Re: Window manager interaction
On 17 Oct 2009, at 18:13, Wolfgang Lux wrote: 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. That sounds right to me. 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. I'm less sure about that ... one thing I really hate is applications which open up blank document windows when I don't want them (which is almost always the case). You are probably right about it though ... it does seem a very common behavior on OSX (though some apps open the most recently used document, and few don't open anything). Is it actually automatic though ... if so, it might be nice to have a default to disable it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 18 Oct 2009, at 05:31, Sheldon Gill wrote: Actually, I think it would simplify things a great deal if we dropped the miniwindow entirely. I believe the fundamental problem here is one of design and the flaw is trying to get -gui to handle miniwindows. For any compatibility desktop we want to consider (GNOME, KDE, MS-WIN...) the answer is conceptually straight-forward: a window sets its state to whatever, including MAXIMIZED, ICONIFIED/MINIMISED the desktop environment does the display So what -gui should be doing is just that, setting the window state appropriately and letting the backend translate that into the desktop environment. The architecture is supposed to go like this: The application handles it's windows and draw in them/etc. This is - gui -back. The window manager decorates the windows and provides the mechanisms for users to interact with them. (Move them around, re-layer, pin, show/hide, whatever) The application manager (pager) handles launching applications, showing what is running and switching between them. This is the taskbar / kicker / fiend / dock thing. This is the thing which would be displaying miniwindows for those desktop environments where its appropriate. It seems to me that we're trying to get -gui/back to sometimes be a window manager and sometimes be an application manager and getting (understandably) very confused. I happen to like minwindows (they were great in NeXTstep), though I agree that the world has standardised on a less functional mechanism and the advantage of the miniwindow (allowing user interaction with a minimised window) is, as a consequence, practically never used. On the other hand, maintaining OpenStep backward compatibility is not the issue here. The problem I was talking about really has nothing to do with miniwindows (and doesn't involve trying to be a window manager) and my mention of miniwindows was only as a possible way to simplify the frontend-backend api a little for clarity, by handling minimise strictly using the ordering API with miniwindows (you could equally use a special API for it and not use the ordering API for miniwindows at all, but the point was to avoid having overlap between the ordering and minimisation APIs). The actual problem is that X doesn't differentiate between a window being mapped and a window being de-iconified, so you can't know when a window is de-iconified in order to send the notification mandated by the OSX NSWindow API. In fact, this problem does not occur with miniwindows (since when X tells us a miniwindow has been mapped, we know that the normal window has been miniaturised, and when X tells us it is unmapped, we know the normal window has been deminiaturized). The problem ONLY occurs when we are using the standard X mechanism/ architecture you describe. Actually the lack of discrimination in what X tells us is only part of the problem, I guess the more intractable part is that the event queue prevents us from inferring what's needed: Consider the sequence of events ... 1. start hiding app 2. order in the window 3. minimise/iconfiy it 4. wait for notification that it has been unminimised 5. unhide application at (2) we tell X to map the window at (3) we tell X to iconify it (we have to do (2) first because at least some window managers don' allow you to iconify an unmapped window) at (4) X tells us that the window has become visible, which would ideally mean that it was de-iconified, but is actually the event resulting from the window being mapped at (2). This means that the hide operation usually results in an immediate unhide simply because an old event looks like it is a deminiaturise. I've experimented with various ideas to solve this, but without success so far ... any ideas from X coders would be good. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
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. 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. I think the problem with document based applications should be handled differently. I don't think that porting an application to a different Menu Style can be done completely automatically in any case. For example even if you force opening of a New document, what happens if you close the last document? The application should definitely not close! This is Wrong! At least, not true under any condition. Do you guy actually use window? I do, sadly. Use any Office application. Use Photoshop. How do they work under windows? They have that horrible MDI - Multi Document Interface. With that interface the application can continue to exist without any documents open. It doesn't force the opening of a new document and it does NOT close after the last document is closed. 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. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Richard Frith-Macdonald wrote: On 17 Oct 2009, at 18:13, Wolfgang Lux wrote: 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. That sounds right to me. 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. I'm less sure about that ... one thing I really hate is applications which open up blank document windows when I don't want them (which is almost always the case). I happen to think differently. Most of the time I find it annoying that I have to go to the menu just to create a new document after starting an application. However, that is probably because I usually start an application directly only when I want it to create a fresh document and otherwise I start the application by double-clicking the document I want to open. So I understand that your workflow is probably different from mine. You are probably right about it though ... it does seem a very common behavior on OSX (though some apps open the most recently used document, and few don't open anything). Is it actually automatic though ... if so, it might be nice to have a default to disable it. What I've implemented is in fact just the OS X behavior: In a document-based application, create a new document on startup unless the user did already request another document to be opened (or there are autosaved changes that were not properly cleaned up when the program was used last time, probably indicating that there was a crash). The OS X way to prevent a document-based application from opening a fresh document on startup is by implementing the - applicationShouldOpenUntitledDocumentFile: and return NO from it. Anyway, if you think it would be useful to have a user default too, I'll add it (or you can do it yourself; look for the code which calls -openUntitledDocumentAndDisplay:error: the end of -finishLaunching in NSApplication.m). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 18 Oct 2009, at 07:44, Richard Frith-Macdonald wrote: 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. I'm less sure about that ... one thing I really hate is applications which open up blank document windows when I don't want them (which is almost always the case). You are probably right about it though ... it does seem a very common behavior on OSX (though some apps open the most recently used document, and few don't open anything). Is it actually automatic though ... if so, it might be nice to have a default to disable it. This was why I suggested doing it only if, after calling - applicationDidFinishLaunching in the delegate, there is no main window. That way, if the application is opening the last document on relaunch, or providing a 'create some specialised kind of document' window, -gui has somewhere sensible to put the menu already and doesn't need to create one. Note that I was only suggesting this behaviour for applications in the Win95 interface style. In any other interface style it's not particularly important, because the window location doesn't change when you have no main windows. Oh, and Riccardo, Microsoft deprecated MDI almost a decade ago now. Any applications still using it are violating Microsoft's HIGs. MS Office hasn't used it since Office 2000; each MS Word document is a stand-alone window. When you close the last one, Word exits. David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Hi, 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. yes, you are correct. The application's behaviour should be respected. If not, the interface style should be. I suggest that your YES default instead of NO could be extended to mac-style menus and not win95 only? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Hi, This was why I suggested doing it only if, after calling -applicationDidFinishLaunching in the delegate, there is no main window. That way, if the application is opening the last document on relaunch, or providing a 'create some specialised kind of document' window, -gui has somewhere sensible to put the menu already and doesn't need to create one. Note that I was only suggesting this behaviour for applications in the Win95 interface style. In any other interface style it's not particularly important, because the window location doesn't change when you have no main windows. Oh, and Riccardo, Microsoft deprecated MDI almost a decade ago now. Any applications still using it are violating Microsoft's HIGs. MS Office hasn't used it since Office 2000; each MS Word document is a stand-alone window. When you close the last one, Word exits. You are only partially correct. It was deprecated, but it is widely used. I use Office 2003 at work and it still essentially MDI. Try excel and try to have its document not full-sized. The whole excel is a big window then. If you program in SWING under Java, you can get the whole MDI thing again and sometimes it is the only clean way to port the application without rewriting some of its logic. If you have Multi-documents, which is what we have, there aren't many choices: closing/reopening an application is a no-go, IMHO. THus either a big encompassing window or a floating menu, which I have seen for certain programming IDEs for example. Also under BeOS this approach was used. A contorted way to get some OpenStep behaviour. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Riccardo Mottola wrote: Hi, 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. yes, you are correct. The application's behaviour should be respected. If not, the interface style should be. I suggest that your YES default instead of NO could be extended to mac-style menus and not win95 only? I feel unsure about mac-style menus. Classic Mac OS was similar to OS X and NeXTstep in that applications normally did not quit when their last window is closed. You could also hide and unhide applications as on OS X. For that reason I would think the right default for mac- style menus would me NO. On the other hand, Classic Mac OS also had an application switcher, a menu at the right end of the menubar that allowed you to switch to any running application (whether hidden or not). Yet, I expect that it is unlikely that anybody would (want to) implement such an application switcher for Mac style menus, so returning YES makes sense to me too. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On Oct 18, 2009, at 3:21 AM, Richard Frith-Macdonald wrote: On 18 Oct 2009, at 05:31, Sheldon Gill wrote: Actually, I think it would simplify things a great deal if we dropped the miniwindow entirely. I believe the fundamental problem here is one of design and the flaw is trying to get -gui to handle miniwindows. For any compatibility desktop we want to consider (GNOME, KDE, MS-WIN...) the answer is conceptually straight-forward: a window sets its state to whatever, including MAXIMIZED, ICONIFIED/MINIMISED the desktop environment does the display It seems like a really good idea. There's some wear beginning to show in Gnome, where people are starting to want to draw on icons, and there's a move to client-side windows for a lot of things. I think this is a good thing. Window managers need a way to deal with miniwindows, and I think it's time to solve this in a cross-platform way. The time's really ripe to get a spec that works for Gnome and Gnustep both. I happen to like minwindows (they were great in NeXTstep), though I agree that the world has standardised on a less functional mechanism and the advantage of the miniwindow (allowing user interaction with a minimised window) is, as a consequence, practically never used. On the other hand, maintaining OpenStep backward compatibility is not the issue here. I like the concept of miniwindows, but I'd love to see some evolution that lets us have a MacOS-style dock that really works. I'd also really love to be able to use Metacity as a window manager. There's also a move toward application-handled decoration, and specs are being built for this. I think it's ripe time for Gnustep to get involved there, too. The actual problem is that X doesn't differentiate between a window being mapped and a window being de-iconified, so you can't know when a window is de-iconified in order to send the notification mandated by the OSX NSWindow API. In fact, this problem does not occur with miniwindows (since when X tells us a miniwindow has been mapped, we know that the normal window has been miniaturised, and when X tells us it is unmapped, we know the normal window has been deminiaturized). The problem ONLY occurs when we are using the standard X mechanism/architecture you describe. Indeed, though modern window managers do give some better messages. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
