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. 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? > - 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). Ben
Attachment:
pgpLknBxTBYVF.pgp
Description: PGP signature