Re: "floating panel" window type

[Lubos Lunak <l lunak sh cvut cz>]

On Tuesday 18 June 2002 03:27, Havoc Pennington wrote:
> Haavard Kvaalen <havardk xmms org> writes:
> > On 16 Jun 2002, Havoc Pennington wrote:
> > > Assuming panels are always on top, a change I'm planning, XMMS and
> > > gkrellm could probably just set their type to DOCK and go with that,
> > > just like a panel. The one problem there is that DOCK windows are
> > > never decorated.
> >
> > kwin has a non-standard _NET_WM_STATE atom called
> > _NET_WM_STATE_STAYS_ON_TOP that XMMS will use if it is available.  This
> > does exactly what XMMS wants.  I like this approach better than setting
> > the type to DOCK.
>
> The difficulty with this hint from a window manager implementation
> standpoint is that STAYS_ON_TOP isn't really telling me "on top of
> what" - is it on top of fullscreen movies? ("sometimes", for a thing
> like xine) On top of its own dialogs? (no) Is it on top of panels?
> (maybe) Is it on top of splash screens? (probably not) What about on
> top of system-modal dialogs? (probably not) How about onscreen
> keyboards? (definitely no)
>
> So if we have that hint, it shouldn't be used for most of those
> on-top-ish things I just listed, but only for this particular kind of
> thing that xmms and gkrellm seem to be. At that point it's really
> identifying a type of window, not a state.
>
> I do think that a state might be nicer than a type, though, in that
> you can change it without unmapping the window.

 And you can also set it for any window. E.g. if I want to see a movie or the 
status of my PPP connection, I just set mplayer/kppp window to sticky and 
on_top. Changing window type just because I want it to be kept in a certain 
position for some time is weird.

>
> Maybe just _NET_WM_STATE_FLOATING is the right solution. A window that
> floats above other windows, but isn't really on top of everything,
> just on top of normal windows.

 That's just a name. And I personally think STAYS_ON_TOP explains better than 
FLOATING the purpose (FLOATING somehow makes me feel it will move and I'll 
have to chase that window on the desktop ;) ). Of course STAYS_ON_TOP doesn't 
have to mean always always always on top. It can be defined on top of what 
the windows have to be.

 If I look at the list you made above:
> - is it on top of fullscreen movies? ("sometimes", for a thing
> like xine)
 I guess that 'movies' is supposed to be 'windows'. Right now KWin doesn't put 
stays_on_top windows above active fullscreen windows (because active 
fullscreen windows are internally made temporarily stays_on_top too). 
Probably they should be placed above fullscreen windows, and those 
never-put-anything-above-me should be stays_on_top too.

> - On top of its own dialogs? (no)
 Of course not. KWin has a little problem here with non-modal dialogs though.

> Is it on top of panels? (maybe)
 It's yes with KWin. If the user puts the window there, they probably want it 
to be above the panel.

> Is it on top of splash screens? (probably not)
 *shrug* What is a splashscreen ? >;)

> What about on
> top of system-modal dialogs? (probably not) How about onscreen
> keyboards? (definitely no)

 How exactly are these two described (i.e. window type, etc)? 



 So I think we can have defined _NET_WM_STATE_STAYS_ON_TOP as:

 - it's undefined when there are two stays_on_top windows at the same position 
(the WM should probably put more recently active windows above the less 
recently active ones)
 - not on top of all windows that are transient for it
 - on top of all other windows, maybe except for some types (DIALOG, SPLASH, 
MENU, TOOLBAR and FULLSCREEN ?)

 Hmm, even shorter that I expected. Does anybody see a problem with it?

> Havoc

-- 
 Lubos Lunak
 l lunak email cz ; l lunak kde org
 http://dforce.sh.cvut.cz/~seli