This reminds me of when Apple included a 'close window' command in the contextual menu on a minimized window in the dock in the 10.3 beta. They ended up leaving it out due to the complexity of dealing with sheets and quitting apps.
It's still there for Carbon apps... try it in the Finder
i believe a minimal undocumented feature such as this wouldn't really hurt anything as far as user friendliness goes, as it would go unnoticed by most users.. it'd only help the "power users" who want to use it.
Now use that justification for 50 such features and you've got *ta-da*! Windows.
I would love the ability to have a pop-up menu listing all Exposé commands appear when I click the scroll wheel button of my mouse. Drag and release to select the view I want. Any ideas on how I could set this up? Any software available that would work?
I like the idea of being able to send a command-w to close the window the cursor is over. It doesn't matter what behaviour comes out of it (save sheet, modal this, blah blah blah). All Exposé has to do is send the command-w keystroke to that window, then bring it forward as if the user had clicked on it. Now if the window happens to have destryoed itself, Exposé simply refreshes to make that window disappear (it can detect a now null pointer or get the event).
One could argue that this is equivalent to doing Exposé, click to bring a window up, close the window (however you like) and then Exposé again. However, this is not equivalent. With one less window, Exposé now displays the remaining windows in different positions on the screen. By simply passing the keystroke, Exposé detected the window gone and just makes it disappear rather without reshuffling the remaining windows. (Or an animation showing where it is moving the windows as it reshuffles them to make better use of screen with the benefit that the user can track them visually and so still knows where that next window he/she was going to activate now is.)
Now we can have some fun. Exposé could pass any command keystroke (apple-option-whatever, apple-whatever, etc) down to the window below it, then bring it forward (if it is still there). Detect any windows that have gone and refresh itself. Programatically, a very easy thing to do. It would probably be smarter to not pass any other keystrokes (it would be like no widget on the window has focus; only the window -- I should say application -- itself can accept commands).
Exposé would then be raised somewhat. It wouldn't be just a window switcher. It would be closer to a virtual desktop (a nice large one) where you don't care where the windows actually are but zoom in on them to work on them. However, when not zoomed in, you could still tell the applications things (send commands).
I would rather see Expose let you freeze the windows when they are spread out and even let you tile windows so that I don't have to move around a bunch of windows to clean up things myself.
Well, if MOSR is right *snort* *cough* *giggle*, Expose will be enhanced in 10.4: *Expose 2.0, with more eye candy (imagine if Expose warped windows as they moved, ala the "Genie" minimizing effect) and new window-managing behaviors."
Will be interesting to see what mechanisms they come up with, if any.
I like the idea of being able to send a command-w to close the window the cursor is over. It doesn't matter what behaviour comes out of it (save sheet, modal this, blah blah blah). All Exposé has to do is send the command-w keystroke to that window, then bring it forward as if the user had clicked on it. Now if the window happens to have destryoed itself, Exposé simply refreshes to make that window disappear (it can detect a now null pointer or get the event).
But that's sort of like shifting window focus (sloppy focus) in other GUIs like WindowMaker. Hover your pointer over a window and all commands register for that window. I don't like it. It's not deliberate enough. It's not consistent with the normal function of the GUI. Just say no to sloppy focus.
Comments
Originally posted by bauman
This reminds me of when Apple included a 'close window' command in the contextual menu on a minimized window in the dock in the 10.3 beta. They ended up leaving it out due to the complexity of dealing with sheets and quitting apps.
It's still there for Carbon apps... try it in the Finder
Originally posted by confirmed
i believe a minimal undocumented feature such as this wouldn't really hurt anything as far as user friendliness goes, as it would go unnoticed by most users.. it'd only help the "power users" who want to use it.
Now use that justification for 50 such features and you've got *ta-da*! Windows.
Originally posted by Dale Sorel
It's still there for Carbon apps... try it in the Finder
No, it's only the finder, because Apple knows that the Finder will never have any save document or quitting issues.
One could argue that this is equivalent to doing Exposé, click to bring a window up, close the window (however you like) and then Exposé again. However, this is not equivalent. With one less window, Exposé now displays the remaining windows in different positions on the screen. By simply passing the keystroke, Exposé detected the window gone and just makes it disappear rather without reshuffling the remaining windows. (Or an animation showing where it is moving the windows as it reshuffles them to make better use of screen with the benefit that the user can track them visually and so still knows where that next window he/she was going to activate now is.)
Now we can have some fun. Exposé could pass any command keystroke (apple-option-whatever, apple-whatever, etc) down to the window below it, then bring it forward (if it is still there). Detect any windows that have gone and refresh itself. Programatically, a very easy thing to do. It would probably be smarter to not pass any other keystrokes (it would be like no widget on the window has focus; only the window -- I should say application -- itself can accept commands).
Exposé would then be raised somewhat. It wouldn't be just a window switcher. It would be closer to a virtual desktop (a nice large one) where you don't care where the windows actually are but zoom in on them to work on them. However, when not zoomed in, you could still tell the applications things (send commands).
Originally posted by bauman
No, it's only the finder, because Apple knows that the Finder will never have any save document or quitting issues.
I just did it in BBEdit, though I don't know about other Carbon apps
There is zero reason why the contextual items I described, all window related functions, couldn't also be in a traditional menu.
Select multiple windows and apply a command to them from either the main menu or a contextual one.
Oh my the horror! The unmac-like inconsistency!
Honestly, it's not that difficult or arcane or awkward.
Will be interesting to see what mechanisms they come up with, if any.
Originally posted by rrabu
I like the idea of being able to send a command-w to close the window the cursor is over. It doesn't matter what behaviour comes out of it (save sheet, modal this, blah blah blah). All Exposé has to do is send the command-w keystroke to that window, then bring it forward as if the user had clicked on it. Now if the window happens to have destryoed itself, Exposé simply refreshes to make that window disappear (it can detect a now null pointer or get the event).
But that's sort of like shifting window focus (sloppy focus) in other GUIs like WindowMaker. Hover your pointer over a window and all commands register for that window. I don't like it. It's not deliberate enough. It's not consistent with the normal function of the GUI. Just say no to sloppy focus.