IconTasks taskmanager changes

[Aaron J. Seigo]

On Thursday, October 27, 2011 13:16:25 Craig Drummond wrote:
> > > The only
> > > cases where IconTasks will not create a launcher, where current taskbar
> > > may, is when no desktop file is present. But I dont see this as that big
> > > a deal.
> > 
> > .. and that is the regression. you can't start with "it isn't a
> > regression"
> > and then end with "it regresses the current behaviour". it's a
> > contradiction.
> 
> It /changes/ the current behaviour, not sure I'd call it a regression - but
> that's just nit-picking.
> > a better approach might be to get the command line associated with a
> > window.
> > this can be done using the _NET_WM_PID property on x11
> 
> IconTasks *already* does this. It doesn't use libprocesscore, as I was not
> aware of this - it reads "/proc", so this probably needs updating/fixing.

indeed, as that is not very portable.
 
> Please have a look at IconTasks' TaskItem::launcherUrl()

this is a set of steps in a very good direction imho.. nice :)

> I had not considered kcmshell - not really sure if that is actually
> 'pinnable'

it should be ... it needs to be matched by command line. usually there will be 
a .desktop file that matches. if not, then one could be written that does, or 
simply store the command line somewhere convenient for re-use.

in fact, using the "pin the whole command line" as a last resort should work 
with just about every single window i imagine. getServicesViaPid should 
perhaps also check the mappings in the rules file?
 
> But I do agree that for some apps, workarounds will be required. Hence
> IconTasks has a taskmanagerrc file that has some work-around settings.

for a bit of consistency with kwin, it might be nice to call the file that 
contains these mappings and settings "taskmanagerrulesrc" so that it fits 
nicely with the kwinrulesrc file.

> > > So in this regard, the matching, etc, *is* better.
> > > 
> > > The only current regression would be for existing launchers that have
> > > their details embedded in the config file (as I said this happens for
> > > system settings).
> > 
> > right, and we can avoid such a regression.
> 
> I can convert the embedded config into a fake launcherUrl, so that existing
> config works.

that could be a nice solution to bridge existing config.

> However, I do not agree with embedding this stuff in the
> config for future launchers. 

your suggestion solution is to create a proper .desktop file?

> Currently when System Settings is pinned, the
> launcher has the title "Systemsettings" and not "System Settings", as this
> is the class name, and no other details are shown in the tooltip.

and this would be solved by the method i described in my previous email. so i 
don't see what the problem is.

> > > But this could probably be resolved by using an
> > > internal launcher URL that points to the embedded details.
> > 
> > or, at least in the case of control panels, we can actually find the
> > .desktop
> > file.
> 
> But how? How would I find the launcher for "kcmshell4 fonts colors"??? For

this would require a workaround, using a whitelist for such apps as i 
mentioned.

> the simple case of 1 kcm, then it would be doable. But then this is
> inconsistent - we can pin one, but not all.

we can pin those launched via a .desktop file; for those launched by an 
application (a practice that should really be discouraged imho, as we have an 
easy way to load them in-application using the KCM dialog) or from the command 
line we'd need to have a fall-back hack.

> I cant imagine many people pinning kcm's.

yes, it's an edge case for certain. would be nice if it works, all the same.

> In fact the current taskbar is broken for these, as kcmshell
> is pinned - but you cannot start this byitself. So, it creates a launcher
> that does nothing.

yes, we've covered that there are problems with the current implementation in 
the tasks widget. i'm interested in solutions we can implement next, not 
repeatedly saying "we do know that the current implementation in that widget 
is broken, right?" :)

-- 
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 Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20111027/8c1da41d/attachment.sig>