Xcode window organization tips? - xcode

I'm a fairly recent convert to Xcode and OS X. Even though I have two large monitors it feels likes I spend far to much time hunting for windows.
I typically have at least the following windows open:
The file I'm editing.
A matching header file.
Another source file.
API Documentation.
A browser window.
It seems like whatever I want next is always underneath something else. There are lots of ways to switch windows (e.g., Exposé, Spaces, OS X hotkeys, Xcode hotkeys), but that's part of the problem. There are so many different approaches, I can't blindly use one; I have to think about which is the right one for each situation.
How do you organize your Xcode windows so you aren't switching all the time?
Or, how do you effectively switch between windows?

I prefer all-in-one layout (Xcode's preferences->General). If I need to look at several files simultaneously, I split the editor view (the little button above the vertical scroller). I also constantly use Cmd-Option-UpArrow to switch between .h and .m files. The only other window I have is the documentation browser.
I have a dedicated Space for Xcode so that I can switch between Xcode and Safari with a shortcut.
Xcode is unbelievably customizable, though many options are well hidden.

I keep the main XCode window open and the documentation open slightly askew from each other horizontally so i can click one while the other is on top. I use the button (right next to the lock icon) which opens the associated file to toggle in-betweeen the h and m files.
I use expose and keep safari in another panel.

Related

Disable auto-raise windows in LibreOffice

Apologies if this isn't the right place to ask about LibreOffice, but I didn't see another site more appropriate.
If I have two LibreOffice documents open simultaneously with one overlapping the other, I find that floating my mouse pointer over the toolbar buttons in the background window (without clicking) brings that window to the foreground, covering the document I was trying to work with. But the focus doesn't change. If I type, those characters are typed into the now-in-back document window, not the one on front. It's super-annoying.
Is this a setting that I can disable? Usually, it's the window-manager that is in charge of raising windows, but LO seems to be doing it by itself.
When neither of the two document-windows has the focus (e.g. a web browser or whatever is in the foreground), the LO windows still behave the same way, but they do not come to the foreground... they just swap their foreground/background position relative to each other.
This is on LibreOffice 7.4.5.1, but it was happening with whatever version I just upgraded from as well (I upgraded to see if this was "fixed"). It was probably 7.2.something. I'm on x86-84 MacOS Ventura.

create a program with Xcode-like interface

On Mac it is usual that there is a "hidden" main window.
The usual example is "Text Edit". When you open a file you with you don't see a "main frame". Instead every single file will be opened in its own "Text Edit" instance. This is OSX way of emulating the so-called MDI interface.
However, there is an exception. If you open Xcode and open the project there, you can click on the file and it will be open inside the main Xcode window. And if you double click the file it will be opened in its own independent editor window, keeping the main Xcode window visible.
My question would be: do I need to do anything special in order to make my program behave like an Xcode? Should I use different class for the main frame or maybe react differently on the opening document event?
Any hints/pointers where to look or even to the official Apple documentation would be helpful.
The TextEdit behavior you're describing is much more like “SDI” than “MDI”, and the terms “SDI” and “MDI” weren't even needed until Microsoft invented MDI long after Xerox invented the SDI-type interface of which macOS is a derivative.
Anyway, I think you are misunderstanding Xcode's behavior. You seem to think “its own independent editor window” is a different kind of window than “the main Xcode window”. But in fact the new window is of the same kind as the old window, with some optional parts hidden. You can show those hidden parts and make the new window look exactly like the old window. Demo:
The ability to open multiple windows showing the same document (or, in Xcode's case, project) is a matter of software architecture. If you carefully design your app so that multiple windows can share a single model object graph, and can be notified and redraw themselves when the object graph changes, then you have an app that supports multiple windows showing the same document. If you want multiple kinds of windows showing the same document, nothing about Cocoa stands in your way. As a matter of fact, Xcode does have at least one other kind of window in which it shows some properties of a project:
That project settings sheet is really another window; macOS keeps it attached to the main window, but it is in fact an instance of NSWindow (or a subclass of NSWindow), no doubt with its own custom window controller that references the same project objects as the main window.
If you use the Cocoa NSDocument architecture, then a small amount of multi-window support is built-in: an NSDocument knows about its associated windows (via their window controllers). If you want to use the NSDocument architecture, you should read Document-Based App Programming Guide for Mac.
It is unclear what you are after. The traditional Mac UI has been one window per document - i.e. SDI with a single instance of the app running multiple windows - but there has always been the ability for any app to organise the content of that window as it sees fit, including showing multiple "documents" within one window - i.e MDI type UI.
Apps approach such "MDI" in different ways, e.g. some use panes (views) and others tabs. From macOS Sierra the standard NSWindow supports tabs, this system is (semi)automatic for standard document apps. Read Apple's NSWindow Automatic Window Tabbing section in the Sierra release notes for more details.
If you wish to use multiple panes - e.g. like Xcode - you just use views (NSView) and arrange them how you wish.
HTH

Control-Command-Up not switching to counterpart file in Xcode on Lion.

Since the three finger swipe has been stolen in Lion, I find myself forced to resort to the keyboard to switch between .h and .m files. Two finger swipe left and right only seems to work infrequently, and that should be for scrolling anyways.
The keyboard command should be Control-Command-Up, but for some reason this takes me out of Xcode and shows the project file in Finder.
I have checked both System Preferences, and Xcode's key bindings settings, and I can't find anything wrong. Xcode is set properly, and I can't find any conflicts.
Do you by any chance have another program such as Afloat installed that might be taking over the key combination? For instance, Afloat uses the Control-Command-Up key combo to do just what you described - show the open application's file in Finder.
Besides changing the key combo, the Xcode default Control-Command-Down will also switch to the counterpart.
I think it's a bug. For now I assigned another key combination: ^Q and ^Z to "jump to counterpart" and it works.

How to cycle through xcode windows (or open 'help' within the bottom pane)?

In Xcode 3.2 the help/reference pops up in a new window when I ALT, CMD, DOUBLECLICK on a class name**. In previous versions it looks like it used to open up in the bottom pane of the main Xcode window. Can I replicate that in 3.2+?
The problem I'm having is that if either one of the Xcode windows (help or main) is maximised, it's easy to loose one window behind the other, and I seem unable to cycle through the individual Xcode windows (the normal window cycling doesn't work - both windows just show up as one item, 'Xcode').
I'd be happy to find out how to cycle through the Xcode windows or bring up the help window in the bottom pane, as it was in prior versions. Currently I'm using Expose to access the hidden window - which is okay, but not optimal.
Thanks.
** ALT & DOUBLE-CLICK now brings up QuickHelp in 3.2
Can you not simply type Command-~ (command tilde)? That works for me and is the common method of cycling between the windows of an application.
At least with XCode 4, but probably with 3 too, you can use Ctrl+Command+Arrows for navigating between tabs. The Up/Down buttons will switch between header files and source files and the Left/Right between opened windows/tabs.

Xcode window positions when switching from dual to single monitor

When I'm working at home I plug my MacBook in to my 20" monitor as a second (right side) monitor. I do all my editing in Xcode on the larger monitor, and leave the menu bar, debugging and documentation on the laptop's monitor.
The problem is when I disconnect from the second monitor and want to work on code in "laptop" mode. Now, whenever I open a file for editing, it shows up almost entirely off the screen and I have to drag it over to edit it. I understand (sort of) why this is happening, since I last had it open in a different monitor. What I'd like to do is reset the window positions in Xcode so the edit windows show up completely on the laptop monitor. Any ideas on how to do this?
I'd even be willing to nuke entries out of the preferences (or set up an applescript to do it) but the xcode plist is inscrutable to me.
Right click the project in finder, select show package contents, and delete the two username.* files. Its not automated... but it works.
Additionally if your using some kind of version control system you probably want to add username.* to your ignore pattern.

Resources