<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><BR><BR><BR><HR id="stopSpelling"><DIV align="left">> From: aseigo@kde.org<BR>> To: plasma-devel@kde.org<BR>> Subject: Re: GroupingTaskbar infos and questions<BR>> Date: Thu, 4 Sep 2008 12:49:48 -0600<BR>> <BR>> On Thursday 04 September 2008, christian mollekopf wrote:<BR>> > Hi there,the groupingtaskmanager is in a fairly usable state now but there<BR>> > are still some issues left where i could use some help.What is working by<BR>> > now:-Everthing that the old taskmanger could do exept the show only current<BR>> > screen functionality and startup tasks-Automatic grouping by programname<BR>> > based on the name in Taskmanager::Task::classClass()-Manual grouping, this<BR>> > creates on change of the desktop a copy of the whole grouptree so all<BR>> > manually created groups can get restored on return to the desktop (only if<BR>> > showOnlyCurrentDesktop is enabled of course)-Automatic sorting by<BR>> > alpha-Manual sortingWhere i still have to work on and need your help:-I<BR>> > couldn't figure out how to find out if a window is on the current screen<BR>> > because the containment isn't available in the lib.<BR>> <BR>> that's something belongs in the Applet (which has access to the <BR>> containment()); libtaskmanager should simply advertise which screen a window <BR>> is on (and probably take a flag to control whether it should care or not, since <BR>> that's a relatively expensive operation)</DIV><DIV align="left"></DIV><DIV align="left">hmm... i thought so but this leads to some serious problems.</DIV><DIV align="left">Since all the grouping gets done in the lib we can't just leave it up to the</DIV><DIV align="left">visualization because we would end up with empty groups the lib created because it </DIV><DIV align="left">has more tasks available than the visualization displays in the end.</DIV><DIV align="left"></DIV><DIV align="left">The only two solutions i can think of are, we pass the containment pointer to the lib</DIV><DIV align="left">which isn't nice but should at least work, or the visualization has to update a screen variable in</DIV><DIV align="left">the lib. So i guess you would prefer the latter</DIV><DIV align="left"><BR>> <BR>> > -I couldn't find a reliable source for<BR>> > the progamtype. As mentioned i currently use<BR>> > Taskmanager::Task::classClass() which works for things like opera or<BR>> > konqueror but totally fails on programs like vlc and its playlist.<BR>> <BR>> i think that's mostly a failing of programs like vlc.<BR>> <BR>> however, vlc's playlist should belong to the grouping; so calling <BR>> KWindowSystem::groupLeader(vlcPlaylistTask->winId()) should hopefully return <BR>> vlcTask->winId()<BR>> <BR>> > -Expanded<BR>> > groups currently look really ugly. The first point is that currently all<BR>> > tasks in an expanded group are squeezed to fit in the room that one task<BR>> > has. I not sure if an expanded group that contains 2 task should use the<BR>> > place of two tasks, or just maybe 1.5 time the place of a single task.<BR>> <BR>> that's a question for the art team ... <BR>> <BR>> > The<BR>> > expanded groups have a background in a specific color so they can easely<BR>> > distincted from other tasks. This is a fully opaque red,, yet. Since this<BR>> > looks awful we need some kind of colorpalette which looks nice and fits the<BR>> > current theme.<BR>> <BR>> leave this up to the artists ...</DIV><DIV align="left"> <BR>> > There porbably has to be a configuration dialog to choose<BR>> > between some palettes.<BR>> <BR>> first sign it's probably not the best possible direction: you need to resort <BR>> immediately to configuraiton for something like "colour used on a specific <BR>> widget when in a specific state" =)<BR>> <BR>> > Unfortunately i don't have a clue if there is<BR>> > already something like this.What else i intend to implement:-A<BR>> > configuration window where some group properties (name, color, icon) can be<BR>> > changed by the user. <BR>> <BR>> i'd recommend not bothering. let's have the artists come up with a concept svg <BR>> for us to work from and then go from there.<BR>> <BR>> the name should be the group leader's name, the icon should be the group <BR>> leader's window icon. KISS.<BR></DIV><DIV align="left"></DIV><DIV align="left">I'm trying to =) </DIV><DIV align="left">But there isn't any group leader. Obvously i can pick one of the first two tasks</DIV><DIV align="left">but then you could end up with a group called "opera" which is actually used to </DIV><DIV align="left">group all tasks for developing the groupingtaskbar =)</DIV><DIV align="left"></DIV><DIV align="left">But strategies like progarmGrouping (grouping by program) obvisouly take the icon and name from one of its tasks</DIV><DIV align="left">and won't let the user configure anything.</DIV><DIV align="left"> <BR>> > grouping by programbtw. both manual groupingstartegies aren't persistent<BR>> > over sessions since the Task pointer changes. I wonder if there is some way<BR>> > to recognize windows over sessions.<BR>> <BR>> window class; take a look at how kwin does it in its per-window settings. it's <BR>> not 100% perfect, but 99.9% is good enough here.<BR>> <BR>> > About the sorting and grouping<BR>> > strategies:The only useful sortingstrategy for me is currently the<BR>> > manualSortingStrategy (for what i actually started this whole project =). I<BR>> > implemented the alphasorting to stress the api but it's actually rather<BR>> > annoying if a task jumps around just because the website (and therefore the<BR>> > name of the task) changed.<BR>> <BR>> it shouldn't be alpha by window title, but by application.<BR></DIV><DIV align="left"></DIV><DIV align="left">alright </DIV><DIV align="left"><BR>> > And i can't think of any situation where this<BR>> > would be useful anyway.<BR>> <BR>> so i can go "i'm looking for 'kontact' .. it'll be somewhere before 'mplayer'"<BR></DIV><DIV align="left"></DIV><DIV align="left">yes sure, but unless you havent got like 30 tasks open at the same time you won't be much faster. </DIV><DIV align="left">And since we're trying to focus on work to do and not on application names ....;-)</DIV><DIV align="left">No just joking, i will implement it.</DIV><DIV align="left"><BR>> > Almost the same for the groupingStrategies. My<BR>> > favourite is definitely the manualgroupingStrategy where i can group tasks<BR>> > according to the work i have to do.<BR>> <BR>> understood; it's a really great exercise to try and get into the headspace of <BR>> others. i wil likely never use manual grouping, but i can totally understand <BR>> where you are coming from.<BR></DIV><DIV align="left">Yes its definitely a great exercise, but im still having a hard time doing it =) </DIV><DIV align="left"><BR>> > i can't think of any further useful strategies. Would be great if some of<BR>> > you could come up with some cool ideas.<BR>> <BR>> by Plasma::Context =) in another week or so we should have Nepomuk integration <BR>> on the rails and then we can start playing with tagging windows.<BR></DIV><DIV align="left"></DIV><DIV align="left">Hehe, this sounds like work is ahead </DIV><DIV align="left"></DIV><DIV align="left">Thanks for your answers<BR>> <BR>> -- <BR>> Aaron J. Seigo<BR>> humru othro a kohnu se<BR>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<BR>> <BR>> KDE core developer sponsored by Trolltech<BR>> <BR></DIV><br /><hr />Die neue Generation der Windows Live Services - jetzt downloaden! <a href='http://get.live.com/' target='_new'>Hier klicken!</a></body>
</html>