Re: 1.9d
- From: Dan Winship <danw mit edu>
- To: wm-spec-list gnome org
- Subject: Re: 1.9d
- Date: 13 Dec 1999 09:57:10 -0800
> Erm... What I mean is that Pagers MUST NOT delete or insert desktops
> themselves. If they want the number of desktops to be altered (by the
> WM), they MUST send the INSERT/DELETE message.
OK. But there are other cases where you say the Pager MUST do foo, when
the thing you're talking about is the only possible way the Pager could
do it.
> If the Pager tries to set the viewport to an arbitrary x,y, and the WM
> does not support it, then the WM should probably round to the nearest
> viewport. The Pager will know that its request was not honored exactly by
> watching the VIEWPORT property and seeing what it gets set to. Do we need
> a more positive whole-viewports-only type hint?
What if the nearest viewport available is the one it's currently on? I guess
you can just require that the wm has to "change" the property anyway, even
if it's not changing the value of it, so the Pager can see the PropertyEvent
and see if it won.
> _NET_ACTIVE_WINDOW essentially means "Taskbar wants to work with this
> window".
...
> > _NET_WM_STATE_SKIP_TASKBAR: Should TASKBAR be PAGER?
>
> Hmm. SKIP_TASKBAR windows should probably show up on a Pager, just not a
> TaskBar.
Should the spec really be defining the behaviors of these various objects
that specifically? What if I want to implement something that's sort of like
a pager and sort of like a taskbar and sort of like a banana? Do I just lose
because now all new apps are going to expect the world to be divided into
apps, WMs, pagers, and taskbars and nothing else?
> > _NET_WM_STATE_SHADED: What does "shaded" mean?
>
> Whatever the WM wants it to mean. Usually it means that just the titlebar
> is visible.
Oh, that kind of shaded! I was imagining windows having their colormaps
changed to be darker for some reason. More terminology fun.
-- Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]