Fwd: Pager and Desktop Layout

[Jason Kasper <vr movingparts net>]

Keeping this on-list...

--

-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-

-[ KDE PIM Developer         //  http://www.kde.org  ]-

-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-

Begin forwarded message:

From: Martin Gräßlin <mgraesslin kde org>
Date: August 2, 2011 4:53:18 AM EDT
To: Ryan Beasley <ryan beasley+foss gmail com>
Cc: Jason Kasper <vr movingparts net>
Subject: Re: Re: Pager and Desktop Layout

On Tuesday 02 August 2011 01:16:15 you wrote:

In fact the pager plasmoid is stopping to use the manager selection and not setting the

desktop layout any more. The desktop layout is initially set by kwin and can be updated

through the multiple desktops kcm. If other processes change the desktop layout KWin

will

adjust the layout though it may be that the setting change is lost when restarting KWin.

In general I would say that the behavior if changes to desktop layout are not done through

the

expected way is undefined.

Hm. This poses a problem for me. One of the products I work on depends on

being able to reconfigure the desktop layout in a desktop environment/window

manager-agnostic manner. The idea is that the properties of the destination

desktop session are to (temporarily) be in sync with a source desktop

session. In my particular case, I'm not concerned with persisting the

settings across sessions, so not having them saved as part of the KDE

settings store isn't a problem.

May I ask why exactly you need to adjust the desktop layout? Maybe it is just the wrong
approach? In our opinion the desktop layout belongs to the desktop shell and should therefore
only be changed by the desktop shell and not by any third party process.

Even without this change on our side the behavior was more or less undefined as the
settings would not have been persisted and most likely the pager plasmoids would not have
updated their view.

If controlling the atom via _NET_DESKTOP_LAYOUT *does* go away, I'd very

much love to see a generic mechanism (e.g. D-Bus?) replace it, else I have

to add another implementation that knows how to speak KCM (I guess?).

The atom is still used and in fact our KCM does nothing else then changing the atom.
Nevertheless I highly recommend to not change this atom from a 3rd party application as that
changes the state of the desktop shell and can lead to user problems especially as the
changes of 3rd party applications are not persisted.

Handling to support and drive GNOME/KDE/kwin4/Metacity/Compiz/etc. all

separately is a major pain in the rear. wm-spec bits, at least when they're

supported correctly, makes my job much easier. :)

Yes I know that wm-spec is not really helpful - one reason why we decided to abandon one
of the more idiotic parts ;-)

Cheers
Martin

- Ryan