> From: [EMAIL PROTECTED]> 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 thevisualization 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 libwhich isn't nice but should at least work, or
> the visualization has to update a screen variable inthe lib. So i guess you
> would prefer the latter> > > -I couldn't find a reliable source for> > the
> progamtype. As mentioned i currently use> > Taskmanager::Task::classClass()
> which works for things like opera or> > konqueror but totally fails on
> programs like vlc and its playlist.> > i think that's mostly a failing of
> programs like vlc.> > however, vlc's playlist should belong to the grouping;
> so calling > KWindowSystem::groupLeader(vlcPlaylistTask->winId()) should
> hopefully return > vlcTask->winId()> > > -Expanded> > groups currently look
> really ugly. The first point is that currently all> > tasks in an expanded
> group are squeezed to fit in the room that one task> > has. I not sure if an
> expanded group that contains 2 task should use the> > place of two tasks, or
> just maybe 1.5 time the place of a single task.> > that's a question for the
> art team ... > > > The> > expanded groups have a background in a specific
> color so they can easely> > distincted from other tasks. This is a fully
> opaque red,, yet. Since this> > looks awful we need some kind of colorpalette
> which looks nice and fits the> > current theme.> > leave this up to the
> artists ... > > There porbably has to be a configuration dialog to choose> >
> between some palettes.> > first sign it's probably not the best possible
> direction: you need to resort > immediately to configuraiton for something
> like "colour used on a specific > widget when in a specific state" =)> > >
> Unfortunately i don't have a clue if there is> > already something like
> this.What else i intend to implement:-A> > configuration window where some
> group properties (name, color, icon) can be> > changed by the user. > > i'd
> recommend not bothering. let's have the artists come up with a concept svg >
> for us to work from and then go from there.> > the name should be the group
> leader's name, the icon should be the group > leader's window icon. KISS.I'm
> trying to =) But there isn't any group leader. Obvously i can pick one of the
> first two tasksbut then you could end up with a group called "opera" which is
> actually used to group all tasks for developing the groupingtaskbar =)But
> strategies like progarmGrouping (grouping by program) obvisouly take the
> icon and name from one of its tasksand won't let the user configure anything.
> > > grouping by programbtw. both manual groupingstartegies aren't persistent>
> > over sessions since the Task pointer changes. I wonder if there is some
> way> > to recognize windows over sessions.> > window class; take a look at
> how kwin does it in its per-window settings. it's > not 100% perfect, but
> 99.9% is good enough here.> > > About the sorting and grouping> >
> strategies:The only useful sortingstrategy for me is currently the> >
> manualSortingStrategy (for what i actually started this whole project =). I>
> > implemented the alphasorting to stress the api but it's actually rather> >
> annoying if a task jumps around just because the website (and therefore the>
> > name of the task) changed.> > it shouldn't be alpha by window title, but by
> application.alright > > And i can't think of any situation where this> >
> would be useful anyway.> > so i can go "i'm looking for 'kontact' .. it'll be
> somewhere before 'mplayer'"yes sure, but unless you havent got like 30 tasks
> open at the same time you won't be much faster. And since we're trying to
> focus on work to do and not on application names ....;-)No just joking, i
> will implement it.> > Almost the same for the groupingStrategies. My> >
> favourite is definitely the manualgroupingStrategy where i can group tasks> >
> according to the work i have to do.> > understood; it's a really great
> exercise to try and get into the headspace of > others. i wil likely never
> use manual grouping, but i can totally understand > where you are coming
> from.Yes its definitely a great exercise, but im still having a hard time
> doing it =) > > i can't think of any further useful strategies. Would be
> great if some of> > you could come up with some cool ideas.> > by
> Plasma::Context =) in another week or so we should have Nepomuk integration >
> on the rails and then we can start playing with tagging windows.Hehe, this
> sounds like work is ahead Thanks for your answers> > -- > 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>
_________________________________________________________________
Werden Sie Mitglied der neuen Windows Live Messenger Familie!
http://get.live.com
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
