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

List:       kde-panel-devel
Subject:    Re: IconTasks taskmanager changes
From:       "Craig Drummond" <Craig.Drummond () gmx ! net>
Date:       2011-10-27 11:16:25
Message-ID: 20111027111625.218140 () gmx ! net
[Download RAW message or body]

> > 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.

Please have a look at IconTasks' TaskItem::launcherUrl()

> to cover the wine and kcmshell4 cases, we probably will need to create a 
> whitelist of apps to handle specially and then (and yes, i know this is
> not 
> elegant but ugly since it means hardcoding for reality) handling those 
> specially. e.g. if we find our unfindable command line starts with
> "kcmshell" 
> then we need to look not in Applications but in ServiceTypes=KCModule.
> 
> we should be able to do a lot (even if a bit ugly in places) to prevent 
> showing the "pick the .desktop file" to the user exept in exceptional
> cases.

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

But I do agree that for some apps, workarounds will be required. Hence IconTasks has \
a taskmanagerrc file that has some work-around settings. 

> > 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. However, I do not agree with embedding this stuff in the config for future \
launchers. 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.

> > 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 the simple \
case of 1 kcm, then it would be doable. But then this is inconsistent - we can pin \
one, but not all. I cant imagine many people pinning kcm's. 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.

Craig.

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone
_______________________________________________
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]