I think you're confusing Single Window mode and MDI from Windows?
I talked about SWM just for the clutter on screen it artificially cleaned, not any fullscreen ability it doesn't have
MDI on Windows (ala Photoshop) is a pretty bad UI design IMHO. This grey background with a limitating border for all application windows is dummy, but it comes from technical limitations of Windows itself.
I talked about iMovie because it is an app which does not spill its tools across your cluttered desktop.
Prevous versions of iMovie ran even in fullsreen mode, but it was not very good for many reasons, one was the Dock which had to be automatically hidden and shown after quitting iMovie, antother was the system-level drag&drop removed from within the application. Now iMovie is an application with an "integrated UI" not spilled accross the screen but gathered in one block. Same "integrated UI" with iDVD, iPhoto, GarageBand...
I would argue that solution seems like a tack on than a thought out function that affects the entire OS. Preferences can get out of control rather quickly. As has been discussed, developers only code what they have to and by keeping the more difficult to code philosophy a standard, they will get more developers to adhere. I am really interested to hear why someone likes maximize to full screen. I have never found an instance where its useful. Frankly its one thing I have trouble understanding when using Windows. Several of you have stated you like it, but why. Zoom will maximize if the window's content is of that great of a size. Am I missing something?
Wow, I think we might actually have consensus here...
Dear Apple... we the undersigned do hereby proclaim the following...
1) Recognizing that drag and drop is a ubiquitous and useful feature in the MacOS UI...
2) and that a default full-screen maximize mode ala Windows would break that model...
3) and that allowing the user to make that the default would only encourage lazy developers from coding intelligent zoom...
4) but that some users find such a mode useful for reducing accidental 'in the gutter' clicks between palette windows bringing for the Finder...
5) and that some users are simply more comfortable with a lesser capable UI model...
we request that a full-screen maximize mode be introduced for all windows, and that it be triggered by a command key sequence, such as Opt-click on the zoom widget.
Additionally, we would urge you to develop a common-case general purpose intelligent zoom system within the Cocoa framework to alleviate the issue with #3 above and make this even less of an issue.
we request that a full-screen maximize mode be introduced for all windows, and that it be triggered by a command key sequence, such as Opt-click on the zoom widget.
Personally I would like the option for an on off checkbox in Appearance>System Preferences, to turn that green button from Zoom to Maximize with a simple click
Maximization... useful in a number of cases, for me, I have large photo editing (photoshop or what have you) maxxed and zoomed on one panel, then the interface lives on the other... so one large panel for working, and second smaller for "normal" apps... music, files, email, etc.
Button customization. I dont get why resize/ recolor is such a bother... my grandma has a palsy... she hates trying to get to those small buttons with a mouse. She really hates that she can't space them more. So on my windows machine I have a UI that makes it easier for her.
But shift-click zoom does do maximise, doesn't it?
It does in OmniWeb, where I am now. It does in Mail, Skype, Adium and Colloquy. The only app I have open now that doesn't do that is the Finder, which is retarded for other reasons and therefore does not count.
Frankly, though, at this point I wonder if the "zoom" function needs a rethink. But either give developers the tools to allow for easy-as-pie-to-code intelligent zoom (with some nice, global alternate maximize function) or give it an entirely new zoom function.
Quote:
Originally posted by Amorya
But shift-click zoom does do maximise, doesn't it?
It does in OmniWeb, where I am now. It does in Mail, Skype, Adium and Colloquy. The only app I have open now that doesn't do that is the Finder, which is retarded for other reasons and therefore does not count.
I've noticed that in Omniweb. Problem is the behavior isn't global. Shift-clicking the zoom widget in Safari, Word, TextEdit, [insert app here], etc. has no effect.
Frankly, though, at this point I wonder if the "zoom" function needs a rethink. But either give developers the tools to allow for easy-as-pie-to-code intelligent zoom (with some nice, global alternate maximize function) or give it an entirely new zoom function.
I've noticed that in Omniweb. Problem is the behavior isn't global. Shift-clicking the zoom widget in Safari, Word, TextEdit, [insert app here], etc. has no effect.
Well, it does here in TextEdit, but good point.
I thought the shift-click to maximise was at least standard for Cocoa. Safari has me surprised.
Further testing: it works in iCal, OmniPlan, Xcode, iGetter...
Doesn't work in Preview, Safari, Finder, iTunes...
It does work in a random app that I coded, which I did not write any code at all to do with window resizing, so it seems to me that it takes a special effort not to have the functionality, at least with cocoa.
Zoom isn't all that hard to implement. You just gotta calculate the new frame well. In Cocoa, -[NSWindow (NSRect) windowWillUseStandardFrameNSWindow *) sender defaultFrameNSRect) defaultFrame] will get called.
So here, for instance, is some code to resize a panel that mainly consists of a table (this is actually from a closed-source software project I'm working on):
(Alright, so I cheated: the width is actually not determined in this case, but fixed. In this particular case, that's okay, because other widths don't really make much sense. Usually, though, you'll want to calculate the width just as much as you calculate the height.)
To figure out the height, we first define three constants: the height of a table row, which is actually 50 pixels, but you have to take into account two additional pixels of border, the height of the panel's title bar, and the height of its status bar, which is in our case actually just a mostly empty space with an NSTextField on top acting as a label. Kind of like Safari's Downloads window, if you will.
We create a new frame which will differ from the default zoomed frame in some aspects.
So we calculate what we assume to be the new height by multiplying the amount of rows we need (_totalRows) with how high each of them is, and adding the height of the title bar and that of the status bar. That gives us a panel just high enough to fit all data. Not a single pixel too high.
We then decide that we don't want to change the position, because that would be annoying, so we just copy that of the old frame.
We check if this height would be larger than the one the default zoom method gives us. This gives us an easy way to determine if the new height would actually fit within the screen constraints, including the menu bar and the Dock. The default zoom method already accounts for that, so we might as well make use of that. If our calculated height is equal or smaller, we use it; otherwise, we use whatever Apple's code provides.
The width is hardcoded to 325 pixels, which is all we really need at this point. A similar means as above could be used to calculate a good width for the new frame.
Problem with my app is that it does not scroll - it's a permanent zoom-to-fit custom view. That is, I do the drawing as a percentage of the view. So whatever size my window is, the contents fit exactly. (I do have a scrolling text field underneath, so maybe I could do something clever vertically.)
Hence I didn't know how to implement zooming properly - surely the current size is the optimal size?
But thanks for the tip. The next time I write an app which doesn't do scale-to-fit, I shall use that.
Yeah, there is no true "ideal size" for your window, except for the text field, as you point out yourself: zooming should resize the text's height to fit the text contents as much as possible.
What drives me crazy is when I hit the green button on my 30" display or my 60" tv. It makes the window slightly bigger, IF I WANTED that to happen I'd just freaking DRAG it bigger. Green + should be maximize, I want it to go fullscreen.
Is there no way to make Apple programs go fullscreen? This is the biggest complaint i hear everyday from windows users who've switched to mac, they get really frustrated because they can't make the window fill the screen.
Shift+Click with dual displays, makes the safari window jump to the primary window and go full height, but not full width. What the hell, move my window around why don't you apple. (safari)
Is there no way to make Apple programs go fullscreen? This is the biggest complaint i hear everyday from windows users who've switched to mac, they get really frustrated because they can't make the window fill the screen.
Comments
Originally posted by Kickaha
I think you're confusing Single Window mode and MDI from Windows?
I talked about SWM just for the clutter on screen it artificially cleaned, not any fullscreen ability it doesn't have
MDI on Windows (ala Photoshop) is a pretty bad UI design IMHO. This grey background with a limitating border for all application windows is dummy, but it comes from technical limitations of Windows itself.
I talked about iMovie because it is an app which does not spill its tools across your cluttered desktop.
Prevous versions of iMovie ran even in fullsreen mode, but it was not very good for many reasons, one was the Dock which had to be automatically hidden and shown after quitting iMovie, antother was the system-level drag&drop removed from within the application. Now iMovie is an application with an "integrated UI" not spilled accross the screen but gathered in one block. Same "integrated UI" with iDVD, iPhoto, GarageBand...
Originally posted by Placebo
I wish Zoom was as functional as Windows' Maximize.
Try doing that (maximize) on a 30" Cinema. That's called a total waste of space and you'd be better off with 2 15" monitors.
Originally posted by crees!
Try doing that (maximize) on a 30" Cinema. That's called a total waste of space and you'd be better off with 2 15" monitors.
Very easy to solve that! Simply put a drop down box in system prefs to set the screen size:
13"
15"
17"
20"
23"
30"
Please choose, problem solved.
Originally posted by crees!
Try doing that (maximize) on a 30" Cinema. That's called a total waste of space and you'd be better off with 2 15" monitors.
1. Not everybody has 30" displays.
2. I choose whether it's a waste of space or not.
3. I want the option to choose that, even if it means a modifier key.
Dear Apple... we the undersigned do hereby proclaim the following...
1) Recognizing that drag and drop is a ubiquitous and useful feature in the MacOS UI...
2) and that a default full-screen maximize mode ala Windows would break that model...
3) and that allowing the user to make that the default would only encourage lazy developers from coding intelligent zoom...
4) but that some users find such a mode useful for reducing accidental 'in the gutter' clicks between palette windows bringing for the Finder...
5) and that some users are simply more comfortable with a lesser capable UI model...
we request that a full-screen maximize mode be introduced for all windows, and that it be triggered by a command key sequence, such as Opt-click on the zoom widget.
Additionally, we would urge you to develop a common-case general purpose intelligent zoom system within the Cocoa framework to alleviate the issue with #3 above and make this even less of an issue.
Sound decent?
Originally posted by Kickaha
we request that a full-screen maximize mode be introduced for all windows, and that it be triggered by a command key sequence, such as Opt-click on the zoom widget.
Personally I would like the option for an on off checkbox in Appearance>System Preferences, to turn that green button from Zoom to Maximize with a simple click
Seriously, did you not read the explanation earlier for why that's a really bad idea?
Originally posted by Kickaha
Tough noogies. :P
Seriously, did you not read the explanation earlier for why that's a really bad idea?
It's a good idea right
Button customization. I dont get why resize/ recolor is such a bother... my grandma has a palsy... she hates trying to get to those small buttons with a mouse. She really hates that she can't space them more. So on my windows machine I have a UI that makes it easier for her.
It does in OmniWeb, where I am now. It does in Mail, Skype, Adium and Colloquy. The only app I have open now that doesn't do that is the Finder, which is retarded for other reasons and therefore does not count.
Amorya
Originally posted by Kickaha
Sound decent? [/B]
Sounds great to me. Send 'er over!
Frankly, though, at this point I wonder if the "zoom" function needs a rethink. But either give developers the tools to allow for easy-as-pie-to-code intelligent zoom (with some nice, global alternate maximize function) or give it an entirely new zoom function.
Originally posted by Amorya
But shift-click zoom does do maximise, doesn't it?
It does in OmniWeb, where I am now. It does in Mail, Skype, Adium and Colloquy. The only app I have open now that doesn't do that is the Finder, which is retarded for other reasons and therefore does not count.
I've noticed that in Omniweb. Problem is the behavior isn't global. Shift-clicking the zoom widget in Safari, Word, TextEdit, [insert app here], etc. has no effect.
Originally posted by Hobbes
Sounds great to me. Send 'er over!
Frankly, though, at this point I wonder if the "zoom" function needs a rethink. But either give developers the tools to allow for easy-as-pie-to-code intelligent zoom (with some nice, global alternate maximize function) or give it an entirely new zoom function.
I've noticed that in Omniweb. Problem is the behavior isn't global. Shift-clicking the zoom widget in Safari, Word, TextEdit, [insert app here], etc. has no effect.
Well, it does here in TextEdit, but good point.
I thought the shift-click to maximise was at least standard for Cocoa. Safari has me surprised.
Further testing: it works in iCal, OmniPlan, Xcode, iGetter...
Doesn't work in Preview, Safari, Finder, iTunes...
It does work in a random app that I coded, which I did not write any code at all to do with window resizing, so it seems to me that it takes a special effort not to have the functionality, at least with cocoa.
Perhaps we could make a chart?
So here, for instance, is some code to resize a panel that mainly consists of a table (this is actually from a closed-source software project I'm working on):
- (NSRect) windowWillUseStandardFrame
defaultFrame
{
#define TableRowHeight52.0
#define PanelTitleBarHeight18.0
#define PanelStatusBarHeight21.0
NSRect newFrame;
float assumedHeight = _totalRows * TableRowHeight +
PanelTitleBarHeight + PanelStatusBarHeight;
newFrame.origin = _panelFrame.origin;
if (assumedHeight <= defaultFrame.size.height)
newFrame.size.height = assumedHeight;
else
newFrame.size.height = defaultFrame.size.height;
newFrame.size.width = 325.0;
return newFrame;
}
(Alright, so I cheated: the width is actually not determined in this case, but fixed. In this particular case, that's okay, because other widths don't really make much sense. Usually, though, you'll want to calculate the width just as much as you calculate the height.)
To figure out the height, we first define three constants: the height of a table row, which is actually 50 pixels, but you have to take into account two additional pixels of border, the height of the panel's title bar, and the height of its status bar, which is in our case actually just a mostly empty space with an NSTextField on top acting as a label. Kind of like Safari's Downloads window, if you will.
We create a new frame which will differ from the default zoomed frame in some aspects.
So we calculate what we assume to be the new height by multiplying the amount of rows we need (_totalRows) with how high each of them is, and adding the height of the title bar and that of the status bar. That gives us a panel just high enough to fit all data. Not a single pixel too high.
We then decide that we don't want to change the position, because that would be annoying, so we just copy that of the old frame.
We check if this height would be larger than the one the default zoom method gives us. This gives us an easy way to determine if the new height would actually fit within the screen constraints, including the menu bar and the Dock. The default zoom method already accounts for that, so we might as well make use of that. If our calculated height is equal or smaller, we use it; otherwise, we use whatever Apple's code provides.
The width is hardcoded to 325 pixels, which is all we really need at this point. A similar means as above could be used to calculate a good width for the new frame.
And finally, we return the new frame.
Hence I didn't know how to implement zooming properly - surely the current size is the optimal size?
But thanks for the tip. The next time I write an app which doesn't do scale-to-fit, I shall use that.
Edit: added screenshot.
Amorya
Is there no way to make Apple programs go fullscreen? This is the biggest complaint i hear everyday from windows users who've switched to mac, they get really frustrated because they can't make the window fill the screen.
Originally posted by webmail
Is there no way to make Apple programs go fullscreen? This is the biggest complaint i hear everyday from windows users who've switched to mac, they get really frustrated because they can't make the window fill the screen.
Who? You and yo momma?