[Panel-devel] Task management in plasma

Aaron J. Seigo aseigo at kde.org
Mon May 28 20:39:17 CEST 2007


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:


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

i think that's the most rational approach, yes.
 
> > > - 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.

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

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

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

> > 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)
 - documents (help with mdi)
 - modal relationships

there were some others that came up during conversations with brad hughes last 
year, but i can't find my notes on that right now.. let me touch base with 
brad again and come back to this.

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

i love you. in a manly hetero kind of way, of course ;)

> > > 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()? 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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070528/7380a22e/attachment.pgp 


More information about the Panel-devel mailing list