Re: Window manager interaction
On Sat, Oct 17, 2009 at 07:02:12AM +0100, Richard Frith-Macdonald wrote: > It sounds reasonable to allow interface style to control that sort of > thing, and the behavior you suggest makes sense for a windows app. > I'm not sure it addresses the original case though ... which was not for > an app running on windows and where, specifically, we know we don't want > to have the app close when the last window closes. So we probably still > need to retain defaults for more fine grained control over behavior > rather than just forcing a microsoft style behavior. > It's not a problem really to do both microsoft style behaviors and user > defaults for fine control. Just for the record, I like the vertical menus :o) > Anyway ... see what you think of the change to allow unhide by showing > the app icon when the app is hidden, and think about how it would be if, > instead of showing that, what we actually did was show a miniaturised > version displayed in whatever way the window manager normally handles > miniaturised windows (eg in a task bar). It works for me (under Metacity), thanks Richard ! I think this is a big step for better integration. I would prefer something to appear in the task bar instead (so demanding...) of the appicon but it's a start. Philippe -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. BrKernighan ___ 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 00:01, Wolfgang Lux wrote: You are right with issue (1), but this is only for the case where an application deliberately hides its appicon. On the other hand, in Phillipe's case I feel that GSSupressAppIcon is abused (somewhat) as a workaround for the lack of better integration with the foreign environment. Maybe it would be a better idea to make use of the current interface style instead of checking the _app_icon_window attribute. Then, assuming that, e.g., an interface style NSWindows95InterfaceStyle indicates the presence of a taskbar, the application should suppress its appicon *and* not manage any miniwindows on itself. Thus, problem (1) would go away. With respect to problem (2), I think that this could be handled by terminating applications by default when their last window is closed and the application delegate does not respond to - applicationShouldTerminateAfterLastWindowClosed:. It sounds reasonable to allow interface style to control that sort of thing, and the behavior you suggest makes sense for a windows app. I'm not sure it addresses the original case though ... which was not for an app running on windows and where, specifically, we know we don't want to have the app close when the last window closes. So we probably still need to retain defaults for more fine grained control over behavior rather than just forcing a microsoft style behavior. It's not a problem really to do both microsoft style behaviors and user defaults for fine control. I consider Gnome to be similar enough to Windows in its feel (though not in its look) to warrant a behavior akin to Windows for it. [...] Anyway ... see what you think of the change to allow unhide by showing the app icon when the app is hidden, and think about how it would be if, instead of showing that, what we actually did was show a miniaturised version displayed in whatever way the window manager normally handles miniaturised windows (eg in a task bar). Well, it is certainly not what *I* would expect from a hide application command in a Gnome or KDE environment; but then, I'm using GNUstep primarily with Apple's quartz-wm on OS X and with WindowMaker on other platforms and therefore do not care much. I mainly opposed to your proposal because it appeared to me as introducing more brittle code in -back, which I would like to see avoided, but your actual change is not of that sort and so it is okay for me. Wolfgang P.S.: I just saw in the commit logs that you added a new library license to the svn tree, but made it impossible to check this out for us who are using a less capable operating system (OS X), which uses a case-insensitive file system by default. Please, never use files like License.m and license.m, whose names differ only in their case, in the same directory. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 17 Oct 2009, at 00:01, Wolfgang Lux wrote: With respect to problem (2), I think that this could be handled by terminating applications by default when their last window is closed and the application delegate does not respond to - applicationShouldTerminateAfterLastWindowClosed:. I was going to suggest this as the default behaviour for NSWindows95InterfaceStyle (actually, I was going to implement it and see if it worked nicely, but I haven't had time). Most of the time, this is how people expect document-driven applications to work in Windows and Windows clones like GNOME and KDE. The current behaviour of moving the menu to the top of the screen is really jarring in these applications. I would suggest the following rules for the Windows interface style: - When an application is first launched, a new document is automatically created, if no window created by the main nib file is willing to accept main window status. - When closing a window, if no other window is willing to accept main window status then the application exits. I think this would go a long way towards making GNUstep apps fit in with other environments. David -- Sent from my STANTEC-ZEBRA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
David Chisnall wrote: On 17 Oct 2009, at 00:01, Wolfgang Lux wrote: With respect to problem (2), I think that this could be handled by terminating applications by default when their last window is closed and the application delegate does not respond to - applicationShouldTerminateAfterLastWindowClosed:. I was going to suggest this as the default behaviour for NSWindows95InterfaceStyle (actually, I was going to implement it and see if it worked nicely, but I haven't had time). Most of the time, this is how people expect document-driven applications to work in Windows and Windows clones like GNOME and KDE. The current behaviour of moving the menu to the top of the screen is really jarring in these applications. I would suggest the following rules for the Windows interface style: - When an application is first launched, a new document is automatically created, if no window created by the main nib file is willing to accept main window status. - When closing a window, if no other window is willing to accept main window status then the application exits. 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. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 17 Oct 2009, at 12:04, Philippe Roussel wrote: On Sat, Oct 17, 2009 at 07:02:12AM +0100, Richard Frith-Macdonald wrote: It sounds reasonable to allow interface style to control that sort of thing, and the behavior you suggest makes sense for a windows app. I'm not sure it addresses the original case though ... which was not for an app running on windows and where, specifically, we know we don't want to have the app close when the last window closes. So we probably still need to retain defaults for more fine grained control over behavior rather than just forcing a microsoft style behavior. It's not a problem really to do both microsoft style behaviors and user defaults for fine control. Just for the record, I like the vertical menus :o) Anyway ... see what you think of the change to allow unhide by showing the app icon when the app is hidden, and think about how it would be if, instead of showing that, what we actually did was show a miniaturised version displayed in whatever way the window manager normally handles miniaturised windows (eg in a task bar). It works for me (under Metacity), thanks Richard ! I think this is a big step for better integration. I would prefer something to appear in the task bar instead (so demanding...) of the appicon but it's a start. I'm glad that the partial fix helps, but I'm afraid I'm going to have to withdraw the idea of using the standard miniaturise/deminiaturise behavior to integrate with window managers. I made that proposal based on the assumption that window miniaturisation and deminiaturisation works, but when I actually tried to use it, I found it really doesn't in the current gnustep implementation :-( In the first place, the method to inform the gui that a window had been deminiaturised was not being called, and there was actually no event defined for the backend to pass this information to the frontend. I added the event event type so that the backend could tell the frontend about deminiaturisation, and then went to look at changing the backend to send it, and this is the point where, after hours of investigation I just had to give up ... it seems that the X-windows system simply doesn't provide any mechanism for you to know that a window has been deminiaturised. If the backend doesn't know, it can't tell the frontend, and if the frontend doesn't know, it can't send the notification it's supposed to send ... which means we can't have code in the frontend waiting for the app icon window to be deminiaturised and trigger an unhide operation. This is all very sad. Now, I suppose it ought to be possible to figure out a way to reliably lock frontend and backend together so that the backend can infer a deminiaturisation from a particular sequence of events, but sorting out that sort of interaction is beyond me right now ... it seems that when a window is ordered in, it's pretty indistinguishable from a window being deminiaturised. One option might be to scrap the backend miniaturisation/ deminiaturisation API entirely, and have the frontend strictly implement that using the window/miniwindow counterpart pairing. So to miniaturise a window, we order in the counterpart miniwindow (implicitly ordering the main window out), and to deminiaturise the window, we order it in (implicitly ordering the miniwindow out), and let the backend decide what it's going to do about the way it displays that on-screen. In the case where we don't have real counterpart miniwindows because the window manager is actually just putting labels on a taskbar, i guess the backend could provide some sort of dummy placeholder. Anyway .. that's just an idea ... don't know how much it would really help simplify things. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 18/10/2009, at 02:45 , Richard Frith-Macdonald wrote: On 17 Oct 2009, at 12:04, Philippe Roussel wrote: On Sat, Oct 17, 2009 at 07:02:12AM +0100, Richard Frith-Macdonald wrote: It sounds reasonable to allow interface style to control that sort of thing, and the behavior you suggest makes sense for a windows app. Just for the record, I like the vertical menus :o) Anyway ... see what you think of the change to allow unhide by showing miniaturised windows (eg in a task bar). It works for me (under Metacity), thanks Richard ! I think this is a big step for better integration. I would prefer something to appear in the task bar instead (so demanding...) of the appicon but it's a start. One option might be to scrap the backend miniaturisation/ deminiaturisation API entirely, and have the frontend strictly implement that using the window/miniwindow counterpart pairing. So to miniaturise a window, we order in the counterpart miniwindow (implicitly ordering the main window out), and to deminiaturise the window, we order it in (implicitly ordering the miniwindow out), and let the backend decide what it's going to do about the way it displays that on-screen. In the case where we don't have real counterpart miniwindows because the window manager is actually just putting labels on a taskbar, i guess the backend could provide some sort of dummy placeholder. Anyway .. that's just an idea ... don't know how much it would really help simplify things. 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. Regards, Sheldon Checked for Virus & Spam by West Australian Networks Internet Service Providers see www.westnet.net.au ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
