Re: Review Request 117464: [kglobalaccel] Remove notification support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55325 --- Looks good, but patch does not apply here. It fails with: error: kglobalaccel/CMakeLists.txt: does not exist in index error: kglobalaccel/globalshortcutsregistry.cpp: does not exist in index error: kglobalaccel/kglobalaccel.notifyrc: does not exist in index error: kglobalaccel/kglobalacceld.h: does not exist in index error: kglobalaccel/kglobalacceld.cpp: does not exist in index - Aurélien Gâteau On April 10, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 8:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
On April 10, 2014, 9:17 a.m., Aurélien Gâteau wrote: Looks good, but patch does not apply here. It fails with: error: kglobalaccel/CMakeLists.txt: does not exist in index error: kglobalaccel/globalshortcutsregistry.cpp: does not exist in index error: kglobalaccel/kglobalaccel.notifyrc: does not exist in index error: kglobalaccel/kglobalacceld.h: does not exist in index error: kglobalaccel/kglobalacceld.cpp: does not exist in index ah, nevermind... wrong repo :/ - Aurélien --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55325 --- On April 10, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 8:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55327 --- Ship it! Ship It! - Aurélien Gâteau On April 10, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 8:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117455: [kglobalaccel] Remove Component::showKCM
On April 9, 2014, 7:20 p.m., Martin Gräßlin wrote: Oh I just found a usage in kglobaccel itself: KNotification *notification = new KNotification( newshortcutregistered, KNotification::CloseOnTimeout, q-parent()); notification-setText( i18n(The application %1 has registered a new global shortcut, component-friendlyName())); notification-setActions( QStringList( i18n( Open Global Shortcuts Editor ) ) ); notification-addContext( application, component-friendlyName() ); QObject::connect(notification, SIGNAL(action1Activated()), component, SLOT(showKCM())); Though I'm not sure what's the use case for this notification and the commit message which introduced it doesn't say anything. This problem becomes obsolete with https://git.reviewboard.kde.org/r/117464/ - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117455/#review55296 --- On April 9, 2014, 7:05 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117455/ --- (Updated April 9, 2014, 7:05 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Remove Component::showKCM Component::showKCM was a method exported to DBus to wrap the invocation of kcmshell5 keys. According to lxr there is no application using this DBus method and it's not much use anyway as it doesn't open the keys KCM for the component. This removes the KIOWidgets dependency from kglobalaccel. Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/component.h 019c315374ecd226cb0820519a76bdbc3ced678c kglobalaccel/component.cpp 72a4980a3c26140bde692d376338da03dc67086e Diff: https://git.reviewboard.kde.org/r/117455/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117447: Runner - QueryMatch: Allow each match to give a category
On April 9, 2014, 11:27 a.m., Marco Martin wrote: I like the idea, only two things: * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a misc section * if this goes in, i would like to see sprinter's querymatch have the same, to avoid oh crap moments when porting Marco Martin wrote: (is pretty much corresponding to matchtype in sprinter if i understood correctly?) Aleix Pol Gonzalez wrote: About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now. Creating a shared misc category sounds artificial to me. Marco Martin wrote: uhm, i can easily think about different runners returning website urls, or resutls of type video regardless if is a search on the filesystem or from a youtube runner.. Vishesh Handa wrote: * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo) Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group Recent Documents as Files, and Places as FileSystemLocation. @Marco: I do not think that the Youtube videos should be grouped under the same Videos category for the videos files in your filesystem. We need to give some distinction between local videos and external videos. hmm, to me a video is a video.. by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/#review55272 --- On April 9, 2014, 11:18 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/ --- (Updated April 9, 2014, 11:18 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Repository: krunner Description --- This string based category is useful in categorizing the results. By default the category defaults to the name of the runner. Diffs - src/querymatch.h afec76e src/querymatch.cpp 83888f7 Diff: https://git.reviewboard.kde.org/r/117447/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117450: Add Milou to the default panel layout
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/#review55334 --- so, right now we already have two search uis added by default in the default setup: kickoff and krunner. adding a 3rd one by default, just no. what should be done is having the milou search ui into the kickoff search (and/or whoever will replace it in the future) - Marco Martin On April 9, 2014, 3:22 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/ --- (Updated April 9, 2014, 3:22 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- KRunner is hidden away as it is only accessible via a shortcut. It will be nice to have the plasmoid visible by default. It will not be an extra dependency as plasma-workspace already depends on Milou because of KRunner. Diffs - desktoppackage/contents/layout.js 303e7af Diff: https://git.reviewboard.kde.org/r/117450/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117450: Add Milou to the default panel layout
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/#review55333 --- so, right now we already have two search uis added by default in the default setup: kickoff and krunner. adding a 3rd one by default, just no. what should be done is having the milou search ui into the kickoff search (and/or whoever will replace it in the future) - Marco Martin On April 9, 2014, 3:22 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/ --- (Updated April 9, 2014, 3:22 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- KRunner is hidden away as it is only accessible via a shortcut. It will be nice to have the plasmoid visible by default. It will not be an extra dependency as plasma-workspace already depends on Milou because of KRunner. Diffs - desktoppackage/contents/layout.js 303e7af Diff: https://git.reviewboard.kde.org/r/117450/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117450: Add Milou to the default panel layout
On April 10, 2014, 11:16 a.m., Marco Martin wrote: so, right now we already have two search uis added by default in the default setup: kickoff and krunner. adding a 3rd one by default, just no. what should be done is having the milou search ui into the kickoff search (and/or whoever will replace it in the future) just want to say that I think in the same line as Marco here. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/#review55333 --- On April 9, 2014, 5:22 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/ --- (Updated April 9, 2014, 5:22 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- KRunner is hidden away as it is only accessible via a shortcut. It will be nice to have the plasmoid visible by default. It will not be an extra dependency as plasma-workspace already depends on Milou because of KRunner. Diffs - desktoppackage/contents/layout.js 303e7af Diff: https://git.reviewboard.kde.org/r/117450/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117449: KRunner: No need to reimplement tab/backspace/etc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117449/ --- (Updated April 10, 2014, 9:44 a.m.) Review request for Plasma and Marco Martin. Changes --- I'm not sure how I managed to create a review board request without a diff Repository: plasma-workspace Description --- We can just forward our keys to the Milou.ResultsView and that handles all of these. With this the arrow keys also work. Diffs (updated) - lookandfeel/contents/runcommand/RunCommand.qml d8d7874 Diff: https://git.reviewboard.kde.org/r/117449/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55338 --- This means the notification right now has nothing more than debug purpose. Wasn't there some accessibility reason for that notification? Because you can also have audio notification and others (custom plugins to KNotifications), not just popups. - Martin Klapetek On April 10, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 8:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
On April 10, 2014, 11:47 a.m., Martin Klapetek wrote: This means the notification right now has nothing more than debug purpose. Wasn't there some accessibility reason for that notification? Because you can also have audio notification and others (custom plugins to KNotifications), not just popups. I tried to figure out the reason on why there should be the notification. But neither the commits nor the mailing list thread shed light on it. But also for accessibility I don't really see a reason to have a notification when the global shortcut got triggered. Something should happen when you click it, e.g. Present Windows starts. Why would one want an additional feedback on yo, you just activated Present Windows? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55338 --- On April 10, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 8:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
On April 10, 2014, 9:47 a.m., Martin Klapetek wrote: This means the notification right now has nothing more than debug purpose. Wasn't there some accessibility reason for that notification? Because you can also have audio notification and others (custom plugins to KNotifications), not just popups. Martin Gräßlin wrote: I tried to figure out the reason on why there should be the notification. But neither the commits nor the mailing list thread shed light on it. But also for accessibility I don't really see a reason to have a notification when the global shortcut got triggered. Something should happen when you click it, e.g. Present Windows starts. Why would one want an additional feedback on yo, you just activated Present Windows? It is for accessibility reasons so we could use knotifyd as a sort of text-to-speech. This is now not needed at all and imho it should be removed. We need somebody to take charge of accessibility in Qt5 world (kde-wise). - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55338 --- On April 10, 2014, 6:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 6:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117449: KRunner: No need to reimplement tab/backspace/etc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117449/#review55348 --- Ship it! Ship It! - Marco Martin On April 10, 2014, 9:44 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117449/ --- (Updated April 10, 2014, 9:44 a.m.) Review request for Plasma and Marco Martin. Repository: plasma-workspace Description --- We can just forward our keys to the Milou.ResultsView and that handles all of these. With this the arrow keys also work. Diffs - lookandfeel/contents/runcommand/RunCommand.qml d8d7874 Diff: https://git.reviewboard.kde.org/r/117449/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117447: Runner - QueryMatch: Allow each match to give a category
On April 9, 2014, 11:27 a.m., Marco Martin wrote: I like the idea, only two things: * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a misc section * if this goes in, i would like to see sprinter's querymatch have the same, to avoid oh crap moments when porting Marco Martin wrote: (is pretty much corresponding to matchtype in sprinter if i understood correctly?) Aleix Pol Gonzalez wrote: About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now. Creating a shared misc category sounds artificial to me. Marco Martin wrote: uhm, i can easily think about different runners returning website urls, or resutls of type video regardless if is a search on the filesystem or from a youtube runner.. Vishesh Handa wrote: * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo) Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group Recent Documents as Files, and Places as FileSystemLocation. @Marco: I do not think that the Youtube videos should be grouped under the same Videos category for the videos files in your filesystem. We need to give some distinction between local videos and external videos. Marco Martin wrote: hmm, to me a video is a video.. by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos Vishesh Handa wrote: Yes they are all just videos, but the user needs to be given context as to where the data comes from. One cannot just interleave youtube videos + vimeo videos + local videos. We also have to take our UI into consideration - We can at max display 3-6 results of each category[1]. If we interleave web searches + local searches, then the web-searches will almost never be shown. The local results will be faster than the web results. [1] depends on the number of categories Maybe we should have a discussion separately regarding remote vs local? I think it hasn't been discussed and I'm afraid it would cause misunderstandings in the future. Regarding the actual patch, I don't think it would be bad to have a YouTube category. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/#review55272 --- On April 9, 2014, 11:18 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/ --- (Updated April 9, 2014, 11:18 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Repository: krunner Description --- This string based category is useful in categorizing the results. By default the category defaults to the name of the runner. Diffs - src/querymatch.h afec76e src/querymatch.cpp 83888f7 Diff: https://git.reviewboard.kde.org/r/117447/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117447: Runner - QueryMatch: Allow each match to give a category
On April 9, 2014, 11:27 a.m., Marco Martin wrote: I like the idea, only two things: * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a misc section * if this goes in, i would like to see sprinter's querymatch have the same, to avoid oh crap moments when porting Marco Martin wrote: (is pretty much corresponding to matchtype in sprinter if i understood correctly?) Aleix Pol Gonzalez wrote: About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now. Creating a shared misc category sounds artificial to me. Marco Martin wrote: uhm, i can easily think about different runners returning website urls, or resutls of type video regardless if is a search on the filesystem or from a youtube runner.. Vishesh Handa wrote: * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo) Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group Recent Documents as Files, and Places as FileSystemLocation. @Marco: I do not think that the Youtube videos should be grouped under the same Videos category for the videos files in your filesystem. We need to give some distinction between local videos and external videos. Marco Martin wrote: hmm, to me a video is a video.. by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos Vishesh Handa wrote: Yes they are all just videos, but the user needs to be given context as to where the data comes from. One cannot just interleave youtube videos + vimeo videos + local videos. We also have to take our UI into consideration - We can at max display 3-6 results of each category[1]. If we interleave web searches + local searches, then the web-searches will almost never be shown. The local results will be faster than the web results. [1] depends on the number of categories Aleix Pol Gonzalez wrote: Maybe we should have a discussion separately regarding remote vs local? I think it hasn't been discussed and I'm afraid it would cause misunderstandings in the future. Regarding the actual patch, I don't think it would be bad to have a YouTube category. only thing i fear about having categories as strings is the complete lack of standardization, that will bring things like categories pictures images photos music audio mp3 songs remote internet cloud services online I would really prefer as few categories as possible even if not technically precise than a load of random names each author of a runner came up, each one different - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/#review55272 --- On April 9, 2014, 11:18 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/ --- (Updated April 9, 2014, 11:18 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Repository: krunner Description --- This string based category is useful in categorizing the results. By default the category defaults to the name of the runner. Diffs - src/querymatch.h afec76e src/querymatch.cpp 83888f7 Diff: https://git.reviewboard.kde.org/r/117447/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117447: Runner - QueryMatch: Allow each match to give a category
On April 9, 2014, 1:27 p.m., Marco Martin wrote: I like the idea, only two things: * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a misc section * if this goes in, i would like to see sprinter's querymatch have the same, to avoid oh crap moments when porting Marco Martin wrote: (is pretty much corresponding to matchtype in sprinter if i understood correctly?) Aleix Pol Gonzalez wrote: About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now. Creating a shared misc category sounds artificial to me. Marco Martin wrote: uhm, i can easily think about different runners returning website urls, or resutls of type video regardless if is a search on the filesystem or from a youtube runner.. Vishesh Handa wrote: * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo) Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group Recent Documents as Files, and Places as FileSystemLocation. @Marco: I do not think that the Youtube videos should be grouped under the same Videos category for the videos files in your filesystem. We need to give some distinction between local videos and external videos. Marco Martin wrote: hmm, to me a video is a video.. by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos Vishesh Handa wrote: Yes they are all just videos, but the user needs to be given context as to where the data comes from. One cannot just interleave youtube videos + vimeo videos + local videos. We also have to take our UI into consideration - We can at max display 3-6 results of each category[1]. If we interleave web searches + local searches, then the web-searches will almost never be shown. The local results will be faster than the web results. [1] depends on the number of categories Aleix Pol Gonzalez wrote: Maybe we should have a discussion separately regarding remote vs local? I think it hasn't been discussed and I'm afraid it would cause misunderstandings in the future. Regarding the actual patch, I don't think it would be bad to have a YouTube category. Marco Martin wrote: only thing i fear about having categories as strings is the complete lack of standardization, that will bring things like categories pictures images photos music audio mp3 songs remote internet cloud services online I would really prefer as few categories as possible even if not technically precise than a load of random names each author of a runner came up, each one different In Sprinter you can define the type and the source of each match. e.g. youtube sprinter-plugin: Sprinter::QueryMatch match; match.setTitle(tr(%1 (%2, %3)).arg(title, author, time)); match.setType(Sprinter::QuerySession::VideoType); match.setSource(Sprinter::QuerySession::FromNetworkService); And I completely agree with Marco, a video is a video independent from the source it comes from. - Emmanuel --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/#review55272 --- On April 9, 2014, 1:18 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/ --- (Updated April 9, 2014, 1:18 p.m.) Review request for Plasma and Aleix Pol Gonzalez. Repository: krunner Description --- This string based category is useful in categorizing the results. By default the category defaults to the name of the runner. Diffs - src/querymatch.h afec76e src/querymatch.cpp 83888f7 Diff: https://git.reviewboard.kde.org/r/117447/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117447: Runner - QueryMatch: Allow each match to give a category
On April 9, 2014, 11:27 a.m., Marco Martin wrote: I like the idea, only two things: * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a misc section * if this goes in, i would like to see sprinter's querymatch have the same, to avoid oh crap moments when porting Marco Martin wrote: (is pretty much corresponding to matchtype in sprinter if i understood correctly?) Aleix Pol Gonzalez wrote: About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now. Creating a shared misc category sounds artificial to me. Marco Martin wrote: uhm, i can easily think about different runners returning website urls, or resutls of type video regardless if is a search on the filesystem or from a youtube runner.. Vishesh Handa wrote: * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo) Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group Recent Documents as Files, and Places as FileSystemLocation. @Marco: I do not think that the Youtube videos should be grouped under the same Videos category for the videos files in your filesystem. We need to give some distinction between local videos and external videos. Marco Martin wrote: hmm, to me a video is a video.. by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos Vishesh Handa wrote: Yes they are all just videos, but the user needs to be given context as to where the data comes from. One cannot just interleave youtube videos + vimeo videos + local videos. We also have to take our UI into consideration - We can at max display 3-6 results of each category[1]. If we interleave web searches + local searches, then the web-searches will almost never be shown. The local results will be faster than the web results. [1] depends on the number of categories Aleix Pol Gonzalez wrote: Maybe we should have a discussion separately regarding remote vs local? I think it hasn't been discussed and I'm afraid it would cause misunderstandings in the future. Regarding the actual patch, I don't think it would be bad to have a YouTube category. Marco Martin wrote: only thing i fear about having categories as strings is the complete lack of standardization, that will bring things like categories pictures images photos music audio mp3 songs remote internet cloud services online I would really prefer as few categories as possible even if not technically precise than a load of random names each author of a runner came up, each one different Emmanuel Pescosta wrote: In Sprinter you can define the type and the source of each match. e.g. youtube sprinter-plugin: Sprinter::QueryMatch match; match.setTitle(tr(%1 (%2, %3)).arg(title, author, time)); match.setType(Sprinter::QuerySession::VideoType); match.setSource(Sprinter::QuerySession::FromNetworkService); And I completely agree with Marco, a video is a video independent from the source it comes from. about having too many results per category.. this is clearly a visualization issue more than a model related one. one solution may be (given that each category has a really reliable prioritization of results) to show a max of results per category, say 10 or so, plus a more item as the last, and then it goes in a second page where it shows all the results for a given category, and only that category. or i don't know, there may be other ;) - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/#review55272 --- On April 9, 2014, 11:18 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117447/ --- (Updated April 9, 2014, 11:18 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Repository: krunner Description --- This string based category is useful in categorizing the results.
Re: Review Request 117372: replace kde4-config with kf5-config
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117372/ --- (Updated April 10, 2014, 1:32 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Àlex Fiestas. Repository: plasma-workspace Description --- startkde still uses kde4-config, this should be kf5-config in the kf5 world. Diffs - startkde/startkde.cmake e845603 Diff: https://git.reviewboard.kde.org/r/117372/diff/ Testing --- Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 117481: Remove Open Wallpaper Image entry on the menu
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117481/ --- Review request for Plasma. Repository: plasma-workspace Description --- Is it something we really want? Diffs - wallpapers/image/imagepackage/contents/ui/main.qml f58de66 Diff: https://git.reviewboard.kde.org/r/117481/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117481: Remove Open Wallpaper Image entry on the menu
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117481/#review55394 --- Ship it! Ship It! - Vishesh Handa On April 10, 2014, 2:23 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117481/ --- (Updated April 10, 2014, 2:23 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Is it something we really want? Diffs - wallpapers/image/imagepackage/contents/ui/main.qml f58de66 Diff: https://git.reviewboard.kde.org/r/117481/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 117494: Proposed Patch for Bug 198661 - Add option to disable scroll on taskbar
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117494/ --- Review request for Plasma. Bugs: 198661 https://bugs.kde.org/show_bug.cgi?id=198661 Repository: plasma-desktop Description --- Patch against plasma-desktop git master rev. ba6f2d7c054e7cdc1013c03a3f0821e8e328329b, fixing Bug 198661 - Add option to disable scroll on taskbar. This patch adds a new checkbox under Task Manager Settings General and a corresponding property called enableMouseScroll, with the default set to True (the current default). This property is checked on every onWheelMoved event, and only if true does it permit scrolling. Diffs - applets/taskmanager/package/contents/config/main.xml 1a8fe8a applets/taskmanager/package/contents/ui/ConfigGeneral.qml 114f88a applets/taskmanager/package/contents/ui/MouseHandler.qml 124e4c9 applets/taskmanager/package/contents/ui/Task.qml b6c3539 Diff: https://git.reviewboard.kde.org/r/117494/diff/ Testing --- Don't know how to test. However, patch is trivially small; problems should be eyeballable. Thanks, Olexa Bilaniuk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55428 --- This review has been submitted with commit 59a6e7b3fd64b7821c064a5528dd91efe1814665 by Martin Gräßlin to branch master. - Commit Hook On April 10, 2014, 6:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 6:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117464: [kglobalaccel] Remove notification support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 11, 2014, 5:42 a.m.) Status -- This change has been marked as submitted. Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117452: [kglobalaccel] Port away from dead #ifdef Q_WS_X11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117452/#review55429 --- This review has been submitted with commit d888a16fb0f59ad6657ceddaf3b31ec475959f4c by Martin Gräßlin to branch master. - Commit Hook On April 10, 2014, 5:58 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117452/ --- (Updated April 10, 2014, 5:58 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Port away from dead #ifdef Q_WS_X11 * Add a configure-kglobalaccel.h which defines HAVE_X11 * Port all Q_WS_X11 to HAVE_X11 * Implement a replacement for qApp-syncX() Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/component.cpp 72a4980a3c26140bde692d376338da03dc67086e kglobalaccel/config-kglobalaccel.h.cmake PRE-CREATION kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel_x11.h c0e9334517e3954dde211fd5d79e59f4bb56e2bd kglobalaccel/kglobalaccel_x11.cpp 9da8907485b55d522299200b4e5db307a73ae4e4 Diff: https://git.reviewboard.kde.org/r/117452/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117452: [kglobalaccel] Port away from dead #ifdef Q_WS_X11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117452/ --- (Updated April 11, 2014, 5:43 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Port away from dead #ifdef Q_WS_X11 * Add a configure-kglobalaccel.h which defines HAVE_X11 * Port all Q_WS_X11 to HAVE_X11 * Implement a replacement for qApp-syncX() Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/component.cpp 72a4980a3c26140bde692d376338da03dc67086e kglobalaccel/config-kglobalaccel.h.cmake PRE-CREATION kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel_x11.h c0e9334517e3954dde211fd5d79e59f4bb56e2bd kglobalaccel/kglobalaccel_x11.cpp 9da8907485b55d522299200b4e5db307a73ae4e4 Diff: https://git.reviewboard.kde.org/r/117452/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
