D7270: [FileUndoManager] Enable undoing changes in read-only folders
dfaure added a comment. In https://phabricator.kde.org/D7270#136443, @chinmoyr wrote: > > Is this subclass needed? You could just move the code of its constructor to the UndoJob constructor, no? (using Q_D of course) > > I tried this before anything else and it didn't worked. Q_D requires a private class, right? Ah, good point, this would require a manual use of d_func() instead, to get to the private class of the base class. Here's how Qt does it in a few places: static_cast(d_func()). >> It seems to me that we only want to undo with "privilege execution enabled" if the original job has privilege execution enabled, no? >> This requires storing that information together with the undo information... > > If original job has the flag set and privilege operation succeeds, undo will be available and if the flag is not set then no operation will take place and undo won't be available. > So I don't think storing any other info is required. In Dolphin (for instance), all jobs triggered by the user will have the flag set, even those which didn't actually need privilege operations, right? So how can FileUndoManager make a difference between a file-copy in my home (no privilege needed, neither for the operation nor for the undo) and a file-copy into /etc (root privilege needed, both for the operation and for undo)? But yeah, I'm still undecided between two solutions: 1. only attempt privilege elevation at undo time if it was needed for the initial job 2. just like any other kio job, use privilege elevation after trying without, if that failed -- even if the initial job didn't need that. I can come up with reverse examples: `cp /root/.bashrc /tmp` : the initial operation needs root (to read the file), while undo doesn't need root (anyone can delete files in /tmp). I can't come up with an example where the initial operation doesn't need root but undo does... > I added the variable so that it can be toggled through a dolphin setting. My initial plan was to add a checkbox/toggle to dolphin's setting to "Enable/Disable undo in read-only folder" and read it in FileUndoManager. That time I assumed some users might want to disable undo inside a read-only folder. Personally I want Undo to be there all the time. Do you think there is any need to add such setting? Otherwise that variable can be removed and some of the issues you pointed will be solved as well. I'm pretty sure that this is "over-configurability". *Maybe* someone wants to disable the whole support for root prompts (e.g. to prevent their grandma from deleting files in /etc, on systems where root has the same password as user...), but I definitely don't see a use case for a checkbox that would be specifically about the undo support and only that. REVISION DETAIL https://phabricator.kde.org/D7270 To: chinmoyr, #frameworks, dfaure
D6197: Add kauth helper to file ioslave
dfaure requested changes to this revision.
dfaure added inline comments.
This revision now requires changes to proceed.
INLINE COMMENTS
> filehelper.cpp:34
> +FdSender fdSender;
> +fdSender.connectToPath("org_kde_kio_file_helper_socket");
> +if (fdSender.isConnected()) {
BTW what happens if two instances of this helper (and two instances of
kio_file) try to do this at the same time? Don't they need different socket
paths, to avoid interferring with each other?
I suppose the PID of the kio_file process should be added to this path, which
means passing it in the QVariantMap to exec(), right?
> filehelper.cpp:104
> +} else {
> +sendFileDescriptor(-1);
> +}
You send fd=-1 if opendir fails, but not if dirfd fails.
Is it even needed to send -1, if we're going to return an error reply anyway?
(disclaimer, I don't know sendFileDescriptor nor what the code on the calling
side does)
REVISION DETAIL
https://phabricator.kde.org/D6197
To: chinmoyr, elvisangelaccio, #frameworks, dfaure
D6829: Add ability to use the new kauth helper in file ioslave
dfaure requested changes to this revision.
dfaure added inline comments.
This revision now requires changes to proceed.
INLINE COMMENTS
> slavebase.cpp:1461
> +
> +PrivilegeOperationStatus SlaveBase::privilegeOperationStatus()
> +{
Oh, indeed, can't be const, because it's not a getter, it's a method that asks
for the status via communication with the app.
That means the naming could be improved.
Maybe something like queryPrivilegeOperationStatus() or
requestPrivilegeOperation().
> slavebase.cpp:1468
> +KIO::PrivilegeOperationStatus currentOperationStatus;
> +switch (buffer.toInt()) {
> +case 1:
Not needed, just return KIO::PrivilegeOperationStatus(buffer.toInt())
(constructor-like syntax - or static_cast if that doesn't work).
If you think casting is evil, hardcoding 1/2/3 is even more evil ;-)
And in this case casting is not evil at all, we simply serialize/deserialize
the enum using its integral value.
> slavebase.h:940
> + * Checks with job if privilege operation is allowed.
> + * @return one of the four status, OperationNotAllowed, OperationAllowed
> or OperationCanceled.
> + * @see PrivilegeOperationStatus
Four? I count only three. No need to duplicate the full enum docu anyway, it's
bound to go out-of-date at some point, just refer to the enum.
> file_unix.cpp:666
> +if (opStatus == KIO::OperationCanceled) {
> +mUserCanceled = true;
> +}
No chance to return an enum instead of a bool here, to avoid modifying state?
The problem with mUserCanceled is that it's easy to get it wrong. Like in this
patch, which never resets it to false for the next operation after one canceled
operation. It's just cleaner to return an enum instead of modifying a member
variable temporarily, although the question is, in both cases, what the caller
code will look like...
My fear with a member var is that too many callers will forget to check it.
Let's approach this from the viewpoint of the calling code.
Before:
if (!dir.rmdir(itemPath)) {
error(KIO::ERR_CANNOT_DELETE, itemPath);
return false;
}
After:
if (!dir.rmdir(itemPath)) {
if (auto ret = execWithElevatedPrivilege(RMDIR, itemPath)) { // for this
to work, success must be 0 (or the returned type can be a class with operator
bool()...)
if (ret == KIO::OperationCanceled) { // or a different enum
error(KIO::ERR_USER_CANCELED, itemPath);
} else {
error(KIO::ERR_CANNOT_DELETE, itemPath);
}
return false;
}
}
Alternatively, since we know cancelling will always need to
error(KIO::ERR_USER_CANCELED) (and the QString argument doesn't matter), we
could call error from within execWithElevatedPrivilege. But we still need the
enum ret val:
if (!dir.rmdir(itemPath)) {
if (auto ret = execWithElevatedPrivilege(RMDIR, itemPath)) { // see above
if (ret != KIO::OperationCanceled) { // or a different enum
error(KIO::ERR_CANNOT_DELETE, itemPath);
}
return false;
}
}
I actually like the idea of returning a small class. Then it could even have a
wasCanceled() method... we don't need an enum, we need a value that can convert
to bool (for the if) and additionally let us know if cancelation happened. But
all this in a temporary value, not in a member var of slavebase.
To flesh it out in more details:
class ExecWithElevatedPrivilegeReturnValue
{
public:
static ExecWithElevatedPrivilegeReturnValue success() { return
ExecWithElevatedPrivilegeReturnValue{true, false}; }
static ExecWithElevatedPrivilegeReturnValue failure() { return
ExecWithElevatedPrivilegeReturnValue{true, false}; }
static ExecWithElevatedPrivilegeReturnValue canceled() { return
ExecWithElevatedPrivilegeReturnValue{true, true}; }
operator bool() const { return m_success; }
bool wasCanceled() const { return m_canceled; }
private:
ExecWithElevatedPrivilegeReturnValue(bool success, bool canceled) :
m_success(success), m_canceled(canceled) {}
const bool m_success;
const bool m_canceled;
};
(no setters, all of the slave code shouldn't be able to change this object,
it's created immediately with the right values)
With this, the calling code can be simply
if (!dir.rmdir(itemPath)) {
if (auto ret = execWithElevatedPrivilege(RMDIR, itemPath)) {
if (!ret.wasCanceled()) {
error(KIO::ERR_CANNOT_DELETE, itemPath);
}
return false;
}
}
and the code in this review (execWithElevatedPrivilege) can do things like
`return ExecWithElevatedPrivilegeReturnValue::canceled();` etc.
How does that sound?
REVISION DETAIL
https://phabricator.kde.org/D6829
To: chinmoyr, dfaure, #frameworks
Cc: #frameworks
D7270: [FileUndoManager] Enable undoing changes in read-only folders
chinmoyr added a comment. > Is this subclass needed? You could just move the code of its constructor to the UndoJob constructor, no? (using Q_D of course) I tried this before anything else and it didn't worked. Q_D requires a private class, right? > It seems to me that we only want to undo with "privilege execution enabled" if the original job has privilege execution enabled, no? > This requires storing that information together with the undo information... If original job has the flag set and privilege operation succeeds, undo will be available and if the flag is not set then no operation will take place and undo won't be available. So I don't think storing any other info is required. > (if I understand correctly, the flag in kio jobs is mostly so that jobs triggered programmatically rather than via user interaction never prompt with polkit; but only jobs from the user get undo support, and only jobs where polkit was used would need polkit during undo ... unless I'm missing something). actually its flag+setParentJob combo that controls triggering of any kind of prompt. > So I'm a bit undecided, but I welcome any thoughts in this reflection ;) I added the variable so that it can be toggled through a dolphin setting. My initial plan was to add a checkbox/toggle to dolphin's setting to "Enable/Disable undo in read-only folder" and read it in FileUndoManager. That time I assumed some users might want to disable undo inside a read-only folder. Personally I want Undo to be there all the time. Do you think there is any need to add such setting? Otherwise that variable can be removed and some of the issues you pointed will be solved as well. REVISION DETAIL https://phabricator.kde.org/D7270 To: chinmoyr, #frameworks, dfaure
D7316: Avoid sending data offers from an invalid source.
graesslin accepted this revision. graesslin added a comment. This revision is now accepted and ready to land. Nevertheless I still think we should also ship my review. Rather a null check too many than too few. REPOSITORY R127 KWayland BRANCH master REVISION DETAIL https://phabricator.kde.org/D7316 To: davidedmundson, #plasma, graesslin Cc: mart, graesslin, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, lukas
D6829: Add ability to use the new kauth helper in file ioslave
chinmoyr updated this revision to Diff 18242. chinmoyr added a comment. - Added variable (mUserCanceled) to denote if user canceled operation - Return PrivilegeOperationStatusin SlaveBase's method. Went with switch instead static_cast. Cannot make it const. - Cancelled -> Canceled CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6829?vs=18206=18242 BRANCH master REVISION DETAIL https://phabricator.kde.org/D6829 AFFECTED FILES src/core/global.h src/core/slavebase.cpp src/core/slavebase.h src/core/slaveinterface.cpp src/core/slaveinterface.h src/ioslaves/file/file.cpp src/ioslaves/file/file.h src/ioslaves/file/file_unix.cpp src/ioslaves/file/file_win.cpp To: chinmoyr, dfaure, #frameworks Cc: #frameworks
KDE CI: Frameworks kcoreaddons kf5-qt5 XenialQt5.7 - Build # 47 - Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20XenialQt5.7/47/ Project: Frameworks kcoreaddons kf5-qt5 XenialQt5.7 Date of build: Wed, 16 Aug 2017 14:14:11 + Build duration: 5 min 7 sec and counting JUnit Tests Name: (root) Failed: 3 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 25 test(s)Failed: TestSuite.kdirwatch_fam_unittestFailed: TestSuite.kdirwatch_inotify_unittestFailed: TestSuite.kdirwatch_qfswatch_unittest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report100% (10/10)85% (79/93)85% (79/93)74% (6126/8284)44% (10789/24636)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests83% (33/40)83% (33/40)97% (2635/2718)49% (6538/13336)src.desktoptojson100% (3/3)100% (3/3)79% (84/106)38% (123/324)src.lib67% (2/3)67% (2/3)60% (326/541)27% (221/821)src.lib.caching100% (2/2)100% (2/2)45% (352/787)18% (192/1076)src.lib.io90% (9/10)90% (9/10)60% (840/1397)33% (1048/3158)src.lib.jobs71% (5/7)71% (5/7)52% (159/304)39% (57/146)src.lib.plugin100% (8/8)100% (8/8)86% (648/750)44% (990/2228)src.lib.randomness100% (2/2)100% (2/2)67% (66/99)58% (44/76)src.lib.text63% (5/8)63% (5/8)46% (349/764)40% (748/1867)src.lib.util100% (10/10)100% (10/10)82% (667/818)52% (828/1604) build.log Description: Binary data
KDE CI: Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.7 - Build # 42 - Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20FreeBSDQt5.7/42/ Project: Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.7 Date of build: Wed, 16 Aug 2017 14:14:11 + Build duration: 2 min 45 sec and counting JUnit Tests Name: (root) Failed: 2 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 22 test(s)Failed: TestSuite.kdirwatch_stat_unittestFailed: TestSuite.kshelltest build.log Description: Binary data
D7347: Add support for uninstalled plugins in kcoreaddons_add_plugin
This revision was automatically updated to reflect the committed changes. Closed by commit R244:3dfa71021300: Add support for uninstalled plugins in kcoreaddons_add_plugin (authored by elvisangelaccio). REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7347?vs=18237=18238 REVISION DETAIL https://phabricator.kde.org/D7347 AFFECTED FILES KF5CoreAddonsMacros.cmake To: elvisangelaccio, #build_system, dfaure Cc: #frameworks
D7347: Add support for uninstalled plugins in kcoreaddons_add_plugin
dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. Oh wow, even more magic, to make it even easier. Cool ! Please make sure to document the solution in the wiki - and feel free to port KIO to it ;-) REPOSITORY R244 KCoreAddons BRANCH master REVISION DETAIL https://phabricator.kde.org/D7347 To: elvisangelaccio, #build_system, dfaure Cc: #frameworks
D7347: Add support for uninstalled plugins in kcoreaddons_add_plugin
elvisangelaccio retitled this revision from "Add support for uninstalled plugin in kcoreaddons_add_plugin" to "Add support for uninstalled plugins in kcoreaddons_add_plugin". REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D7347 To: elvisangelaccio, #build_system, dfaure Cc: #frameworks
D7347: Add support for uninstalled plugin in kcoreaddons_add_plugin
elvisangelaccio created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY If find_package(ECM 5.38) or higher was called, output the plugin in a INSTALL_NAMESPACE subfolder of the "bin" folder. This way users of the kcoreaddons_add_plugin macro don't have to manually set the LIBRARY_OUTPUT_DIRECTORY target property (in order to make the plugin work even if uninstalled). REPOSITORY R244 KCoreAddons BRANCH master REVISION DETAIL https://phabricator.kde.org/D7347 AFFECTED FILES KF5CoreAddonsMacros.cmake To: elvisangelaccio, #build_system, dfaure Cc: #frameworks
Review Request 130228: Mingw32 compile fix
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/130228/ --- Review request for KDE Frameworks. Repository: kdelibs4support Description --- Mingw32 compile fix Diffs - src/solid/networking_p.h 894f2fa9259ed3626c6a5e10970eca55afa8cd79 src/solid/networking_win.cpp 354ab3acf6e0d771907792270f209394065ae94b Diff: https://git.reviewboard.kde.org/r/130228/diff/ Testing --- Thanks, Ralf Habacker
D6197: Add kauth helper to file ioslave
chinmoyr added inline comments. INLINE COMMENTS > dfaure wrote in filehelper.cpp:46 > Well, this proves exactly my earlier point: we should only test errno *when* > a libc function fails. > > If this code is still checking errno after success somewhere, then *that* it > what should be fixed. And once it's fixed, there's no need to reset errno > here. > > (BTW strerror(11) is EAGAIN, "Resource temporarily unavailable", rather > frequent for non-blocking sockets, which is probably what triggered the slave > to wake up in the first place.) > > So, where is this code checking for errno even after success? In the caller > of this method? It's hard to review all these separate review requests > because I never have a global overview or the ability to search across the > whole codebase -- but at the same time, everything in a single merge request > would kill this slow webbrowser... [QtWebEngine compiled in debug mode] :-) Actually action OPEN and OPENDIR were relying on this errno assignment (in the previous revision). I forgot that in this revision both of them return on success. I have now removed that statement. Sorry for the trouble. REVISION DETAIL https://phabricator.kde.org/D6197 To: chinmoyr, elvisangelaccio, #frameworks, dfaure
D6197: Add kauth helper to file ioslave
chinmoyr updated this revision to Diff 18235. chinmoyr added a comment. - Remove errno assignment CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6197?vs=18201=18235 BRANCH master REVISION DETAIL https://phabricator.kde.org/D6197 AFFECTED FILES src/ioslaves/file/CMakeLists.txt src/ioslaves/file/file_p.h src/ioslaves/file/kauth/CMakeLists.txt src/ioslaves/file/kauth/file.actions src/ioslaves/file/kauth/filehelper.cpp src/ioslaves/file/kauth/filehelper.h To: chinmoyr, elvisangelaccio, #frameworks, dfaure
KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 43 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/43/ Project: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 Date of build: Wed, 16 Aug 2017 11:32:31 + Build duration: 58 min and counting JUnit Tests Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.qmltests build.log Description: Binary data
KDE CI: Frameworks baloo kf5-qt5 XenialQt5.7 - Build # 20 - Still unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20baloo%20kf5-qt5%20XenialQt5.7/20/ Project: Frameworks baloo kf5-qt5 XenialQt5.7 Date of build: Wed, 16 Aug 2017 09:45:08 + Build duration: 55 min and counting JUnit Tests Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 39 test(s)Failed: TestSuite.kinotifytest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report100% (12/12)77% (111/144)77% (111/144)73% (5039/6932)50% (2613/5194)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests.benchmarks100% (2/2)100% (2/2)100% (42/42)89% (16/18)autotests.integration100% (3/3)100% (3/3)95% (242/255)64% (140/220)autotests.unit.codecs100% (3/3)100% (3/3)100% (40/40)57% (25/44)autotests.unit.engine100% (17/17)100% (17/17)100% (736/736)53% (390/740)autotests.unit.file100% (11/11)100% (11/11)97% (788/809)51% (438/864)autotests.unit.lib100% (6/6)100% (6/6)97% (315/326)52% (156/302)src.codecs100% (5/5)100% (5/5)87% (120/138)76% (32/42)src.engine97% (38/39)97% (38/39)79% (1607/2038)58% (796/1379)src.file39% (17/44)39% (17/44)45% (678/1506)38% (374/980)src.file.extractor100% (2/2)100% (2/2)69% (20/29)58% (7/12)src.file.extractor.autotests100% (1/1)100% (1/1)100% (22/22)61% (11/18)src.lib55% (6/11)55% (6/11)43% (429/991)40% (228/575) build.log Description: Binary data
KDE CI: Frameworks kcoreaddons kf5-qt5 XenialQt5.7 - Build # 46 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20XenialQt5.7/46/ Project: Frameworks kcoreaddons kf5-qt5 XenialQt5.7 Date of build: Wed, 16 Aug 2017 09:45:19 + Build duration: 52 min and counting JUnit Tests Name: (root) Failed: 0 test(s), Passed: 25 test(s), Skipped: 0 test(s), Total: 25 test(s) Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report100% (10/10)85% (79/93)85% (79/93)74% (6130/8284)44% (10755/24636)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests83% (33/40)83% (33/40)97% (2631/2718)49% (6497/13336)src.desktoptojson100% (3/3)100% (3/3)79% (84/106)38% (123/324)src.lib67% (2/3)67% (2/3)60% (326/541)27% (221/821)src.lib.caching100% (2/2)100% (2/2)45% (352/787)18% (192/1076)src.lib.io90% (9/10)90% (9/10)61% (848/1397)33% (1055/3158)src.lib.jobs71% (5/7)71% (5/7)52% (159/304)39% (57/146)src.lib.plugin100% (8/8)100% (8/8)86% (648/750)44% (990/2228)src.lib.randomness100% (2/2)100% (2/2)67% (66/99)58% (44/76)src.lib.text63% (5/8)63% (5/8)46% (349/764)40% (748/1867)src.lib.util100% (10/10)100% (10/10)82% (667/818)52% (828/1604) build.log Description: Binary data
D7337: Port rest of scripting API to QJSValue-based solution
cullmann added a comment. Think that would be nice. Then we always have only that tuple of functions, makes it less confusing (and less to maintain). REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D7337 To: dhaumann, carewolf, cullmann Cc: kwrite-devel, #frameworks
KDE CI: Frameworks kglobalaccel kf5-qt5 WindowsQt5.7 - Build # 19 - Still unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kglobalaccel%20kf5-qt5%20WindowsQt5.7/19/ Project: Frameworks kglobalaccel kf5-qt5 WindowsQt5.7 Date of build: Wed, 16 Aug 2017 09:45:27 + Build duration: 12 min and counting JUnit Tests Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.kglobalshortcuttest build.log Description: Binary data
KDE CI: Frameworks kcoreaddons kf5-qt5 WindowsQt5.7 - Build # 47 - Still unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20WindowsQt5.7/47/ Project: Frameworks kcoreaddons kf5-qt5 WindowsQt5.7 Date of build: Wed, 16 Aug 2017 09:45:20 + Build duration: 8 min 16 sec and counting JUnit Tests Name: (root) Failed: 3 test(s), Passed: 19 test(s), Skipped: 0 test(s), Total: 22 test(s)Failed: TestSuite.kdelibs4configmigratortestFailed: TestSuite.kdirwatch_qfswatch_unittestFailed: TestSuite.krandomtest build.log Description: Binary data
D7316: Avoid sending data offers from an invalid source.
mart added a comment. +1 REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D7316 To: davidedmundson, #plasma Cc: mart, graesslin, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, lukas
D7337: Port rest of scripting API to QJSValue-based solution
dhaumann added a comment. Yes, Allen is correct: Essentially, we could remove all helper functions that use KTE::Range/Cursor. Shall I update the patch? REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D7337 To: dhaumann, carewolf, cullmann Cc: kwrite-devel, #frameworks
D7337: Port rest of scripting API to QJSValue-based solution
carewolf added a comment. A few of the cursor/range functions are used, but not all of them. You could probably rewrite the places using them to use line+col instead. REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D7337 To: dhaumann, carewolf, cullmann Cc: kwrite-devel, #frameworks
KF5Solid in subprefix and/or on [K]Ubuntu 14.04
Hi, As you know I've been building my own KF5 (and Qt5) packages for installation into /opt/local on an up-to-date Ubuntu 14.04LTS system. I register the required directories under /opt/local with DBus so (almost) everything works as you'd expect. On notable difference I just discovered: KF5Solid apparently cannot read the vendor, product and description info for almost none of the available devices (via solid-hardware5; solid-hardware does). Exceptions are the CPU, battery, the internal drive and external USB drives and of course fstab entries. The differences in the UDIs found are minimal (see below). What could be the reason why this information isn't available for so many devices? Thanks, R. --- solid-hardware.log 2017-08-16 11:02:45.469481175 +0200 +++ solid-hardware5.log 2017-08-16 11:02:52.748481015 +0200 @@ -54,10 +54,6 @@ udi = '/org/kde/fstab/portia:/Volumes/Debian' udi = '/org/kde/fstab/portia:/Volumes/Win' udi = '/org/kde/fstab///tcaprjvb.local/tCapRJVB1' -udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3' -udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0' -udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2' -udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/video4linux/video0' udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/audio' udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/controlC0' udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/dsp' @@ -69,6 +65,9 @@ udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/pcmC0D3p' udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1c.0/:01:00.2/net/eth4' udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1c.1/:02:00.0/net/wlan2' +udi = '/org/kde/solid/udev/sys/devices/platform/i8042/serio2/input/input11' +udi = '/org/kde/solid/udev/sys/devices/platform/i8042/serio2/input/input11/event6' +udi = '/org/kde/solid/udev/sys/devices/platform/i8042/serio2/input/input11/mouse0' udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS0' udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS1' udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS10'
D7337: Port rest of scripting API to QJSValue-based solution
cullmann added a comment. Question: Do we need the overloads with the KTextEditor::Cursor at all or should we limit that to line/column + QJSValue? REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D7337 To: dhaumann, carewolf, cullmann Cc: kwrite-devel, #frameworks
D7341: [KDesktopPropsPlugin] Create destination directory if it doesn't exist
wbauer created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY If the directory doesn't exist, applying the changes will fail with "Could not save properties. You do not have sufficient access to write to xxx". TEST PLAN Open the file associations dialog, select some file type and choose an associated application that has its .desktop file in a subfolder of /usr/share/applications/ (e.g. on openSUSE, all KDE4 applications install it to /usr/share/applications/kde4/). Make sure that the corresponding folder ~/.local/share/applications/kde4/ doesn't exist. Click on "Edit...", change something on the "Program" tab (e.g. the command to execute), and click on "OK". The directory ~/.local/share/applications/kde4/ is created now and the changes are saved correctly. Before you got an error dialog and the changes were lost. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7341 AFFECTED FILES src/widgets/kpropertiesdialog.cpp To: wbauer, dfaure Cc: #frameworks
