[Panel-devel] Task management in plasma

[Lubos Lunak]

On Tuesday 29 of May 2007, Aaron J. Seigo wrote:
> 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.

 It definitely doesn't make enough sense to counter all the problems. You're 
not the only one seeing a lot of advantages in having it split (yay!).

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

 Ah, MDI. That MDI thing. Well, this one might be a bit harder possibly, I'm 
not sure. But if you have a good plan we could go at least with KDE private 
hints at least at the beginning.

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

 The problem in the case of the cookie dialog is that it cannot have two 
different windows both as its mainwindow. It's only about the support for 
expressing relations is too limited (although, on the other hand, it should 
get complex because in this case that could easily in practice equal to 
insanely complex).

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

 ? Are we still talking about KWallet? The dialogs should not get lost, modal 
dialogs should be activated when the user tries to activate their (blocked) 
main 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