[Panel-devel] Task management in plasma

[Aaron J. Seigo]

On Monday 28 May 2007, Lubos Lunak wrote:
> 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?

yes and no. you'll be able to move things between screens, but internally i 
expect each screen to have its own Corona object. the downside to this 
approach is that it means you can have an object half on one screen and half 
on the other. in a drag and drop, it would drop and appear on whichever 
screen you dropped on.

i'm not exactly sure that having an object half on one screen and half on the 
other make much sense, to be honest.

the upside is that this makes a -lot- of other things very easy, such as 
multi-screen backgrounds and managing icon allignments across screens with 
different resolutions.

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

hm.. ok, i'll have to ask brad again what issues they ran into .. =)

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

ok, so we need to work on a firm set of requests that make sense... i'll start 
to gather ideas together this week and then present them next week on this 
list for perusal and flamage =)

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

yes; essentially we need an id, an icon and name. similar to what we get with 
a top level window. actually, it has more in common with a transient since it 
also references which window it belongs to. obviously, these aren't real 
windows but would let the taskbar "peer into" tabbed windows or windows that 
are housing, e.g., web content.

as i mentioned in an earlier email, i think it would be possitively cool if 
web apps could actually appear as proper entries in the taskbar; so when you 
open a "compose email" window in a web app, you would get a proper entry just 
as you do with kontact as opposed to yet another konqi entry.

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

what do you think would help solve that?

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

hm.. yes, i see ... 

> Basically the whole kwin/group.cpp is code handling this (be careful
> when looking at it).

ehehe.. yeah, window management is !fun

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

there are password dialogs that take keyboard focus (for better or worse) 
which should show in the taskbar so they are easily found and clicked on when 
lost.

-- 
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/b4ffaa13/attachment-0001.pgp