Re: How to temporarily hide a window

[Lubos Lunak <l lunak suse cz>]

On Tuesday 10 of June 2003 16:02, Ben Jansens wrote:
> On Tue, Jun 10, 2003 at 10:40:09AM +0200, Lubos Lunak wrote:
>
> [...]
>
> > all the state etc. properties reset? I can think of few solutions, but
> > none of them is very good:
> > - have the app remember the state. This can't really work, because the
> > app doesn't who which properties to save.
>
> If going strictly by the spec, it would be the DESKTOP and STATE hints only
> which are removed, but only the STATE hint would need to be saved here I'm
> thinking.

 But what if there will be one day some other property what will have to be 
saved?

>
> If you persist the STATE in the WM based on the window's
> name/class/role/etc, then it could be restored at that point. OTOH, this
> on-top state is being set by the application the first time it maps, why
> not just set it the same way when it re-maps?

 Because it's not set by the application. The user set it using the WM. Or 
using the pager. Or whatever.

>
> > - minimize the window. This doesn't help much either, because it leaves
> > the taskbar entry.
> > - set SkipTaskbar and minimize the window. This leads to somewhat stupid
> > API, both because there are two ways of hiding a window, and because one
> > has to remember the SkipTaskbar state for the restore operation.
>
> yea these are ugly :(
>
> > - it could use _NET_WM_STATE_HIDDEN. This could IMHO actually work, if
> > the spec didn't suggest that this is WM-only internal flag, and the
> > clients shouldn't touch it.
>
> This would definitely the nicest approach if it would work, but it would
> end up giving it a double meaning.
>
> If there was some hint available that clients could set on themselves to
> say "I respect the EWMH!", or even "I'm good for EWMH <= 1.2!" then perhaps
> we could not erase the DESKTOP/STATE hints from those windows. We'd need to
> specify exactly what a client is responsible for that set it though
> somewhere in the spec (i.e. erasing DESKTOP/STATE on an unmap/map unless it
> *means* for them to persist).

 I think this option is the most complicated of all. There's a reason why the 
properties are removed. There are apps that e.g. keep a dialog created, and 
when they need it, they only show it, and then hide it, without destroying 
it. Such dialog needs to be treated as "new" everytime it's mapped. And 
finding out when to do so and when not would be way too much work I'm afraid.

-- 
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/