Re: Window manager interaction

[Wolfgang Lux]

Riccardo Mottola wrote:

> Hi,
> > I agree that with MS Windows style menus an application should  
> > terminate when its last window is closed and have just committed  
> > code that implements that logic.
> >
> > With regard to creating a new document upon program startup, I  
> > think that a document based application should always do so  
> > (regardless of the interface style) and have committed code for  
> > that too.
> This is very wrong.

sed -3s/should always do so/by default should/
Still wrong?

> The Application controller subclasses  
> "applicationShouldOpenUntitledFile" with yes or no. If it is no,  
> clearly no new document should be opened, if yes, it should. It is  
> up to the application to control this.
> Not all document based applications can handle a "new" document,  
> not always it does make sense. I think of my own application PRICE,  
> which is able to modify existing documents but which has no tools  
> to handle a new one. I wonder how it didn't break after your patch,  
> btw. Thus I do not understand the point of your patch: if that  
> option gets respected, it is all what we need.

If the application delegate responds to - 
applicationShouldOpenUntitledFile the result is of course always  
respected (and guess you've implemented it in PRICE). What I've done  
is just to change the default behavior for a document based  
application if that delegate method is not implemented. GNUstep was  
handling this case as NO, whereas Mac OS X considers this as YES for  
a document based application. All I did was to implement the OS X  
behavior, which I find more reasonable and which seems better suited  
for a Windows like environment anyway.

> [...]
>
> Thus I think your last changes and your proposed changes are just  
> wrong, because applications do not behave that way.
>
> Other applications like "WordPad" do indeed open with a new  
> document and exit after it gets closed, but those application do  
> handle only one document at a time!
> The OpenStep paradigm is inherently Multi-Document.
>
> On the other hand the behaviours you cite could be useful under  
> certain conditions.
>
> I thus have the following thoughts:
>
> - we should find a way to implement some sort of MDI. With the  
> GNUstep or Mac-style menu it is easy: we already to perfectly. For  
> windows I propose the creation of a floating menu-window, thus the  
> main menu can be tracked as a real window and doesn't disappears  
> like now. Or we need the full-blown big window which contains  
> everything.
> - the usage of MDI with "in-windows" menus should be controlled by  
> a plist option: if the application does not need it it can disable  
> it (or the other way around). Thus without intervention programs  
> will run with in-windows menus, but a better control for porting  
> application can be done, if the application controller is fine  
> tuned for the different conditions.

Again, what I've changed is only the default behavior that applies if  
an application does not respond to - 
applicationShouldTerminateAfterLastWindowClosed: Up to now this was  
always considered equivalent to returning NO and with my change it is  
YES when using Windows style menus. Thus, you already get some of the  
proposed behavior (although with a menubar at the top instead of a  
floating menu window) if you implement - 
applicationShouldTerminateAfterLastWindowClosed: and return NO.
>


Wolfgang