[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