|
From: | Wolfgang Lux |
Subject: | Re: Miniaturize a panel |
Date: | Thu, 17 Mar 2011 09:49:44 +0000 |
Christopher Armstrong wrote:
Hi WolfgangOn Wed, 16 Mar 2011 10:34 +0000, "Wolfgang Lux" <address@hidden >wrote:Germán Arias wrote:With native decoration, trying to miniaturize a panel don't work (I'mtrying on GNOME). Sometimes works, but this is a odd behavior.Quoting Apple's User Interface Guidelines: “A user would never need tominimize a panel because it is displayed only when needed and disappears when its application is inactive. Therefore, the minimize button is always unavailable. A panel should have the close and zoombuttons or, if you don’t want users to be able to use the zoom button,only the close button.” (http://developer.apple.com/library/mac/#documentation/ UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/ XHIGWindows.html%23//apple_ref/doc/uid/20000961-TPXREF17). So the problem is that GNOME's window manager displays a miniaturize button in the first place (incidentally, I observed this behavior under KDE and not under GNOME, but then I'm not using either of these environments regularly). The problem is that -back uses Motif style window manager hints to tell the window manager about the intendedwindow decorations and in addition maps window levels onto EWMH windowtypes. Unfortunately, the EWMH standard gives window managers a lot(too much?) of freedom about how to decorate windows and in particularallows them to completely ignore Motif style window manager hints and we end up with panels that are not prepared (or supposed) to be miniaturized but do have a miniaturize button.I'd disagree that EWMH gives window managers too much freedom about window decoration (the point of a window manager is to dictate consistent window decoration policy, not clients), but I'm in theopposite camp that believe EWMH is a good thing and that we should workwith it, not ignore it.
I once used to believe that EWMH is a good thing, but having used at least four different window managers that are (or least claim to be) EWMH complaint, I just cannot help concluding that the standard is just rather unspecific in a lot of respects and window decorations is just one of them. To the standard just looks like a mash up of the least common denominator of features supported by GNOME's and KDE's window managers.
Ignoring all that, you said that panels *never* have a minimise button (according to Apples HIG). If that is true, we should be checking forthe NSMiniaturizableWindowMask in the backend, and using some other EWMHhints such as:* _NET_WM_STATE_SKIP_TASKBAR. We can request this so the panels do notappear in the taskbar, which would (hopefully) mean that it cannot be miniturised i.e. whats the point of miniaturising a window if the user can't restore it again.
Your "hopefully" exactly states the problem: The EWMH standard just doesn't specify when a window managers is supposed to display a miniaturize button and when it shouldn't.
* _NET_WM_WINDOW_TYPE_UTILITY for normal panels will probably help, as should NET_WM_WINDOW_TYPE_DIALOG for modal dialog panels.
Once again, the standard is silent about whether such dialogs have a miniaturize button or not.
* ICCCM's WM_TRANSIENT_FOR should also also be enough to indicate thatpanels are not normal windows - it should be enough to set this hint to point to the main window or the menu window if it is present. Note thatthis hint is a "nice to have" and not a "need to have" if we are only considering EWMH support. I think the problem at the moment is that we use only window levels todetermine the EWMH hints, and the window masks to determine Motif hints,when we probably need something more sophisticated for EWMH that considers both window levels and window masks. Abandoning EWMH altogether I think is a rash decision, especially if newer window managers decide not to support Motif hints.
Wolfgang
[Prev in Thread] | Current Thread | [Next in Thread] |