Re: Addition for pager layout.

On Sat, Dec 01, 2001 at 07:22:30PM -0500, Havoc Pennington wrote:
> Waldo Bastian <bastian kde org> writes: 
> > Isn't the normal sequence that after receiving the client message that the 
> > window manager subsequently publishes it as a property? I'm not that deep 
> > into this stuff, but isn't that how e.g. the number of desktops works? In 
> > that case the window manager could read back this property when it 
> > (re)starts, would that work?
> The number of desktops is just a window manager configuration option
> that the WM publishes; there's no way to ask the WM to change the
> number of desktops, unless I'm totally forgetting something.

I think you forget something. The number of desktop property SHOULD
be set and updated by the Window Manager, but "A Pager can request
change in the desktops number by sending a _NET_NUMBER_OF_DESKTOPS
message to the root window". Others properties as 


work like this.

> The desktop layout should probably end up in a property somehow,
> yeah. Most root window properties are owned by the window manager,
> since it's guaranteed that only one window manager can run at once.
> We could say that the client message asks the WM to change the desktop
> geometry, and the actual geometry should be read from the property. In
> that case pagers should always be written in model-view fashion (they
> ask to change the geometry, but always display the geometry from the
> property, instead of assuming their change succeeded).
> Should probably define what the WM is supposed to do when no client
> message has been received (i.e. what is the default?)

Maybe no default at all is good: by default virtual desktops maybe
seen as independent screen without layout in between them. In fact
what it is proposed with this desktops layout is to give to
virtual desktops some properties that a large desktop have
in a natural way. And in fact if both large desktop and multiple
desktops is used this layout between desktops can leads to some
confusions. But I am afraid that GNOME 2 neither KDE >= 2 pagers
(will) never support large desktop and use only multiple virtual
desktops, so I understand why Waldo and Havoc like this layout 
property :o) (I am not against it).

> In GNOME users are allowed to have 8 panels with different
> orientations and a pager in each one, I'm not sure what happens
> then. ;-)

Virtual desktops without layout? The good default IMHO. And if one
want electric borders a solution is to use large desktop (and maybe
only one desktop for users that think that having both large desktop
and multiple desktops is too complicated)?

> Also, on desktop login, there's a race condition where you require the
> WM to finish launching before the pager sends its client message.
> Obviously the desktop environment can do that, I'm not sure either one
> really does right now. (Both launch the WM first, but neither waits
> for the WM to definitely be done starting before proceeding, IIRC.)
> Another option is that the way of requesting the new desktop layout be
> left undefined (desktop-specific), but we just standardize how the WM
> will advertise the actual desktop layout on the root window via
> property. Then pagers are required to follow what the property
> contains, but desktops can implement ways of auto-configuring certain
> window managers as the panel moves. This leaves some freedom to do
> things like make the layout a config option instead of a function of
> panel orientation.
> I'm not sure what's right. Anyone else have an opinion?

An other (better IMHO) solution is the following:
_NET_DESKTOP_LAYOUT is a root property that may (or should but
not must) be maintained by the window manager. A pager can
have an "Application Window Property" _NET_PAGER_DESKTOP_LAYOUT
which describes the desktop layouts that it wants.
The pager may change this property at anytime, therefore the wm
should watch out for property notify events. 
The wm may/should set the _NET_DESKTOP_LAYOUT as indicated by
the _NET_DESKTOP_PAGER_LAYOUT property set on client windows
(if 2 windows have this property and are inconsistent it can
choose to ignore one or to do not set _NET_DESKTOP_LAYOUT).
This solution solves the login race condition and others.
I think it is better because it works without a desktop

Regards, Olivier

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]