IconTasks taskmanager changes

[Aaron J. Seigo]

On Wednesday, October 26, 2011 17:24:08 Craig Drummond wrote:
> On 26/10/11 15:59, Aaron J. Seigo wrote:
> > On Wednesday, October 26, 2011 15:13:02 Craig Drummond wrote:
> >> Then you simply cannot pin the application to the taskbar. Is that such a
> >> big deal?
> > 
> > it would be a regression with no justifiable argument for why it should
> > regress.
> > 
> > a good exercise is to imagine explaining it to a user why that one entry
> > couldn't be added.
> 
> Its not really a regression. 

? let's examine:

> Currently the existing taskbar cannot
> create a launcher for LibreOffice - whereas IconTasks can.

great; always good when things improve, but this has nothing to do with the 
"can't figure out the binary name"

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

what would make a lot of sense to me is this:

* try to determine the .desktop file for the entry (and i bet that as long as 
we can find the executable, we should be able to find it if it exists with the 
right sycoca query)

* if that fails, try to determine the executable and if that works, don't 
hassle the user

* if the executable can not be determined, then ask the user to find a 
relevant .desktop file

> > additionally, for the corner cases where nothing can be done (due to not
> > being able to locate the executable in some fasion) we may wish to simply
> > disable the action.
> 
> Well how would I know nothing can be done? 

see above

> Just because the automatic
> matching did not work, doesn't mean that the app's desktop file is not
> installed. 

true, as the matching as done now is very basic.

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 (don't know about 
wayland, probably something similar but more compositor specific; ditto for 
windows or mac) and then using that with libprocesscore that is in 
kworkspace/libs/ksysguard/processcore to get the command line and see if that 
command line, as stated, is in a .desktop file. if it was started from a 
.desktop file, it will be.

if that fails, then fall back to the current "look for the classClass as the 
executable name in the .desktop file".

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.

and even then, we should probably offer a choice between an auto-generated (if 
possible) solution that doesn't rely on an existing .desktop file since not 
all commands *will* come from .desktop files.

> For instance, for wine apps IconTasks will *always* prompt
> for the user to select the app - as there, currently, is no easy way to
> determine this.

and this is quite acceptable imho when it can't be determined.

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

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

-- 
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/9a1134cf/attachment.sig>