GroupingTaskbar infos and questions

[Christian Mollekopf]

Hopefully it works this time with the formatting...

> From: aseigo at kde.org
> To: plasma-devel at 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

> 
> > -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 tasks
but 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 tasks
and 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
>
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx