[Panel-devel] Task management in plasma

[Lubos Lunak]

On Sunday 27 of May 2007, Aaron J. Seigo wrote:
> On Saturday 26 May 2007, Richard Moore wrote:
> > - No separation of properties of the document from the properties of the
> >   task. In fact there is little or no support for storing the properties
> > of the document at all. Things like parsing '[modified]' from the window
> > title are hardly good enough!

 http://bugs.kde.org/show_bug.cgi?id=80834

> > - The interface provided by NET specification is the only means of
> >   communicating with a task manager. There is no DCOP or DBUS interface
> > that users or tools could use to control higher level facilities.

 For user scripting there is 
http://kde-apps.org/content/show.php/WMIface?content=40425 . I don't know 
what you mean by tools here - if I see applications using DBUS for window 
management I think I'm gonna yell.

> i'm really on the fence whether we should fix NET or add another layer of
> IPC to it all. and if we do add DBUS to the mix, where does the line get
> drawn between what should be in NETWM and what should be on the bus?

 I think it's simple: Nothing related to window management should be on the 
bus. Why? I can see a couple of reasons against (reinventing the wheel, 
blocking, private, to name a few) but I don't see any good reason for. And, 
quite frankly, I'd prefer not to have again to fix some private Kicker 
inventions like I've already had to several times.

 (Also note that when talking about the wm spec here, the e-word is extend, 
fix is off by one.)

> > - Support for transients is weak. I don't know if this really matters
> > though.
>
> i think we're ok with this right now.

 Supporting all the various almost-valid broken ways there are is rather 
non-trivial, the KWin code is a mess. You could possibly just do it the easy 
way and for harder cases use some info about it that KWin would export.

> > - Support for multiple screens is weak.

 What is the plan with Xinerama for Plasma? Kicker panels spanning more than 
one Xinerama screen complicate some things :-/.

> > If we define DBUS interfaces to these concepts then we gain the ability
> > to
>
> at least some of this probably could and even should be done using window
> manager hints. i'm still thinking about which ones should be which =)
> essentially, most of the problems we run into are the incredibly unuseful
> body of NETWM information. there is a policy right now that says that
> windows can only talk about themselves and only as it pertains to window
> management; so window relationships are not supported (and there has
> historically been push back on changing that)

 I'm not aware of anything like that.

> and there is little in the way of window state information.

 What would you need?

> perhaps if we go to the window manager people of the world with a cogent
> "this is what we need and why" we can get them to bend.
>
> this may meant that much of this would slide off until 4.1.

 Not necessarily.

> > provide facilities for richer integration. For example UIServer could
> > tell the task manager to overlay progress data, applications could
> > request particular groupings (eg. group the kwallet dialog with the
> > application that caused it to be launched).

 The KWallet dialog already provides info to be grouped with the application 
that's opened it.

> these are very nice ideas. i'd like to see something similar for many of
> the systray icon usages.
>
> > So, any comments?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz