Re: ICCCM breakage, IconicState, and desktops

["Matthias Clasen" <matthiasc poet de>]

> >
> > That actually creates interesting question that may be
SKIP_PAGER/TASKBAR
> > should be moved into _NET_WM_TYPE, and instead _NET_WM_STATE_HIDDEN
> > should be added. Thats separate discussion though.
>
> This is a possible alternative to a MINIMIZED hint.
> You raise an interesting issue - are SKIP_PAGER/SKIP_TASKLIST supposed
> to be set by the window manager or the app? I always assumed they were
> for apps to control. What do most current window managers assume?
> Do any current window managers e.g. set SKIP_PAGER when they minimize
> an app?

It clearly is a signal to the the pager/taskbar, but exactly who would send
this seems a bit dubious, since it is really just a piece of configuration
for the pager/taskbar.  I definitively wouldn't expect the wm the set it for
minimized windows. If we would allow/demand that, then we would have to
explicitly forbit clients from setting it themselves, otherwise users would
be confused by the following cause of actions:

configure app x to be "skip_taskbar" in x's preferences
  --> x is gone from the pager, fine
iconify x
  --> x keeps absent from the pager, fine
deiconify x
  --> x reappears in the pager, since the wm removed skip_taskbar, oops

Matthias

its a part of _NET_WM_STATE and that as all EWMH app window properties are
set by the wm and can be changed by the client via a ClientMessage to root.

>
> If SKIP_PAGER is being treated as a message from window manager to
> pager, then yes it solves our problem - we can specify that pagers
> should display all windows that are not SKIP_PAGER, even if the
> windows are in IconicState.
>
> If SKIP_PAGER isn't that, we could add _HIDDEN which is such a message
> from WM to pager.
>
> Hmm, even the current spec needs some clarification here. I'm guessing
> we should just do whatever KDE is doing in their current implementation.
>
> > Really try and define what exactly "minimized" state is, and you'll see
that
> > it either indistiguishable from ICCCM defined IconicState, or requires
> > additional information to be meaningfull.
>
> The MINIMIZED state would mean the window is minimized - that's it.
>
> IconicState means the window is unmapped as spec'd in the ICCCM -
> that's it.
>
> By convention, when apps request a transition to/from IconicState, we
> would assume they meant to minimize/unminimize themselves, assuming
> they are currently minimized; if they weren't minimized but
> IconicState for some other reason, the WM would ignore them, or
> whatever makes sense for that WM to do.
>
> > Both IconicState<->NormalState transition and _NET_WM_STATE
> > transitions could be requested by client using ClientMessage. For
> > example e-mail client can attempt to deiconify self when new mail
> > arrives. I can just imagine it requesting deiconification when in
> > fact it was simply moved off-desktop, and it should have instead
> > requested wm to move it onto active desktop.
>
> Remember that clients don't deal with all this hints stuff directly;
> they are going via toolkits. We can just get it all right in the
> toolkit, as long as we agree on this list what constitutes "right."
>
> We have a function in GTK called gtk_window_present() which
> deiconifies, raises, moves to current desktop, all that stuff; usually
> this is the thing an app would call in the situation you describe.  We
> can also check if the WM supports a hint such as
> _NET_WM_STATE_MINIMIZED, and behave differently according to that
> check.
>
> Havoc