Re: Xcode 4 UI customizability curiosities
Re: Xcode 4 UI customizability curiosities
- Subject: Re: Xcode 4 UI customizability curiosities
- From: Joar Wingfors <email@hidden>
- Date: Wed, 23 Jan 2013 21:56:41 -0800
On 23 jan 2013, at 21:06, Rick Mann <email@hidden> wrote:
>
> On Jan 23, 2013, at 19:05 , Joar Wingfors <email@hidden> wrote:
>
>> Now, you can configure Xcode to provide much of what both of you are asking for here. The key is making good use of Behaviors. A good introduction to Behaviors would be the "Working Efficiently in Xcode" session from WWDC 2012.
>
> Sorry, Joar, what's there still isn't really good enough.
I know, and that's why I said "much of" not "all of"... :-)
> One aspect I left unsaid was that documents should remember their windows, so that if a document is not currently open in a separate window, but I do something that causes it to be opened in a separate window, it opens to where it was. I just tried this with command-double-click on a symbol, and it did not re-open the window in the same place it was before.
>
> Regarding command-click: I have to command-double-click, which is sometimes hard. I want to configure command-click to go to the existing window, or to open a new window if it's currently closed (remembering the last state of the window when that file was open). If that file has never been open in a separate window before, then it should open in a suitable default that I can configure (staggering is okay, but shape and config should be the same).
We have heard this requested via the bug reporter.
> I watched Chris' part of that video. It has allowed me to set some things, but I think with the sort-of halfway-there behavior, it might be worse than just staying in one window. I'll give it a shot.
>
> By the way, this model Xcode has, of making me go to a behaviors pref pane and pre-program how I want things to be goes against the direct manipulation paradigm of good UI design. I'd rather just set my window, and have it be remembered.
It's pretty seriously difficult to provide multiple UI paradigms in one application. Someone in this thread said "adding a checkbox that would enable this behavior, so there would be precisely zero downside for you or anyone else's Xcode experience". I cannot agree that adding additional features have "zero downside" for those who are not using those new features. New features always have a price tag, primarily in terms of what you cannot work on while implementing / supporting that new feature set.
Behaviors are awesome in that they allow pretty unmatched ability to customize Xcode to do things your way. For that very same reason though, Behaviors are also have the drawback of putting a lot of knobs and switches in your face and making you responsible for the configuration. Either way we'd strike this balance, we'd still end up with the same feedback: "Why are you not providing me with the ability to have Xcode work this way?", or "Why are you making me build your features?". Or more likely both. All in all, I believe that Behaviors have been a net win for our users.
I totally understand that it's frustrating when the tool that you use 40+ hours per week cannot be made to work exactly like you'd want. We'll never be able to satisfy all of you all the time, but rest assured that we'll keep trying. We appreciate your conversation, and your bug reports. You know that the way Apple works is that we almost never comment on our future plans, but don't take that silence to mean that we don't listen, or that we don't care. We do.
> Another thing: there's no way to show just the project stuff, is there? Files & Groups, etc?
No.
> Really, the other thing Xcode needs is different classes of windows. All windows are the same, in that they can all be configured to be anything. But I want there to be one (and only one) "Project" window, which is a parent to all the windows that spawn from it (not a visual parent, mind you). That is, if I close it, I want all the other windows to close. When I re-open the project, I want that window to open (plus any others that were open before).
We have heard this requested via the bug reporter.
> I really want a traditional document model, not a browser model.
We have heard this requested via the bug reporter.
> I'll try experimenting with the behaviors more. They're still not doing the right thing, but I think some of what I'm seeing is a bug.
Please file a bug report if you decide that's what it is.
> Any way to get a separate search & replace dialog instead of that banner across the top?
No. What's your reason for preferring a separate panel?
Joar
_______________________________________________
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