|
| From: | Richard Frith-Macdonald |
| Subject: | Re: Window manager interaction |
| Date: | Sat, 17 Oct 2009 07:02:12 +0100 |
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 hidecommand should just minimize all application windows. As far as Iunderstand 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 forthe term "hide" (with quotation marks) in that document. This can beimplemented 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 menucommand from another GNUstep application.
We could simply ignore this requestsince the native applications of the foreign gui environment do not understandthat 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 theoffscreen appicon. In my opinion back is already bloated too much with conditionalcode 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 adifferent 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 suppressed, the icon is shown so that you can click on it to unhide again. Implementing 2(a) would not require any additional backend work ... it would just leverage the existing minwindow code. Implementing 2(b) would be the messy option,but it may not be needed for most environments ... and where environments do require us to adopt their conventions for hiding/unhiding, we really do need to do that rather than just having a miniatuires/deminiaturise option to avoid the issue. Of course, in some environments the behavior you select would actually be the native behavior ... in which case we would presumably want to adopt that there and remove the 'hide' menu item.
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).
| [Prev in Thread] | Current Thread | [Next in Thread] |