D6197: Add basic KAuth support to file ioslave
eliasp added inline comments. INLINE COMMENTS > file.h:107 > +}; > +bool execWithRoot(const QString , const QString , const > QVariant , PriviledgeWarning warning); > +void endPriviledgeOp(); I find `execWithRoot()` to be a bit misleading, as the goal shouldn't be to always elevate to `root`'s privileges but to only what's required to execute the specific operation (e.g. browse `/home/someotheruser` doesn't need `root`'s privileges but only `someotheruser`'s privileges). Always elevating to root is IMHO by far too permissive. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D6197 To: chinmoyr, elvisangelaccio, #frameworks Cc: eliasp, aacid
Re: What environment variable defines where krunner looks for libkdeinit5_$app.so
On 06/06/2015 11:31 PM, David Faure wrote: Problem number 2: this kdeinit5 dlopen stuff is supposed to be optional, kdeinit should fallback to executing the binary, otherwise. I.e. this code is supposed to clear libpath and keep only execpath, and find it (kwrite) in $PATH. Related bug: https://bugs.kde.org/show_bug.cgi?id=345175 signature.asc Description: OpenPGP digital signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121949: Add name of consumer to kservice_desktop_to_json() deprecation warning.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121949/ --- Review request for KDE Frameworks. Repository: kservice Description --- Until now, there was no way to tell from the logged message where it was originating from. This change makes it easier to find the originating application. Diffs - src/services/kplugininfo.cpp aa5d26386eb17a7e552b29c8fa7961d68b16 Diff: https://git.reviewboard.kde.org/r/121949/diff/ Testing --- Getting now messages logged which look like this: ``` Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for Kate Session Applet instead of kservice_desktop_to_json() in your CMake code. Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for DataEngine for Kimpanel instead of kservice_desktop_to_json() in your CMake code. Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for Konsole Profiles instead of kservice_desktop_to_json() in your CMake code. ``` This makes it definitely far easier to update the affected applications. Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121949: Add name of consumer to kservice_desktop_to_json() deprecation warning.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121949/ --- (Updated Jan. 9, 2015, 4:01 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kservice Description --- Until now, there was no way to tell from the logged message where it was originating from. This change makes it easier to find the originating application. Diffs - src/services/kplugininfo.cpp aa5d26386eb17a7e552b29c8fa7961d68b16 Diff: https://git.reviewboard.kde.org/r/121949/diff/ Testing --- Getting now messages logged which look like this: ``` Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for Kate Session Applet instead of kservice_desktop_to_json() in your CMake code. Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for DataEngine for Kimpanel instead of kservice_desktop_to_json() in your CMake code. Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for Konsole Profiles instead of kservice_desktop_to_json() in your CMake code. ``` This makes it definitely far easier to update the affected applications. Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121953: Add filename to KPluginInfo::property() deprecation notice.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121953/ --- Review request for KDE Frameworks. Repository: kservice Description --- Add filename to KPluginInfo::property() deprecation notice. Diffs - src/services/kplugininfo.cpp 98a2aa5c553c8a608afdaf82eee8fec9ca4ca60b Diff: https://git.reviewboard.kde.org/r/121953/diff/ Testing --- The deprecation notice for `KPluginInfo::property()` includes now the filename of the originating file, making it easier to update it. ``` Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_geolocation.so instead. Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_hotplug.so instead. Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_tasks.so instead. ``` Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121953: Add filename to KPluginInfo::property() deprecation notice.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121953/ --- (Updated Jan. 9, 2015, 5:07 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kservice Description --- Add filename to KPluginInfo::property() deprecation notice. Diffs - src/services/kplugininfo.cpp 98a2aa5c553c8a608afdaf82eee8fec9ca4ca60b Diff: https://git.reviewboard.kde.org/r/121953/diff/ Testing --- The deprecation notice for `KPluginInfo::property()` includes now the filename of the originating file, making it easier to update it. ``` Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_geolocation.so instead. Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_hotplug.so instead. Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated, use KPluginInfo::pluginName() in /usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_tasks.so instead. ``` Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121958: Deprecate kservice_desktop_to_json(), use kcoreaddons_desktop_to_json().
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121958/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Deprecate kservice_desktop_to_json(), use kcoreaddons_desktop_to_json(). Diffs - examples/dataengines/customDataContainers/CMakeLists.txt 7c6aef8b506ddbadc6d73ce917302ac828537ba1 examples/dataengines/simpleEngine/CMakeLists.txt aa8ce4703389134b63587c28a0afe5d7b5cba3a0 examples/dataengines/sourcesOnRequest/CMakeLists.txt d60a8fb07ea7197e54985325cdc8379dfd9851c2 tests/testengine/CMakeLists.txt 08735867acee249fbb903a5f40e0a783a13f6e6a Diff: https://git.reviewboard.kde.org/r/121958/diff/ Testing --- Builds + installs as expected Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121958: Deprecate kservice_desktop_to_json(), use kcoreaddons_desktop_to_json().
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121958/ --- (Updated Jan. 9, 2015, 10:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Deprecate kservice_desktop_to_json(), use kcoreaddons_desktop_to_json(). Diffs - examples/dataengines/customDataContainers/CMakeLists.txt 7c6aef8b506ddbadc6d73ce917302ac828537ba1 examples/dataengines/simpleEngine/CMakeLists.txt aa8ce4703389134b63587c28a0afe5d7b5cba3a0 examples/dataengines/sourcesOnRequest/CMakeLists.txt d60a8fb07ea7197e54985325cdc8379dfd9851c2 tests/testengine/CMakeLists.txt 08735867acee249fbb903a5f40e0a783a13f6e6a Diff: https://git.reviewboard.kde.org/r/121958/diff/ Testing --- Builds + installs as expected Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120267: Don't run kioexec if we are already running it
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120267/#review67855 --- This patch fixes the issue for me, but I can't really say much about the quality of the patch -- needs someone with some more domain-specific knowledge to give you a ship it. - Elias Probst On Sept. 18, 2014, 4:33 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120267/ --- (Updated Sept. 18, 2014, 4:33 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 339123 https://bugs.kde.org/show_bug.cgi?id=339123 Repository: kio Description --- Only add the actual command and url's otherwise we keep spawning instances of kioexec. Maybe we should rename the kioexec service from 'dummy' to 'kioexec-dummy' just to be safe. Diffs - src/core/desktopexecparser.cpp 9510697 Diff: https://git.reviewboard.kde.org/r/120267/diff/ Testing --- Run kioexec with local file from command line. Remote files don't work (before and after) I'll take a look at that next. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Compression of SVG(Z)s in git repositories
I've noticed, that (except of only a very few) nearly all SVG files are committed as SVGZ to our git repositories. This has IMHO several drawbacks: - every change will be stored as a single atomic blob - git's internal packfile compression and deduplication can't be used - no diffs for changes done to SVGs can be viewed - batch-editing of files via sed/awk/… is way more difficult I'd like to suggest to implement a git hook which enforces SVG files being pushed uncompressed. The compression of SVG to SVGZ might happen when building release tarballs. What are your thoughts? Any reasons not to do this? - Elias P. signature.asc Description: OpenPGP digital signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compression of SVG(Z)s in git repositories
On 09/02/2014 12:48 PM, Martin Gräßlin wrote: On Tuesday 02 September 2014 12:27:11 Sebastian Kügler wrote: On Monday, September 01, 2014 12:59:04 Elias Probst wrote: I've noticed, that (except of only a very few) nearly all SVG files are committed as SVGZ to our git repositories. This has IMHO several drawbacks: - every change will be stored as a single atomic blob - git's internal packfile compression and deduplication can't be used - no diffs for changes done to SVGs can be viewed - batch-editing of files via sed/awk/… is way more difficult I'd like to suggest to implement a git hook which enforces SVG files being pushed uncompressed. The compression of SVG to SVGZ might happen when building release tarballs. What are your thoughts? Any reasons not to do this? Compressed SVG files are way faster to read (it's faster to decompress the data than to read it from disk). Also, the on-disk footprint is lower.. Both of these affect the runtime performance of Plasma. which is not an argument against storing them as SVG in the repository. There could be a pre-install task in CMake which compresses them. Exactly. This might make sense to be placed in ECM to avoid duplication of this functionality all over the place. I think Elias suggestion makes sense on the git repository level, we just need to first put in place the CMake bits to ensure the installed files are still svgz. What I forgot to mention in my initial mail: This should be only enforced by the git push hook for newly added files, so a quick change to an existing file doesn't require one to rename it etc. Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel signature.asc Description: OpenPGP digital signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What to do with autostart scripts? (kinit / ksmserver problem)
On 08/19/2014 09:48 PM, David Faure wrote: What do the gurus say on this? I'd pick option 1 - do it all in ksmserver. I'd vote against this and vote for: - only *.desktop files The reason: in the long term, we're going to add support for systemd user-sessions. This will bring a huge cleanup effort for a lot of Plasma Workspace components which currently spawn subprocesses/modules, where one of the final goals is to have every singly spawned subprocess to be a transient systemd user-session unit. When using *.desktop files, this would be far easier to handle as they can be translated relatively straightforward into a transient unit, while doing it all in ksmserver would just mean, that we'd have to revert this at a later point again to implement transient units. - Elias signature.asc Description: OpenPGP digital signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118853: Log name + size of not found icons in debug output
On June 21, 2014, 9:36 a.m., Christoph Feck wrote: What is the status of categorized debugging/logging support in Qt, and how do we utilize that in our frameworks? If we are still simply using uncategorized qDebug(), please commit it. Luigi Toscano wrote: We can use qCDebug; the only problem is that right now (for what I know) categories can't be enabled/disabled dynamically, but statically from the code. See: http://community.kde.org/Frameworks/Porting_To_qCDebug In Qt 5.3 this should not be needed for KDE anymore because we should then be able to manage the logging categories from outside your application. So this means just this would be enough? qCDebug() my debug message; How will the result then look like? Will it be categorized based on the application using KF5 kiconloader? Or will kiconloader need its own logging category? - Elias --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118853/#review60646 --- On June 21, 2014, 2:53 a.m., Elias Probst wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118853/ --- (Updated June 21, 2014, 2:53 a.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- Currently I get to see this debug log message quite often: Warning: could not find unknown icon for size 48 This makes it hard to find out which icon was originally requested. This patch adds a debug log message including the name + size of the not found icon before attempting to load the unknown icon. Diffs - src/kiconloader.cpp 6e22f3e864db190f409550fcac964154c895ca6b Diff: https://git.reviewboard.kde.org/r/118853/diff/ Testing --- Debug log messages look now like this: Icon konsole for size 48 not found Warning: could not find unknown icon for size 48 Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 118853: Log name + size of not found icons in debug output
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118853/ --- Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- Currently I get to see this debug log message quite often: Warning: could not find unknown icon for size 48 This makes it hard to find out which icon was originally requested. This patch adds a debug log message including the name + size of the not found icon before attempting to load the unknown icon. Diffs - src/kiconloader.cpp 6e22f3e864db190f409550fcac964154c895ca6b Diff: https://git.reviewboard.kde.org/r/118853/diff/ Testing --- Debug log messages look now like this: Icon konsole for size 48 not found Warning: could not find unknown icon for size 48 Thanks, Elias Probst ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118841: Add notify to colorGroup property
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118841/#review60565 --- Fixes for me these messages from battery monitor: QQmlExpression: Expression file:///usr/lib64/qml/org/kde/plasma/workspace/components/BatteryIcon.qml:33:21 depends on non-NOTIFYable properties: ColorScope::colorGroup QQmlExpression: Expression file:///usr/lib64/qml/org/kde/plasma/workspace/components/BatteryIcon.qml:33:21 depends on non-NOTIFYable properties: ColorScope::colorGroup - Elias Probst On June 19, 2014, 9:34 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118841/ --- (Updated June 19, 2014, 9:34 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Add notify to colorGroup property Diffs - src/declarativeimports/core/colorscope.h b90bb61 Diff: https://git.reviewboard.kde.org/r/118841/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Usage of ~/.config vs ~/.config/kde.org
Currently all KF5/Workspaces configuration files end up in ~/.config. Looking at my personal ~/.config, it seems that nearly all other applications and desktop-environments make use of a subdirectory to prevent spamming the toplevel directory and isolate the related config files nicely. Compared to the situation of KDE SC 4.x where everything was nicely separated in ~/.kde/share/config the current situation is IMHO rather unsatisfying and makes e.g. resetting/backing up/etc. a user's complete KF5/Workspaces configuration really hard as one cannot simply target a single directory like ~/.config/kde.org/ In case this should be done, it needs to be done before the first final release, otherwise migrating this over at a later point will be a major PITA. What are your thoughts regarding this situation? - Elias P. signature.asc Description: OpenPGP digital signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
