Re: Window manager interaction
Fred Kiefer wrote: Richard Frith-Macdonald schrieb: [...] The documentation says: GSSuppressAppIcon A boolean value, NO by default. Specifies wether the application icon window should not be displayed. Set to YES for background server applications. I think the expectation is that, if you have set GSSuppressAppIcon to YES, it's because your app is not intended to appear on-screen (I think that's what 'background server' means), or that your window manager will be handling activation of the app some other way. The other default (GSAppOwnsMiniwindow) is the one which is supposed to control whether miniwindows are controlled by the application or by the window manager, and if that's set to 'NO' then (as I understand it) the miniwindows should not appear on the desktop. I'm not sure how well this works though. I haven't looked at the code for ages, but I suspect that the application icon window is handled as a special case and GSAppOwnsMiniwindow does not effect it (shouldn't that be GSAppOwnsMiniWindow rather than GSAppOwnsMiniwindow anyway?). I think the current code probably does the wrong thing with the app icon window... if it's suppressed then the app just doesn't create it, but it might make more sense for it to be created off-screen ... so that we still have the icon window but it's unseen. Then, we would always be able to minimise the icon window when we hide the app. If we did that then presumably the window manager would display a reference to the minimised icon window in whatever manner it normally displays minimised windows, and the window manager's mechanism for unminimising it would be able to unhide the application (we could have the gui watch for the icon window being unminimised and automatically unhide the app at that point). Would this be a workable way of curing this particular window manager interaction issue? First off, we already have a related bug report for this problem, #18199 and perhaps it would be best to add any further comments there, to make it easier to reference things later on. Your idea sounds feasible to me, we will of course need to add a bit more logic to it, for example only to minimize the hidden app icon window when there is no other window. And putting it off screen may not be enough for some window managers to not display it in there program bar or what ever they use. Also we need to make sure that the app icon window wont get show after activating its mini window. And of course this will have to work with all window managers out there... IMHO Richard's proposal is much too complicated. I'd suggest something radically simpler: If an application does not have an appicon the hide command should just minimize all application windows. As far as I understand this also was the solution used by Apple in OpenStep 4.2 for Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for the term "hide" (with quotation marks) in that document. This can be implemented trivially with the three-line patch below in NSApplication.m. NSApp.patch Description: Binary data Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On Fri, Oct 16, 2009 at 08:16:24PM +0200, Wolfgang Lux wrote: > IMHO Richard's proposal is much too complicated. I'd suggest something > radically simpler: If an application does not have an appicon the hide > command should just minimize all application windows. As far as I > understand this also was the solution used by Apple in OpenStep 4.2 for > Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for > the term "hide" (with quotation marks) in that document. This can be > implemented trivially with the three-line patch below in > NSApplication.m. I thought about that but what happens for document based application without a window ? Thanks, Philippe -- Un mari, c'est le gars qui vous soutient dans tous les problemes que vous n'auriez pas eus si vous ne l'aviez pas epouse. Caroline Ammerlaan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On Fri, Oct 16, 2009 at 09:30:07PM +0200, Philippe Roussel wrote: > On Fri, Oct 16, 2009 at 08:16:24PM +0200, Wolfgang Lux wrote: > > IMHO Richard's proposal is much too complicated. I'd suggest something > > radically simpler: If an application does not have an appicon the hide > > command should just minimize all application windows. As far as I > > understand this also was the solution used by Apple in OpenStep 4.2 for > > Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for > > the term "hide" (with quotation marks) in that document. This can be > > implemented trivially with the three-line patch below in > > NSApplication.m. > > I thought about that but what happens for document based application > without a window ? By the way, with your patch, the hide command leaves the application menu visible. Thanks, Philippe -- My mom had Windows at work and it hurt her eyes real bad. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 16 Oct 2009, at 19:16, Wolfgang Lux wrote: IMHO Richard's proposal is much too complicated. I'd suggest something radically simpler: If an application does not have an appicon the hide command should just minimize all application windows. As far as I understand this also was the solution used by Apple in OpenStep 4.2 for Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for the term "hide" (with quotation marks) in that document. This can be implemented trivially with the three-line patch below in NSApplication.m. Good idea, but unfortunately that approach does not really work and is not really that simple: 1. the app is not properly hidden ... there are potentially loads of miniwindows left visible 2. the app is potentially 'lost' (as at present) if it has no windows (and hence no miniwindows) 3. there is no consideration of unhiding ... allowing for that would require a lot more code (to track which windows were miniaturised as part of the hide process, and automatically deminiaturise them when you click on any of the miniwindows of the 'hidden' app). Problem (2) is the problem we currently have ... so this approach actually adds an issue (1) without solving the original issue. ___ 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 16 Oct 2009, at 19:16, Wolfgang Lux wrote: IMHO Richard's proposal is much too complicated. I'd suggest something radically simpler: If an application does not have an appicon the hide command should just minimize all application windows. As far as I understand this also was the solution used by Apple in OpenStep 4.2 for Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for the term "hide" (with quotation marks) in that document. This can be implemented trivially with the three-line patch below in NSApplication.m. Good idea, but unfortunately that approach does not really work and is not really that simple: 1. the app is not properly hidden ... there are potentially loads of miniwindows left visible 2. the app is potentially 'lost' (as at present) if it has no windows (and hence no miniwindows) 3. there is no consideration of unhiding ... allowing for that would require a lot more code (to track which windows were miniaturised as part of the hide process, and automatically deminiaturise them when you click on any of the miniwindows of the 'hidden' app). Problem (2) is the problem we currently have ... so this approach actually adds an issue (1) without solving the original issue. 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:. I see issue (3) as rather unproblematic. If the app is properly hidden, the user cannot invoke -unhide: in the first place except by selecting the Show All menu command from another GNUstep application. We could simply ignore this request since the native applications of the foreign gui environment do not understand that request and we would at least be consistent with our environment. But even if you are not happy with that suggestion, I'd really prefer to add the additional flag to every window that would allow distinguishing whether a window was miniaturized or "hidden" than to delve into the hairy interaction with lots of different window managers out there and trying to convince them to manage the offscreen appicon. In my opinion back is already bloated too much with conditional code that is supposed to work with WindowMaker, KDE, Gnome, and whats not. Yet, it nevertheless does not really work with, e.g., Apple's quartz-wm (Apple managed to implement the NETWM specification in completely weird ways, but that is a different story). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Philippe Roussel wrote: On Fri, Oct 16, 2009 at 09:30:07PM +0200, Philippe Roussel wrote: On Fri, Oct 16, 2009 at 08:16:24PM +0200, Wolfgang Lux wrote: IMHO Richard's proposal is much too complicated. I'd suggest something radically simpler: If an application does not have an appicon the hide command should just minimize all application windows. As far as I understand this also was the solution used by Apple in OpenStep 4.2 for Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for the term "hide" (with quotation marks) in that document. This can be implemented trivially with the three-line patch below in NSApplication.m. I thought about that but what happens for document based application without a window ? By the way, with your patch, the hide command leaves the application menu visible. Ummm, yes. I have tried the patch only in combination with setting the interface style to NSWindows95InterfaceStyle, in which case there is no separate menu. I'll try to have a look at that tomorrow (err, today). 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 00:01, Wolfgang Lux wrote: Richard Frith-Macdonald wrote: On 16 Oct 2009, at 19:16, Wolfgang Lux wrote: IMHO Richard's proposal is much too complicated. I'd suggest something radically simpler: If an application does not have an appicon the hide command should just minimize all application windows. As far as I understand this also was the solution used by Apple in OpenStep 4.2 for Windows. See, e.g., http://support.apple.com/kb/TA45871 and search for the term "hide" (with quotation marks) in that document. This can be implemented trivially with the three-line patch below in NSApplication.m. Good idea, but unfortunately that approach does not really work and is not really that simple: 1. the app is not properly hidden ... there are potentially loads of miniwindows left visible 2. the app is potentially 'lost' (as at present) if it has no windows (and hence no miniwindows) 3. there is no consideration of unhiding ... allowing for that would require a lot more code (to track which windows were miniaturised as part of the hide process, and automatically deminiaturise them when you click on any of the miniwindows of the 'hidden' app). Problem (2) is the problem we currently have ... so this approach actually adds an issue (1) without solving the original issue. 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 see issue (3) as rather unproblematic. If the app is properly hidden, the user cannot invoke -unhide: in the first place except by selecting the Show All menu command from another GNUstep application. We could simply ignore this request since the native applications of the foreign gui environment do not understand that request and we would at least be consistent with our environment. Well, *normally* (for us) you can unhide by clicking the app icon, and *normally* in other environments there is a way to select/activate an application easily/quickly. I think, form a usability point of view it's desirable to keep that somehow and it's what my proposal was trying to do (and I think it's what Philippe as asking for. But even if you are not happy with that suggestion, I'd really prefer to add the additional flag to every window that would allow distinguishing whether a window was miniaturized or "hidden" than to delve into the hairy interaction with lots of different window managers out there and trying to convince them to manage the offscreen appicon. In my opinion back is already bloated too much with conditional code that is supposed to work with WindowMaker, KDE, Gnome, and whats not. Yet, it nevertheless does not really work with, e.g., Apple's quartz-wm (Apple managed to implement the NETWM specification in completely weird ways, but that is a different story). I don't really want to do lots of window manager specific code either (well, keep it to a minimum anyway), but it's one of our official stated aims to integrate well into other environments, so I expect some of it will be inevitable. However, my proposal was to avoid it as much as possible by using existing mechanisms. 1. keep the app icon but hide it if it's 'suppressed' (I changed NSApplication to do that) 2. (a) use the existing code for window managers to handle miniaturised windows to provide a handle to unhide the application, or (b) if the 'native' window manager has another unhide mechanism, use that. Maybe the change (1) is sufficient for Philippe though ... if you hide an app which has the icon su
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
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
