Please don’t make it the only mode for your application. I hate when applications assume they can grab the whole screen - I frequently have long-term things like compiles or downloads going on in background windows and want to be able to see what kind of progress is being made while I do something else in the foreground.

Please don’t make it the only mode

I can’t think of any apps like that that I’ve come across.

In my experience, with the exception of, say, “DVD Player,” FSM is something you deliberately call up for a purpose then flip off when you’re done. Although I could be wrong. What app’s doing that to you now?

Last summer I tried my hand at developing a plugin for Terminal.app that made it full screen, and I ended up with a solution that works about half way. The API call to hide the dock and menubar is one line of Carbon code, but making the actual window frameless is slightly more involved.

My solution was to call Carbon to hide the dock and menu bar, then tell the window to zoom, which fills the screen but doesn’t hide the window’s title bar. I had to tweak a preferences file by hand to change font sizes and window postion settings, which is why I haven’t released it.

As a recent Switcher, my main gripe about Mac OS X is that 90% of Mac apps refuse to go full screen. If Fitts’ Law is good enough for the Mac OS system controls, why not the apps, too?? I don’t want to scroll unnecessarilyl and I want my scrollbar in the “Fittsable” location on the right side of the screen!

My second gripe about Mac OS X is the lack of consistent, universal keyboard shortcuts (especially for arrow key navigation within an app).

I hate that full screen windows… I will not use them, ever. The main two reasons: I can not read text that is that wide and it kills my work flow between applications.

Did it once for a movie player project. Used AppleScript Studio. Trivial to use a call method…

Hmmm, what’s required?

You subclass NSWindow and override - (BOOL)canBecomeKeyWindow to return YES.

Then you instantiate it, passing NSBorderlessWindowMask as the styleMask parameter of a call to NSWindow’s -initWithContentRect:styleMask:backing:defer:screen: initializer.

Then you probably want to pass something like CGShieldingWindowLevel() to NSWindow’s -setLevel: method before setting the window’s frame (CORRECTLY handling the case where -[NSScreen screens] returns an array of more than one item (i.e. you’re on a dual display box)) and putting it on-screen.

Oh, and don’t forget to capture some keystroke so people can get out of your fullscreen world!

It’s actually quite easy to do it in Cocoa…. by subclassing NSWindow (playing a bit with its initWithContentRect:styleMask:backing:defer: method); no need to “hide” the menu bar, just set the window’s level to something higher than NSMainMenuWindowLevel. This is actually how most 3rd party apps are implementing the FSM. Look for example at VLC: when you’re in FSM hit Shift+Command+F11 to actually slow down the Exposé effect and find out that the full screen view is nothing more than a “normal” window. Even Apple apps (DVD Player and QuickTiime Pro Player) use this method; but others (like Keynote.app) use a more “sirius” FSM that can’t be exposé-ed.

Thanks, guys. This is awesome. Over me head, but useful and awesome. :-)

It would be great if there were some kind of haxie for emulating/inserting this in apps that don’t have FSM baked in.

If any of you are interested here’s the code. It’s messy and probably really bad, but it was(is) my first Obj-C project.

I thought about subclassing the Terminal.app window when I was writing it, but it turns out that you have to assign NSBorderlessWindowMask to the window at creation time and I couldn’t figure out how to move the contents of a current window to a new one. That’s why I used the hide-and-zoom method.

Oh, by the way, my plugin uses SIMBL to inject code at runtime into existing apps, so you have to install that first. The author hasn’t touched it in awhile and I bet there’s a better method now.