[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: GroupingTaskbar infos and questions
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2008-09-04 21:44:09
Message-ID: 200809041544.12827.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 04 September 2008, Christian Mollekopf wrote:
> Hopefully it works this time with the formatting...
>
> > From: aseigo@kde.org
> > To: plasma-devel@kde.org
> > Subject: Re: GroupingTaskbar infos and questions
> > Date: Thu, 4 Sep 2008 12:49:48 -0600
> >
> > On Thursday 04 September 2008, christian mollekopf wrote:
> > > Hi there,the groupingtaskmanager is in a fairly usable state now but
> > > there are still some issues left where i could use some help.What is
> > > working by now:-Everthing that the old taskmanger could do exept the
> > > show only current screen functionality and startup tasks-Automatic
> > > grouping by programname based on the name in
> > > Taskmanager::Task::classClass()-Manual grouping, this creates on change
> > > of the desktop a copy of the whole grouptree so all manually created
> > > groups can get restored on return to the desktop (only if
> > > showOnlyCurrentDesktop is enabled of course)-Automatic sorting by
> > > alpha-Manual sortingWhere i still have to work on and need your help:-I
> > > couldn't figure out how to find out if a window is on the current
> > > screen because the containment isn't available in the lib.
> >
> > that's something belongs in the Applet (which has access to the
> > containment()); libtaskmanager should simply advertise which screen a
> > window is on (and probably take a flag to control whether it should care
> > or not, since that's a relatively expensive operation)
>
> hmm... i thought so but this leads to some serious problems.
> Since all the grouping gets done in the lib we can't just leave it up to
> the visualization because we would end up with empty groups the lib created
> because it has more tasks available than the visualization displays in the
> end. The only two solutions i can think of are, we pass the containment
> pointer to the lib which isn't nice but should at least work, or the
> visualization has to update a screen variable in the lib. So i guess you
> would prefer the latter

good points; yes, i agree that passing a screen parameter to the grouping 
strategy would be the way to go =)

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

KDE core developer sponsored by Trolltech


["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]