Re: Miniaturize a panel

[Christopher Armstrong]

Hi Wolfgang

On 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'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.

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. 
* _NET_WM_WINDOW_TYPE_UTILITY for normal panels will probably help, as
should NET_WM_WINDOW_TYPE_DIALOG for modal dialog panels. 
* 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.

Cheers
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au

-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au