Re: Xcode 4 UI customizability curiosities
Re: Xcode 4 UI customizability curiosities
- Subject: Re: Xcode 4 UI customizability curiosities
- From: "Andy O'Meara" <email@hidden>
- Date: Wed, 23 Jan 2013 11:35:22 -0600
On Jan 22, 2013, at 5:15 PM, Fritz Anderson <email@hidden> wrote:
> On 22 Jan 2013, at 3:49 PM, Andy O'Meara <email@hidden> wrote:
>
>> On Jan 22, 2013, at 1:54 PM, Quincey Morris wrote:
>>
>>> On Jan 22, 2013, at 11:04 , Andy O'Meara <email@hidden> wrote:
>>>
>>>> Apologies in advance if I'm being a meathead here, but is there any way for Xcode 4.5 to bring an already-open file (as a tab) to the front rather than Xcode always make a new tab?
>>>
>>> … when you do … what?
>>
>> Well, when you do a navigation click that initiates a new tab (as set in the general prefs pane). Pretty common unless you do all your editing in a single tab the entire time.
>
> So your problem is that you've set a gesture to open files in separate (the General pref pane's word) tabs, and you use that gesture, and you're annoyed that when you repeat the gesture a lot you've opened a lot of separate tabs? I don't see how it's unintuitive or unintelligent that asking for X five times should give you X five times.
i'm not sure why you regard it as a given that a gesture has to produce the same precise result even if it doesn't always make sense in a certain situation (like when the file is already open in a tab). also, we're talking about adding a checkbox that would enable this behavior, so there would be precisely zero downside for you or anyone else's Xcode experience that felt like editing the same file in multiple windows was important to have.
>
> Or is it that when you have tabs A.m, B.h, and C.storyboard, and then do something that expresses interest in A.m (other than, say, clicking A.m's tab), the gesture should activate tab A.m, rather than creating an additional tab?
yeah, that's the situation. it arises, at least for us, when you're in a C++ forest and you're navigating through a sequence of symbols (imagine 6-7 .cpp or .m files with methods that call methods in the other files -- ya do a pseudo trace via click navigation and the next thing ya know there's an over-crowed tab party goin on).
>
> Interesting feature. You should elaborate it (off-list) and request it. http://bugreporter.apple.com/ .
>
> My own comment is that in providing a big fat tab for you to click, and key bindings to navigate between tabs, Xcode has already provided an intuitive, intelligent way to expose a file in a tab. Perhaps I misunderstand.
>
10 files in 30 tabs with say a 1700 pixel-wide MacBook Pro screen => 55 pixels per tab (and even less if Xcode isn't maximized)
10 files in 10 tabs on the same screen => 170 pixels per tab (and 1/3 the clutter)
The name of a file typically often won't even fit once a tab is less than a 100 pixels, let alone that now your eye has to visually scan through more tabs before it statistically will see the file name you're looking for. when my mind is in down an intense implementation decision rabbit hole with a lot of mental plates in the air, it doesn't make sense to get distracted to be tab hunting.
So perhaps "big fat tab" doesn't best describe the size of a typical tab for many veteran devs.
>
> What you're asking for is a _feature_, not God's will. It's a feature worth considering, but it is not offensive that the responsible people will have to trade it off against the complexity of the UI and documentation (you want open-tab-times-5 to mean open-tab-times-1, but only sometimes), and the problem of working the feature into hundreds of thousands of lines of code (again, it's not the Tao — there is no "flow with the Universe" opcode).
Your point would probably stand more strongly if the work required isn't just adding a pref checkbox 'Always navigate to newly created tabs' and a single page of code that would address the issue. And if you disagree on the code assessment, then we probably have a disagreement about software design and implementation quality standards at a premier US software company (in the new tab code path, insert logic that steps through the existing pathname/identifier associated with each open tab/window and if it finds it, make it active; otherwise, proceed along the new tab/window code path). Xcode is badass in so many ways, so i hesitate to think this issue isn't a feature that requires the strength of "God's will" to make happen. just the strength and labor of a single engineer that realizes that this issue seems to be easily addressable.
>
> I'm sorry to land so hard on you, who are probably unaware of this group's history. We have had this conversation (not the feature request, which is perfectly legitimate, but — in some cases — the bullying) time and time again, to no effect other than to make one guy feel important. Please let's not have it again.
>
Fair enough, but I don't feel like i'm being a bully -- i'm just trying to understand why things are the way the are and calling attention to what seems inconsistent. being a bully would be like, 'my way is better than your way' rather than, 'at no loss to the existing way, why isn't there a pref that offers this other way that seems to make sense for a lot of dev's needs when the work required seems to be pretty minor'.
And you're certainly right -- a radar is the right way to go, but I thought I'd discuss it on the Xcode discussion list first before assuming that what i figured is automatically the right way to go.
andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden