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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
