> Full screen mode: This is mainly because we are hesitant to go Lion-only so we are holding back with “lionizing” TextMate till we feel confident we can fully drop backwards compatibility.
That's not true. Adding full-screen support does not require breaking backwards compatibility: it's a quick check to see if the feature can be enabled.
I am also confused by all of the Lion hate. I will admit I just recently got my first mac but man is Fullscreen mode NICE. Swipe right to go to the browser, swipe right to my text editor, swipe again to check on the irc window.
All the while those screens are not distracting me with popups and notices. To me Lion is still more fluid and better built then anything I've used from Ubuntu to Win7/8.
Add more than one physical screen you'll see lion's fullscreen mode completely wastes the extra screens by blanking them out with that grey crosshatching. very lame if you have 3 screens
It's opt-in for old projects, but it's as simple as compiling the app with Lion support without code changes or compatibility issues to turn on the flag for the window in IB. (Obviously, for new Lion projects, it's automatically enabled). The issue of checking in code comes when you want to add an "Enter Fullscreen" menu item, which requires a tiny bit of code to make sure you don't call "toggleFullscreen:" on a window that doesn't know about it (or display the menu item on an OS where it will do nothing).
Still. It's pretty basic.
(As for the window manager supporting it, some apps really shouldn't be fullscreen - Address Book, I'm looking at you - so having an easy opt-in/out mechanism seems pretty necessary on the application side.)
To me, this seems to be an "opt-out" rather than "opt-in" sort of thing. The easiest parallel would be maximizing windows in Windows or most Linux WMs: you can maximize all windows by default, but they are free to disallow maximizing. This seems a more reasonable approach.
Full screen mode in Lion is a little more than just maximizing window to fill the screen, though. Developer can/may/should also provide an alternative UI that's tailored for full screen and may update the UI depending on top menu bar's visibility. iPhoto and Photo Booth does this, for example. If bookmark bar is hidden in Safari, it will be shown when you point the mouse at the topmost of the screen (make the menu bar visible for extra controls).
Yes, I could see that. However, that still doesn't mean it should be opt-in for everybody. For most programs--particularly text editors--going full screen is basically minimizing.
I really like how KDE handles this: by default, full screen is like maximizing and turning off the borders/title bar (the window might also cover the panel on the bottom, but I have that hidden so I don't know). However, programs are free to do whatever they want in full-screen mode; Chrome, for example, treats it just like F11.
This lets me have the best of both worlds--if software does something special, it can; if it doesn't, I can still have it full screen, which is especially useful for programs like Emacs (which is its own window manager, really ;)).
That's not true. Adding full-screen support does not require breaking backwards compatibility: it's a quick check to see if the feature can be enabled.