Re: "floating panel" window type
- From: Havoc Pennington <hp redhat com>
- To: Haavard Kvaalen <havardk xmms org>
- Cc: wm-spec-list gnome org, <bill gkrellm net>, <peter xmms org>, <jakdaw xmms org>, <notting redhat com>
- Subject: Re: "floating panel" window type
- Date: 17 Jun 2002 21:27:24 -0400
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.
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.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]