Re: xcode 4: detach console window?
Re: xcode 4: detach console window?
- Subject: Re: xcode 4: detach console window?
- From: Jean-Denis Muys <email@hidden>
- Date: Wed, 18 May 2011 08:36:52 +0000
- Thread-topic: xcode 4: detach console window?
On 17 mai 2011, at 19:23, David Duncan wrote:
> On May 17, 2011, at 10:07 AM, John Michael Zorko wrote:
>
>> While I appreciate the white-on-black text style, I greatly preferred the detached console window in Xcode 3. Is there a way I can detach the console window in Xcode 4 from the main window and have it float freely like any other window?
>
>
> I don't think you can fully detach it, but you can come close depending on what setup you want to do.
>
> In Xcode's Preferences under Behaviors you can set various debugging actions to open a new tab. Give the tab a name, and debug your application. When the tab opens, if you drag it off as a secondary window, then it will reappear as a window instead of a tab in the future. You can configure this window however you like, including opening the console window up to cover most of the area etc. About the only thing the window doesn't seem to remember is if the toolbar is visible or not (which I need to file a bug on).
>
> Since this is really a full debug window, you can do whatever other debugging tasks you desire here as well. You can also still have Xcode do other debugging manipulations to the main project window. But I don't think there is currently a way to open multiple "tabs" (but I'd be happy to be proven wrong).
> --
> David Duncan
I feel I need to elaborate.
>> Is there a way I can detach the console window in Xcode 4
there is no "the" console window in Xcode 4 any more. There is "the" console content, that Xcode 4 will display in any and/or all windows depending on many factors, including tomorrow's weather, but excluding what you have in mind as "the" console window.
> I don't think you can fully detach it
Since there is no "the" console window, there is no "it" either.
This is the main issue with Xcode 4 new window model: windows and their content are totally dissociated.
Their is a strong cognitive dissonance between the user mental model, as exemplified by your use of "the" console window, and Xcode 4 model, which considers the top window as the container in which to display whatever it is that Xcode wants to display at any one time: the console, the file just clicked by the user, whatever. This works when the top window is the only window, albeit in a very user-limiting way. It breaks down completely when the user, full of hope, tries to open several windows.
It breaks down with several window, because Xcode's windowing schizophrenia soon leads to the user carefully set up window displaying something completely different, and unintended by the user, including the console.
I and others, have argued that Xcode should (perhaps optionally) restore the model of a "spacial" window. This model is characterized by two essential default behaviors:
1- a window's content is never replaced by Xcode: the window's content is under user control exclusively.
2- when Xcode needs to display something (the console, a file just clicked by the user, whatever), it should when possible, bring to the front the initial window that already shows that content, if it exists.
Other cases should be considered as special cases: replacing a window content should be a conscious user choice, perhaps triggered by a keyboard modifier. Opening a second window on the same content should be a conscious user choice, perhaps triggered by a keyboard modifier.
Currently, Xcode 4 respects neither rule.
The said cognitive dissonance was not lost to Xcode 4's developers. As a cumbersome workaround, they designed the Behaviors user preferences to try and tame Xcode 4 propensity to step left and right on the user windows. As David writes, it helps. To some extent. Indeed, if you kill the wounded, the ache disappear.
Fill free to join the chorus and file a bug report.
Jean-Denis
_______________________________________________
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