[Top][All Lists]

[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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]