Re: Proposal: _NET_WM_STATE_MINIMIZED

[Lubos Lunak <l lunak suse cz>]

On Thursday 17 of June 2004 19:29, Havoc Pennington wrote:
> On Thu, 2004-06-17 at 05:04, Lubos Lunak wrote:
> >  I personally think the simplest solution would be dumping all this mess
> > and starting over from scratch. And the current state is a mess. The
> > meaning of STATE_MINIMIZED would be simple - a minimized window is a
> > window explicitly hidden by the user (to taskbar, desktop icon,
> > wherever). Can anybody tell me how to currently represent this state
> > (http://bugs.kde.org/show_bug.cgi?id=81271)? Because I don't know.
>
> "window hidden by the user" is pretty much how HIDDEN is already
> defined. If you define MINIMIZED that way, it's the same as HIDDEN in
> the spec now.

 Is it? HIDDEN means hidden in any way. MINIMIZED is when I click that little 
button near the upper-right corner, which makes the window to be gone and 
accessible only using the taskbar or things like Alt+Tab.

>
> The problem here I guess is that both KWin and metacity set HIDDEN for
> shaded windows, i.e. we've decided that shading a window means the
> window "would not be visible on the screen if its desktop/viewport were
> active and its coordinates were within the screen bounds" in the
> language of the spec. Maybe this is a questionable decision.

 These days everything with X is a questionable decision I'm afraid :-/.

>
> You have to decide what you want the "minimized" indicator in the task
> bar to mean. Do you want it to mean any hiding of the window including
> shaded, or do you want to have some kinds of hiding be special. If we
> want some kinds to be special, we have to define those kinds and create
> a state for them. So that's what MINIMIZED could be.

 Come on, everybody knows what a minimized window is. That button in the 
upper-right corner, you know :). If the spec has SHADED, why not MINIMIZED?

> > - shaded window - WM_STATE is Iconic, STATE_HIDDEN, STATE_SHADED
>
> Maybe we shouldn't do STATE_HIDDEN here, and clarify that in the spec.

 Or maybe we should, just like Elijah says. That way it'd be actually easier 
to extend things. After somebody invents some new way of hiding windows, 
pagers/etc. would still work despite not knowing the specific state. I think.

>
> >  Which means
> > - iconic != minimized
> > - there's no good way how to recognize the minimized state (see the KDE
> > bug)
>
> I don't think you've defined "minimized" adequately.
>
> The basic issue here is that we *don't* assume the Windows-style
> minimized/maximized/normal three-state model. Even GNOME/KDE introduce
> shaded as well, and other WMs do more strange things. So you can't just
> assume we know what "minimized" is. We currently define HIDDEN as
> "anything that hides the window, except workspaces" - we could add
> "except shaded" perhaps.
>
> > - the iconic state itself probably doesn't make much sense, as it doesn't
> > have any clear meaning, or even something close - you can e.g. have a
> > window in NormalState that's not actually visible because it's on
> > inactive virtual desktop with WM that doesn't unmap in such case, and
> > only its iconic representation (=taskbar entry) is visible. Moreover one
> > can in practice achieve the same with simply obscuring the window by
> > another one, so I kind of fail to see the point of the iconic state[*].
>
> IconicState is still used for state transitions; i.e. asking to move in
> and out of IconicState with ICCCM mechanisms means to "minimize" /
> "unminimize"
>
> Also, IconicState/NormalState are required to match the map status of
> the window. There's some reason this is useful I think, but I don't
> remember it.

 I have no proof, but I personally think that the only purpose 
NormalState/IconicState were meant to server was to represent 
normal/minimized state (and the fact that the window is managed, indeed). If 
you look at Xutil.h, it has also the obsolete states like ZoomState 
(=maximized), so I think WM_STATE was basically meant like our _NET_WM_STATE, 
it just wasn't a bitfield, and it degenerated to only two useful states.

 Moreover Normal/IconicState and the relevant things are defined in a way 
which doesn't allow much of extending, so now we're trying to bend it to fit 
the current needs.

 For example, what does currently IconicState mean? "The window is hidden, but 
I don't know why, and I can't also guarantee that NormalState actually means 
the window is visible, so, in fact, all I can tell you is that I can't tell 
you anything." Or the transitions - if a window is shaded or on another 
virtual desktop (and is in IconicState), what should a request to change to 
NormalState do? Unminimize? It will be a no-op then. Or should it act like 
our _NET_ACTIVE_WINDOW message?

 I think currently WM_STATE can serve only two purposes - marking the window 
as managed, and having the transition requests as messages "show me", which 
we already have as _NET_ACTIVE_WINDOW, and "hide me" (somehow), for which we 
don't have anything yet but maybe we should.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/