[Panel-devel] Task management in plasma

[Lubos Lunak]

On po 28. května 2007, Aaron J. Seigo wrote:
> On Monday 28 May 2007, Lubos Lunak wrote:
> > On Sunday 27 of May 2007, Aaron J. Seigo wrote:
> > > On Saturday 26 May 2007, Richard Moore wrote:
> > > > - 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.
>
> we more or less manage this ok in libtaskmanager already... at least i
> haven't received bug reports on the transient handling in there.

 Fair enough. But see below :).

> > > > - 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 :-/.
>
> yes, i'm dropping this "feature" since it breaks far too easily, e.g. if
> the screens are of different resolutions then the math gets funny =) plasma
> will be sticking to a policy of "each Corona (that's the graphicsview
> container we're using) will be on one and only one screen at a time"

 But this doesn't apply to the desktop itself (a'la kdesktop), does it?

> hm.. speaking with others who have tried to get things like (for example)
> the ability for a dialog to say "i'm the modal dialog for that specific
> window" for the purpose of having the window manager be able to make that
> dialog appear as a macOS style sheet have been turned down...

 There is support for saying "this window is my main window" and "I'm a modal 
dialog", so unless you'd need something more, this should be already 
possible.

> if this is 
> not the case anymore, then i would love to see a few bits of information
> added to NETWM that can optionally be used by windows to note their
> relationships to other windows directly.

 The wm spec list is these days a bit ... dozy. I expect getting reasonable 
additions should be mainly a question of enough manpower to push it in.

> > > and there is little in the way of window state information.
> >
> >  What would you need?
>
> at least:
>
>  - modification states (modified, read only, encrypted/secure, etc)

 This one shouldn't be a big problem I hope. There could be possibly some 
resistance because this could easily turn into a dumpground for all kinds of 
insane flags though.

>  - documents (help with mdi)

 This would need to be more precise.

>  - modal relationships

 The current practice is to use transiency and window group for this. I.e. a 
modal dialog either has the transient hint set to a specific window or if it 
doesn't it is modal for the whole window group. It may be possibly somewhat 
limiting. Actually e.g. for the cookie dialog this is way too limited.

> > > > 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.
>
> this is accessed via KWindowInfo::transientFor()?

 Yes. And no. As said above, determining mainwindow for a dialog is somewhat 
more complicated, especially when considering some a bit broken apps. 
Basically the whole kwin/group.cpp is code handling this (be careful when 
looking at it).

> if so, then yeah, we 
> actually already supported that in kicker; except that if it was a
> transient we just didn't show it in the taskbar, as it was assumed it
> wasn't a useful window to be shown in the taskbar. which may be true ... or
> .. not. hm. i'll have to look around to see if i (or someone =) can find
> use cases where a window that should be shown in the taskbar is also a
> transientFor() another window.

 I don't think the kwallet dialog should be considered different from any 
other dialog shown for a window.

-- 
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