> On Sept. 22, 2014, 3:38 nachm., Martin Gräßlin wrote: > > I like the idea! > > > > Suggestion for the "which package manager to use" part: add a package > > manager selection to the defaults application KCM and use the one which is > > configured there. Distros should be able to easily configure the one they > > are using then. > > Aleix Pol Gonzalez wrote: > Why would distros need a GUI for configuring it? > > Martin Gräßlin wrote: > distros don't need the GUI, but the kconfig key. Some distros provide > multiple tools, though and then the user might want to be able to configure > it. > > Eike Hein wrote: > I was planning to add a config key to Kicker for now, but I agree a more > canonical workspace-level key and an API in KToolInvocation would be cool. > Next Frameworks release maybe? > > Matthias Klumpp wrote: > In theory, a call on the PackageKit interface should trigger whatever > implements the PackageKit session DBus interface (on KDE that's only Apper at > time) to display any GUI dialogs. > But probably showing the application prior to removing it in a software > center is a good idea anyway :) > Would it make sense to send the application-name to the software center, > and have it figure out the package name, instead of doing that prior to > calling the SC? Might be a bit nicer... > > As a sidenote: Using LibAppstreamQt could be a future option for > resolving application-names to packages - depending on the distribution's > package-manager, calls to SearchFiles() could be a bit slow. Drawback of > using that lib is that distros need to ship with AppStream metadata, which > currently only OpenSUSE and Fedora do - Debian will support is soon, and > Ubuntu maybe as well (both distros currently have partial support via > AppInstall data). > > That feature looks great, I hope it doesn't conflict with > http://dantti.wordpress.com/2010/11/25/yup-laziness-is-a-virtue/ , although > honestly I need to check if that Apper feature actually still works... > > Aleix Pol Gonzalez wrote: > @Klumpp: Well, we still want to do the lookup on the kicker side, because > we don't want to show the option in case its not removable. Otherwise we > would be rising the user's hopes for little reason.
Ah, right - didn't think about that possibility. - Matthias ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120318/#review67209 ----------------------------------------------------------- On Sept. 22, 2014, 3:34 nachm., Aleix Pol Gonzalez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120318/ > ----------------------------------------------------------- > > (Updated Sept. 22, 2014, 3:34 nachm.) > > > Review request for Plasma and Eike Hein. > > > Repository: plasma-desktop > > > Description > ------- > > I've been discussing with Eike having something like that for a while, I > finally managed to put something together that we could use in a future. > > It adds an entry on the menu that is called "Remove '<packagename>'" that > opens a software center. I set it to muon-discover for now, but this should > be iterated over. > > To do the lookup, it uses PackageKitQt. It probably should be an optional > dependency, but I want Eike to look into it first and decide how to do it > best. > > > Diffs > ----- > > CMakeLists.txt 7b794ff > applets/kicker/CMakeLists.txt 0688732 > applets/kicker/plugin/appsmodel.cpp b88d711 > applets/kicker/plugin/findpackagenamejob.h PRE-CREATION > applets/kicker/plugin/findpackagenamejob.cpp PRE-CREATION > config-workspace.h.cmake 58a11d4 > > Diff: https://git.reviewboard.kde.org/r/120318/diff/ > > > Testing > ------- > > I uninstalled openarena, selfcompiled software cannot removed. > > The locking is not really noticeable on my system. We still probably want to > improve that but I don't think it would be terrible like this, only bad. > > > Thanks, > > Aleix Pol Gonzalez > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
