Christopher Armstrong wrote:
Hi Wolfgang
On Wed, 16 Mar 2011 10:34 +0000, "Wolfgang Lux" <[email protected]
>
wrote:
Germán Arias wrote:
With native decoration, trying to miniaturize a panel don't work
(I'm
trying on GNOME). Sometimes works, but this is a odd behavior.
Quoting Apple's User Interface Guidelines: “A user would never need
to
minimize 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 zoom
buttons 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 intended
window decorations and in addition maps window levels onto EWMH
window
types. Unfortunately, the EWMH standard gives window managers a lot
(too much?) of freedom about how to decorate windows and in
particular
allows 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 the
opposite camp that believe EWMH is a good thing and that we should
work
with 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 for
the NSMiniaturizableWindowMask in the backend, and using some other
EWMH
hints such as:
* _NET_WM_STATE_SKIP_TASKBAR. We can request this so the panels do
not
appear 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 that
panels 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
that
this 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 to
determine 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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
