> > 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.
I've just started looking at libprocesscore. However, there seems to be no quick way of getting the details for a single pid - it seems to read them all, then you can ask for the details required. Not sure how slow that would be. But anyway, I agree reading /proc needs to be changed! > in fact, using the "pin the whole command line" as a last resort should > work > with just about every single window i imagine. But, this is where I disagree with the current implementation. If we pin stuff that does not have a desktop file, then you need to embed the icon, etc. This leads to non-translated strings, cant detect when an app is uninstalled, etc, etc. > getServicesViaPid should > perhaps also check the mappings in the rules file? Not currently, as the rules are for window classes, once we're looking at the PID then we have already discounted the window class. > > 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. Fine with me :-) > > 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. But I would prefer that to *only* be for supporting existing config, not for adding new launchers. > > 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? No, just to now allow it. And for the user to be prompted to locate the launcher. > > 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. But, is it worth adding work-arounds for such an edge case? Why bloat the code with something that is unlikely to occur? At least I dont see it as a blocker for the current implementation, just maybe a TODO for later. > > > 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?" :) My point was to show that whilst the IconTask implementation is not perfect, it already works better then the current one. With the one caveat of the embedded launcher details. But it does not have that, as it prompts the user to specify the launcher. I agree this prompting should only be at the very last resort - and for the vast majority of cases it is not needed. 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
