[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Impelmenting NSWindows95InterfaceStyle
From: |
Richard Frith-Macdonald |
Subject: |
Re: Impelmenting NSWindows95InterfaceStyle |
Date: |
Mon, 19 Jan 2009 20:52:36 +0000 |
On 19 Jan 2009, at 19:12, Germán Arias wrote:
El lun, 19-01-2009 a las 13:46 +0100, Fred Kiefer escribió:
Sounds like the right condition to decide whether to add a menu. But
what should we do in the case, when there isn't a main window? Take
for
example the GSTest application that doesn't display a window on
startup.
Should we only have the context menu of the icon window?
For that reason I propose a new window. A new window without a resize
bar, because its width is determined to the menu (of course the
programmer needs by careful with his menu), and without a close button
in the title bar, because for that is the option Quit in the menu. And
in the toolbar some standard icons like: Open, Save, Info Panel, Help,
Go to app's website, ...
We already have something like that ... it's called the main menu.
It's fine having our main menu in a window of its own, but that's not
mswindows style.
In other hand, with the main menu inside an app's window. I see many
problems. First, as Fred say, if there isn't a main window, which
window?.
Windows apps have menus in multiple windows ... so that's not an issue
(the menu is not supposed to be just in the main window). If there
are no windows we can adopt one of at least two policies ...
1. the app simply terminates.
2. we create a standalone menu (like current menus).
Second, if the user change the window's width, sometimes the
option Quit will by outside the window, that is unacceptable, unless
we
change the position of the option Quit inside the menu.
The normal solution to that is to disallow shrinking of the windowto
be smaller than the menu, but another is to allow scrolling of the
menu inside the window so that you can get to everything. I don't
know what mswindows does, but obviously for mswindows style menus we
should do the same thing.
And the hidden
options needs by accesible in a control that show a vertical menu (not
an horizontal menu). And third, the window need call [NSApp terminate:
self] when the user do a click in its close button.
IIRC there is already an option to have the app terminate when the
last window is closed.
We need an flexible menu and easy change with
NSNextStepInterfaceStyle,
NSMacintoshInterfaceStyle and NSWindows95InterfaceStyle. Now I
propose a
new solution. As said Nikolaus, he proposed a [window setMenu:], then
why not implement this method together my idea?. This solution work on
this way:
When you set NSWindow95InterfaceStyle, GNUstep check if there is a
main
window, if this exist set the menu in that window (with [window
setMenu:]). Call the method setMinSize, with a value that prevent
hidden
options (the programmer need careful in this), and perform a
connection
to window with (for example) AppController, with sometime like this
- (void) windowWillClose: (NSNotification *)aNotification;
{
if( (style == NSWindows95InterfaceStyle]) && (thereIsMainWindow) )
{
[NSApp terminate: self] ;
}
}
If there isn't a main window then, GNUstep make a new window as I said
before.
And I don't see problem if the user want set his own menus in other
windows (of course not the main window).
What do you think about this new idea?
The main problem is that it's not much like the way mswindows
behaves ... we want to implement an NSWindow95InterfaceStyle for our
main menu which makes our apps behave like mswindows apps. An
application programmer may well want (and be allowed) to control
things (eg preventing the main window from appearing in certain
windows and terminating the app when they want to) but the default
behavior of the application should be like mswindows, with the main
menu displayed inside every eligible window and the app being
terminated if there is no eligible widow.
- Impelmenting NSWindows95InterfaceStyle, Germán Arias, 2009/01/18
- Re: Impelmenting NSWindows95InterfaceStyle, address@hidden, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Richard Frith-Macdonald, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Pete French, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Matt Rice, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Fred Kiefer, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Pete French, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Matt Rice, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Germán Arias, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Germán Arias, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle,
Richard Frith-Macdonald <=
- Re: Impelmenting NSWindows95InterfaceStyle, Germán Arias, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Robert J. Slover, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Gregory John Casamento, 2009/01/19
- Re: Impelmenting NSWindows95InterfaceStyle, Riccardo Mottola, 2009/01/20
- Re: Impelmenting NSWindows95InterfaceStyle, David Chisnall, 2009/01/20
- Re: Impelmenting NSWindows95InterfaceStyle, Riccardo Mottola, 2009/01/20
- Re: Impelmenting NSWindows95InterfaceStyle, Robert J. Slover, 2009/01/21
- Re: Impelmenting NSWindows95InterfaceStyle, Nicolas Roard, 2009/01/21
- Re: Impelmenting NSWindows95InterfaceStyle, Germán Arias, 2009/01/21
- Re: Impelmenting NSWindows95InterfaceStyle, Fred Kiefer, 2009/01/22