D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies
Zren added a reviewer: apol. REPOSITORY R252 Framework Integration REVISION DETAIL https://phabricator.kde.org/D8636 To: Zren, apol Cc: #frameworks
D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies
Zren edited the test plan for this revision. REPOSITORY R252 Framework Integration REVISION DETAIL https://phabricator.kde.org/D8636 To: Zren Cc: #frameworks
D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies
Zren edited the test plan for this revision. REPOSITORY R252 Framework Integration REVISION DETAIL https://phabricator.kde.org/D8636 To: Zren Cc: #frameworks
D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies
Zren created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Implementing the feature request in BUG #385429. https://bugs.kde.org/show_bug.cgi?id=385429 LookAndFeels introduced the ability to set dependencies, that are downloaded first before installing the look and feel package. https://userbase.kde.org/Plasma/Create_a_Look_and_Feel_Package Eg: X-KPackage-Dependencies=kns://plasmoids.knsrc/api.kde-look.org/1160672 It will call: /usr/lib/x86_64-linux-gnu/libexec/kf5/kpackagehandlers/knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672 Previously this file called `engine.install(entry);` the second argument (`linkId`) isn't supplied so it defaults to 1. void install(KNSCore::EntryInternal entry, int linkId = 1); This means it downloads the first link, which for me is the oldest version of the widget typically. https://api.kde-look.org/ocs/v1/content/download/1160672/1 tells it to download tiledmenu-v05-kde5.5.plasmoid while https://api.kde-look.org/ocs/v1/content/download/1160672/3 tells it to download the latest version tiledmenu-v18-kde5.9.plasmoid This patch adds the ability to specify which link to download in the 3rd path section. Eg: `kns://plasmoids.knsrc/api.kde-look.org/1160672/3` TEST PLAN Shorten the command call for testing since knshandler isn't in `$PATH`. alias knshandler='/usr/lib/x86_64-linux-gnu/libexec/kf5/kpackagehandlers/knshandler' knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672 // Installs tiledmenu-v05-kde5.5.plasmoid knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2 // Should error, since we didn't uninstall the previous version. Should log: // Command ' "kpackagetool5 --install /tmp/tiledmenu-v05-kde5.5.plasmoid --type Plasma/Applet" ' failed with code 4 /tmp/tiledmenu-v05-kde5.5.plasmoid knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2 // Should error, since we didn't uninstall the previous version. Should log: // Command ' "kpackagetool5 --install /tmp/tiledmenu-v11-kde5.6.plasmoid --type Plasma/Applet" ' failed with code 4 knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/3 // Should error, since we didn't uninstall the previous version. Should log: // Command ' "kpackagetool5 --install /tmp/tiledmenu-v18-kde5.9.plasmoid --type Plasma/Applet" ' failed with code 4 knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/3 // Should error, since we didn't uninstall the previous version. Should log: // Command ' "kpackagetool5 --install /tmp/tiledmenu-v18-kde5.9.plasmoid --type Plasma/Applet" ' failed with code 4 knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/test // linkId is not an integer QUrl("kns://plasmoids.knsrc/api.kde-look.org/1160672/test") ("api.kde-look.org", "1160672", "test") knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2/test // wrong format in the url path QUrl("kns://plasmoids.knsrc/api.kde-look.org/1160672/2/test") ("api.kde-look.org", "1160672", "2", "test") knshandler kns://plasmoids.knsrc/api.kde-look.org/ // wrong format in the url path QUrl("kns://plasmoids.knsrc/api.kde-look.org/") ("api.kde-look.org") REPOSITORY R252 Framework Integration REVISION DETAIL https://phabricator.kde.org/D8636 AFFECTED FILES src/kpackage-install-handlers/kns/main.cpp To: Zren Cc: #frameworks
D7828: fix createKMessageBox focus widget inconsistency
This revision was automatically updated to reflect the committed changes. Closed by commit R236:19a313ecc90c: fix createKMessageBox focus widget inconsistency (authored by emateli, committed by ngraham). REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7828?vs=21453&id=21820 REVISION DETAIL https://phabricator.kde.org/D7828 AFFECTED FILES src/kmessagebox.cpp To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks
D7828: fix createKMessageBox focus widget inconsistency
ngraham added a comment. I think we've got enough thumbs up. I'm gonna land this. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D7828 To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks
D8633: KLauncher: remove dead code related to autostart.
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R303 KInit BRANCH master REVISION DETAIL https://phabricator.kde.org/D8633 To: dfaure, davidedmundson Cc: #plasma, #frameworks
Re: Python bindings using cppyy (was: An update on Python bindings)
Albert, On 2 November 2017 at 21:43, Albert Astals Cid wrote: > El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va > escriure: >> A progress update... >> >> On 24 October 2017 at 13:05, Shaheed Haque wrote: >> > Hi all, >> > >> > I have a preliminary version of the Cppyy bindings generator CMake >> > >> > support available here: >> > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-ex >> > perimental-version-of-a/diff> >> > There are some TODOs yet to be addressed, >> >> The original TODOs and bugs have been resolved, and there is the >> beginnings of support for packaging frameworks under a Python >> namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm >> close [1] to being able to generate a *complete* set of bindings for >> all of Akonadi driven from CMake with just 2-3 lines of custom logic. >> This contrasts with the 549 SLOC of customisation needed to produce a >> substantially slash-and-burned subset of Akonadi [2] with the >> SIP-based approach. >> >> > but I would appreciate >> > feedback on how easy it would be to integrate this with KDE's >> > buildsystem, especially for the frameworks. I'm a CMake noob, but the >> > basic idea I have is that the packager of some_framework might do >> > something like this: >> > >> > find_package(cppyy) >> > CPPYY_ADD_BINDINGS( >> > >> > ... >> > LINK_LIBRARIES some_framework_LIBRARIES >> > H_DIR some_framework_INCLUDE_DIRS >> > H_FILES ) >> >> In the course of working through the "KF5" namespace implementation, >> it has become apparent to me that a framework-by-framework integration >> of the binding generation logic (as previously pioneered by Steve) >> probably cannot work in general because there are cases where multiple >> frameworks contribute to to the same C++ namespace, for example: >> >> $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi* >> /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi >> .. >> /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi >> .. >> /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h: >> namespace Akonadi >> .. >> /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi >> .. >> /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi >> .. >> >> The problem is that the Python implementation of these namespaces is a >> class, and so treating these frameworks (let's not quibble over >> whether KF5Akonadi* are truly KF5 frameworks, the point is more >> general) as separate would result in multiple colliding Python class >> definitions. The only solution I can see would be to bundle all of >> KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and >> AFAICS, this can only be done out of tree from the individual >> frameworks, say in kde-bindings.git [3]. > > Sincerely if you go with out ot tree bindings they will always be broken > because people working on the frameworks won't even see them, if the problem > is that frameworks have to be self-contained, this seems like a good general > rule to me and maybe what we should do is fix the libs? Thanks for the input, but... Firstly, we have existence proofs in the form of PyQt and the PyKDE4 bindings that (even with the SIP support tax), that out of tree bindings are possible, and I am hopeful that things will be much easier with cppyy. Also, I wonder how easy that will be given the need to keep source compatibility? I've hardly done a comprehensive survey, but if the Akonadi example is anything to go by, I don't think there is a short term prospect of seeing a solution to this problem. If there is developer effort available from framework owners, I'd much rather see that put to productive use (there are plenty of point issues like #includes broken-from-my-POV and the like). Finally, not to put to fine a point on it, I've been working on this for the best part of two years, and I am very keen to get to something workable. (Not least because I hope to get a job at some point...and then intensive effort from me at least might be much trickier to offer up). Cheers, Shaheed > Cheers, > Albert > >> >> The work to date attempts to maintain a clean separation such that all >> C++ builds are done from CMake, and all Python builds are done using >> setuptools/pip. >> >> Apart from working through bugs [1], the remaining work items I can >> >> think of are, as before: >> >> - Need to look into the exact usage of Qt-specifics: signals/slots and >> >> interoperability with SIP-based PyQt >> >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glu >> >> e-ing-applications, >> >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html) >> >> >> >> - Need to figure out how any customisations which *are* required >> >> should be handled. >> >> plus: >> >> - I'm working with upstream on how to support discovery (e.g. via >> autocompletion in Python3). There is some POC-level hackery in git as >> above
D8336: Improve apidox of KJobTrackerInterface
elvisangelaccio added a comment. @kossebau Ping? REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D8336 To: elvisangelaccio, kossebau, dfaure Cc: apol, #frameworks
D8633: KLauncher: remove dead code related to autostart.
dfaure created this revision. dfaure added a reviewer: davidedmundson. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY ksmserver takes care of it (and no longer calls this code) since August 2016, see https://phabricator.kde.org/R120:d9883511c92e448b3441d994170fa1d43eea4ff2 in plasma-workspace. I have moved autostarttest.cpp to ksmserver just now. TEST PLAN none, dead code REPOSITORY R303 KInit BRANCH master REVISION DETAIL https://phabricator.kde.org/D8633 AFFECTED FILES CMakeLists.txt src/klauncher/klauncher.cpp src/klauncher/klauncher.h src/klauncher/klauncher_adaptor.cpp src/klauncher/klauncher_adaptor.h tests/CMakeLists.txt tests/autostarttest.cpp To: dfaure, davidedmundson Cc: #plasma, #frameworks
Re: Python bindings using cppyy (was: An update on Python bindings)
El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va escriure: > A progress update... > > On 24 October 2017 at 13:05, Shaheed Haque wrote: > > Hi all, > > > > I have a preliminary version of the Cppyy bindings generator CMake > > > > support available here: > > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-ex > > perimental-version-of-a/diff> > > There are some TODOs yet to be addressed, > > The original TODOs and bugs have been resolved, and there is the > beginnings of support for packaging frameworks under a Python > namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm > close [1] to being able to generate a *complete* set of bindings for > all of Akonadi driven from CMake with just 2-3 lines of custom logic. > This contrasts with the 549 SLOC of customisation needed to produce a > substantially slash-and-burned subset of Akonadi [2] with the > SIP-based approach. > > > but I would appreciate > > feedback on how easy it would be to integrate this with KDE's > > buildsystem, especially for the frameworks. I'm a CMake noob, but the > > basic idea I have is that the packager of some_framework might do > > something like this: > > > > find_package(cppyy) > > CPPYY_ADD_BINDINGS( > > > > ... > > LINK_LIBRARIES some_framework_LIBRARIES > > H_DIR some_framework_INCLUDE_DIRS > > H_FILES ) > > In the course of working through the "KF5" namespace implementation, > it has become apparent to me that a framework-by-framework integration > of the binding generation logic (as previously pioneered by Steve) > probably cannot work in general because there are cases where multiple > frameworks contribute to to the same C++ namespace, for example: > > $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi* > /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi > .. > /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi > .. > /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h: > namespace Akonadi > .. > /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi > .. > /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi > .. > > The problem is that the Python implementation of these namespaces is a > class, and so treating these frameworks (let's not quibble over > whether KF5Akonadi* are truly KF5 frameworks, the point is more > general) as separate would result in multiple colliding Python class > definitions. The only solution I can see would be to bundle all of > KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and > AFAICS, this can only be done out of tree from the individual > frameworks, say in kde-bindings.git [3]. Sincerely if you go with out ot tree bindings they will always be broken because people working on the frameworks won't even see them, if the problem is that frameworks have to be self-contained, this seems like a good general rule to me and maybe what we should do is fix the libs? Cheers, Albert > > The work to date attempts to maintain a clean separation such that all > C++ builds are done from CMake, and all Python builds are done using > setuptools/pip. > > Apart from working through bugs [1], the remaining work items I can > > think of are, as before: > >> - Need to look into the exact usage of Qt-specifics: signals/slots and > >> interoperability with SIP-based PyQt > >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glu > >> e-ing-applications, > >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html) > >> > >> - Need to figure out how any customisations which *are* required > >> should be handled. > > plus: > > - I'm working with upstream on how to support discovery (e.g. via > autocompletion in Python3). There is some POC-level hackery in git as > above, but there is work ongoing with upstream to find a robust > solution. > > - Flesh out how to make one set of bindings depend on another (e.g. > tier 2 framework bindings might depend on tier 1 bindings, or maybe it > is better to avoid PyQt and just produce cppyy-based bindings for Qt > and depend on those). > > As always, comments/ideas/suggestions are welcome. > > Thanks, Shaheed > > [1] There is a bug with namespaced externs being worked on with upstream. > > [2] > https://github.com/ShaheedHaque/extra-cmake-modules/blob/shaheed_master/fin > d-modules/module_generation/PyKF5/Akonadi.py > > [3] I attach an example CMakeLists.txt which shows now this can be > driven from CMake for the case of KF5Akonadi*...the implementation is > intended to serve as the basis for a generic solution usable across > KF5 at least. > > > On 16 October 2017 at 16:16, Shaheed Haque wrote: > >> As promised, here is an interim update on the investigation into the > >> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based > >> bindings. > >> > >> The first thing is that the underlying technology of cppyy, > >> cling/ROOT, h
D8632: kded: remove dbus calls to ksplash.
dfaure created this revision. dfaure added a reviewer: davidedmundson. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Not needed anymore since June 2016 (b6058a0 in plasma-workspace, i.e. Plasma 5.7). Originally at https://git.reviewboard.kde.org/r/129010/ TEST PLAN none, this is dead code REPOSITORY R297 KDED BRANCH master REVISION DETAIL https://phabricator.kde.org/D8632 AFFECTED FILES src/kded.cpp To: dfaure, davidedmundson Cc: #plasma, #frameworks
D8348: Add a section for removable devices
renatoo updated this revision to Diff 21808. renatoo added a comment. Updated parent branch REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8348?vs=21759&id=21808 REVISION DETAIL https://phabricator.kde.org/D8348 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h To: renatoo, #dolphin, #frameworks, #vdg, ervin, ngraham Cc: mlaurent, anthonyfieroni, ngraham, #frameworks
D8332: Added baloo urls into places model
renatoo marked an inline comment as done. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8434: Created 'remote' section
renatoo updated this revision to Diff 21809. renatoo added a comment. Updated parent branch REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8434?vs=21760&id=21809 REVISION DETAIL https://phabricator.kde.org/D8434 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h To: renatoo, ngraham, #frameworks, #dolphin, mwolff, mlaurent Cc: elvisangelaccio, mwolff, mlaurent, #frameworks
D8332: Added baloo urls into places model
renatoo updated this revision to Diff 21807. renatoo added a comment. Added warning message for invalid search:// urls REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8332?vs=21758&id=21807 REVISION DETAIL https://phabricator.kde.org/D8332 AFFECTED FILES autotests/CMakeLists.txt autotests/kfileplacesmodeltest.cpp autotests/kfileplacesviewtest.cpp src/filewidgets/kfileplacesmodel.cpp src/filewidgets/kfileplacesview.cpp To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D6317: fix crash on Windows when deleting an instance of QtMultimediaExtractor
mgallien added a comment. Sorry for the delay, currently I have no easy access to a development computer running Windows. David, I am afraid I have not understood correctly your suggestion. Did you suggest to make mMetadataExtractor have its thread as Qt parent ? REPOSITORY R286 KFileMetaData BRANCH master REVISION DETAIL https://phabricator.kde.org/D6317 To: mgallien, #frameworks, davidedmundson Cc: davidedmundson, #frameworks
Re: Python bindings using cppyy (was: An update on Python bindings)
A progress update... On 24 October 2017 at 13:05, Shaheed Haque wrote: > Hi all, > > I have a preliminary version of the Cppyy bindings generator CMake > support available here: > > > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a/diff > > There are some TODOs yet to be addressed, The original TODOs and bugs have been resolved, and there is the beginnings of support for packaging frameworks under a Python namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm close [1] to being able to generate a *complete* set of bindings for all of Akonadi driven from CMake with just 2-3 lines of custom logic. This contrasts with the 549 SLOC of customisation needed to produce a substantially slash-and-burned subset of Akonadi [2] with the SIP-based approach. > but I would appreciate > feedback on how easy it would be to integrate this with KDE's > buildsystem, especially for the frameworks. I'm a CMake noob, but the > basic idea I have is that the packager of some_framework might do > something like this: > > find_package(cppyy) > CPPYY_ADD_BINDINGS( > ... > LINK_LIBRARIES some_framework_LIBRARIES > H_DIR some_framework_INCLUDE_DIRS > H_FILES ) In the course of working through the "KF5" namespace implementation, it has become apparent to me that a framework-by-framework integration of the binding generation logic (as previously pioneered by Steve) probably cannot work in general because there are cases where multiple frameworks contribute to to the same C++ namespace, for example: $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi* /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi ... /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi ... /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h:namespace Akonadi ... /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi ... /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi ... The problem is that the Python implementation of these namespaces is a class, and so treating these frameworks (let's not quibble over whether KF5Akonadi* are truly KF5 frameworks, the point is more general) as separate would result in multiple colliding Python class definitions. The only solution I can see would be to bundle all of KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and AFAICS, this can only be done out of tree from the individual frameworks, say in kde-bindings.git [3]. The work to date attempts to maintain a clean separation such that all C++ builds are done from CMake, and all Python builds are done using setuptools/pip. Apart from working through bugs [1], the remaining work items I can think of are, as before: >> - Need to look into the exact usage of Qt-specifics: signals/slots and >> interoperability with SIP-based PyQt >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glue-ing-applications, >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html) >> >> - Need to figure out how any customisations which *are* required >> should be handled. plus: - I'm working with upstream on how to support discovery (e.g. via autocompletion in Python3). There is some POC-level hackery in git as above, but there is work ongoing with upstream to find a robust solution. - Flesh out how to make one set of bindings depend on another (e.g. tier 2 framework bindings might depend on tier 1 bindings, or maybe it is better to avoid PyQt and just produce cppyy-based bindings for Qt and depend on those). As always, comments/ideas/suggestions are welcome. Thanks, Shaheed [1] There is a bug with namespaced externs being worked on with upstream. [2] https://github.com/ShaheedHaque/extra-cmake-modules/blob/shaheed_master/find-modules/module_generation/PyKF5/Akonadi.py [3] I attach an example CMakeLists.txt which shows now this can be driven from CMake for the case of KF5Akonadi*...the implementation is intended to serve as the basis for a generic solution usable across KF5 at least. > On 16 October 2017 at 16:16, Shaheed Haque wrote: >> As promised, here is an interim update on the investigation into the >> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based >> bindings. >> >> The first thing is that the underlying technology of cppyy, >> cling/ROOT, has been under development at CERN for quite a while. It >> directly reads regular C++ files (there is no intermediate format like >> SIP). >> >> The bindings it generates from Python to C++ seem far more complete >> and automatic than SIP. For example: >> >> - Template instantiation is done on the fly as needed. >> >> - Since it uses C++ directly, there is none the effort required to >> decollide SIP's notion of forward and duplicate declarations. >> >> - Function overloads are cleanly handled, as are most (all?) operators. >> >> The net result is that so far, there is about 3 days work and >> approximately [1] no "cus
D8544: KTextEditor : avoiding QML crashes
rjvbb updated this revision to Diff 21793. rjvbb marked an inline comment as done. rjvbb added a comment. Updated as requested. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8544?vs=21724&id=21793 REVISION DETAIL https://phabricator.kde.org/D8544 AFFECTED FILES src/utils/kateglobal.cpp To: rjvbb, #frameworks Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, sars
D8544: KTextEditor : avoiding QML crashes
rjvbb set the repository for this revision to R39 KTextEditor. REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, sars
D8544: KTextEditor : avoiding QML crashes
rjvbb marked 2 inline comments as done. rjvbb added inline comments. INLINE COMMENTS > kfunk wrote in kateglobal.cpp:106 > Minor: "... set to 1" would be sufficient. You're setting it yourself right > before, so you can presume it is set (=> no need for `qgetenv(...)`. I know that of course, but figured that if I was adding a debug output I could just as well have it verify that we got what we asked for. REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, sars
D7828: fix createKMessageBox focus widget inconsistency
subdiff accepted this revision. subdiff added a comment. Looked at the code and I think @rkflx explained the situation quite well (if we should force passing a parent or not - better - for the QDialogButtonBox). REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D7828 To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks
KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 132 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/132/ Project: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 Date of build: Thu, 02 Nov 2017 16:49:21 + Build duration: 1 min 11 sec 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
D7828: fix createKMessageBox focus widget inconsistency
emateli added a comment. Ping @subdiff @abetts does this iteration work for you guys? It's marked as ready to land but I feel that we should get an overall opinion on this. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D7828 To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks
D8332: Added baloo urls into places model
ngraham added a comment. @mlaurent would you mind changing your approval status then? :) REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8348: Add a section for removable devices
ngraham requested changes to this revision. ngraham added a comment. This revision now requires changes to proceed. Could you add camera:/ devices to this section too? That way we could also take care of https://bugs.kde.org/show_bug.cgi?id=386060 REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8348 To: renatoo, #dolphin, #frameworks, #vdg, ervin, ngraham Cc: mlaurent, anthonyfieroni, ngraham, #frameworks
D8619: Refactor and remove duplicate code in kfileplacesview
mlaurent updated this revision to Diff 21779. mlaurent added a comment. Remove virtual keyword when we have override CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8619?vs=21778&id=21779 REVISION DETAIL https://phabricator.kde.org/D8619 AFFECTED FILES src/filewidgets/kfileplacesview.cpp To: mlaurent, #frameworks, ervin
D8619: Refactor and remove duplicate code in kfileplacesview
mlaurent updated this revision to Diff 21778. mlaurent added a comment. Const'ify + use more static_cast CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8619?vs=21776&id=21778 REVISION DETAIL https://phabricator.kde.org/D8619 AFFECTED FILES src/filewidgets/kfileplacesview.cpp To: mlaurent, #frameworks, ervin
D8173: Use readelf to find project dependencies
apol updated this revision to Diff 21777. apol added a comment. Make sure we get the dependencies from the prefix as well REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8173?vs=20434&id=21777 BRANCH arcpatch-D8173 REVISION DETAIL https://phabricator.kde.org/D8173 AFFECTED FILES tests/CMakeLists.txt tests/ECMToolchainAndroidTest/CMakeLists.txt tests/ECMToolchainAndroidTest/main.c tests/ECMToolchainAndroidTest/testlinkfile/CMakeFiles/testtarget.dir/link.txt tests/ECMToolchainAndroidTest/testlinkfile/outputfake.json toolchain/Android.cmake toolchain/specifydependencies.cmake To: apol, #frameworks, #build_system, aacid
D8619: Refactor and remove duplicate code in kfileplacesview
mlaurent created this revision. mlaurent added reviewers: Frameworks, ervin. REVISION SUMMARY Remove duplicate code. Use static_cast when we don't test result from dynamic_cast Remove unused variable TEST PLAN compile/test REPOSITORY R342 KIO AudioCD REVISION DETAIL https://phabricator.kde.org/D8619 AFFECTED FILES src/filewidgets/kfileplacesview.cpp To: mlaurent, #frameworks, ervin
D8332: Added baloo urls into places model
usta added inline comments. INLINE COMMENTS > kfileplacesview.cpp:1348 > +searchUrl = searchUrlForType(QStringLiteral("Video")); > +} > + won't be nice to add an else statement? (for the sake of searchUrl ) REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8332: Added baloo urls into places model
mlaurent added a comment. +1 for me REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8434: Created 'remote' section
mlaurent accepted this revision. mlaurent added a comment. Seems good for me REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8434 To: renatoo, ngraham, #frameworks, #dolphin, mwolff, mlaurent Cc: elvisangelaccio, mwolff, mlaurent, #frameworks
D8366: Factoring out lists of url data within KFilePlacesModelTest
renatoo added a comment. In https://phabricator.kde.org/D8366#163427, @ngraham wrote: > Is this dependent on any of the other patches floating around? Probably not, but that will affect (possible conflicts) with all patches REVISION DETAIL https://phabricator.kde.org/D8366 To: mlaurent, renatoo, ervin, franckarrecot Cc: ervin, ngraham, mlaurent, #frameworks
D8366: Factoring out lists of url data within KFilePlacesModelTest
ngraham added a comment. Is this dependent on any of the other patches floating around? REVISION DETAIL https://phabricator.kde.org/D8366 To: mlaurent, renatoo, ervin, franckarrecot Cc: ervin, ngraham, mlaurent, #frameworks
D8544: KTextEditor : avoiding QML crashes
dhaumann added a comment. By limited amount of time I mean we can remove it once the required Qt version of KDE Frameworks is 5.9. (I thought this was obvious :)) REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, sars
D8544: KTextEditor : avoiding QML crashes
kfunk added inline comments. INLINE COMMENTS > kateglobal.cpp:104 > +// disable the QML JIT compiler as a protection against an unknown bug > +// in Qt's V4 engine which can provoke a crash in certain of our scripts. > +qputenv("QV4_FORCE_INTERPRETER", QByteArrayLiteral("1")); Please add a reference to the bug reports (Qt JIRA, KDE Bugzilla) here. > kateglobal.cpp:106 > +qputenv("QV4_FORCE_INTERPRETER", QByteArrayLiteral("1")); > +qCDebug(LOG_KTE) << "QV4_FORCE_INTERPRETER set to" << > qgetenv("QV4_FORCE_INTERPRETER"); > +#endif Minor: "... set to 1" would be sufficient. You're setting it yourself right before, so you can presume it is set (=> no need for `qgetenv(...)`. REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, sars
D8544: KTextEditor : avoiding QML crashes
rjvbb added a comment. Good, I'll push this sometime tonight (I'm waiting for some feedback via the Qt bug report ticket, but won't mind if someone beats me to it0. > I agree with this patch. It will not hurt and is clearly only relevant for a limited amount of time. So +1 from me. By limited you mean "until we start requiring Qt 5.9"? That won't be too soon, I hope (it's already a pity support for 5.6LTS had to be dropped)! REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, kfunk, sars
D8544: KTextEditor : avoiding QML crashes
dhaumann added a comment. I agree with this patch. It will not hurt and is clearly only relevant for a limited amount of time. So +1 from me. And thanks a lot René and Christoph for this work. It will make the next Frameworks release better, which is alraedy tagged in 2 days. REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, kfunk, sars
D8566: Add API to retrieve the screen id for a screen name
ervin accepted this revision. This revision is now accepted and ready to land. REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D8566 To: amantia, #plasma, ervin, dvratil, mlaurent, hein, davidedmundson Cc: broulik, plasma-devel, dhaumann, apol, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart
D8366: Factoring out lists of url data within KFilePlacesModelTest
renatoo accepted this revision. REVISION DETAIL https://phabricator.kde.org/D8366 To: mlaurent, renatoo, ervin, franckarrecot Cc: ervin, ngraham, mlaurent, #frameworks
D8348: Add a section for removable devices
renatoo updated this revision to Diff 21759. renatoo added a comment. Updated parent branch REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8348?vs=21648&id=21759 REVISION DETAIL https://phabricator.kde.org/D8348 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h To: renatoo, #dolphin, #frameworks, #vdg, ervin Cc: mlaurent, anthonyfieroni, ngraham, #frameworks
D8434: Created 'remote' section
renatoo updated this revision to Diff 21760. renatoo added a comment. Updated parent branch REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8434?vs=21757&id=21760 REVISION DETAIL https://phabricator.kde.org/D8434 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h To: renatoo, ngraham, #frameworks, #dolphin, mwolff Cc: elvisangelaccio, mwolff, mlaurent, #frameworks
D8332: Added baloo urls into places model
renatoo updated this revision to Diff 21758. renatoo added a comment. Fixed code style REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8332?vs=21647&id=21758 REVISION DETAIL https://phabricator.kde.org/D8332 AFFECTED FILES autotests/CMakeLists.txt autotests/kfileplacesmodeltest.cpp autotests/kfileplacesviewtest.cpp src/filewidgets/kfileplacesmodel.cpp src/filewidgets/kfileplacesview.cpp To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8332: Added baloo urls into places model
renatoo marked 5 inline comments as done. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8434: Created 'remote' section
renatoo updated this revision to Diff 21757. renatoo added a comment. Fixed code style REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8434?vs=21697&id=21757 REVISION DETAIL https://phabricator.kde.org/D8434 AFFECTED FILES autotests/kfileplacesmodeltest.cpp autotests/kfileplacesviewtest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h To: renatoo, ngraham, #frameworks, #dolphin, mwolff Cc: elvisangelaccio, mwolff, mlaurent, #frameworks
D8367: Hidding place groups implementation in KFilePlacesModel
mlaurent updated this revision to Diff 21755. mlaurent added a comment. Remove commented code. Rename methods CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8367?vs=21752&id=21755 REVISION DETAIL https://phabricator.kde.org/D8367 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h src/filewidgets/kfileplacesmodel.cpp src/filewidgets/kfileplacesmodel.h To: mlaurent, renatoo, ngraham, franckarrecot, ervin Cc: ngraham, mlaurent, #frameworks
D8367: Hidding place groups implementation in KFilePlacesModel
mlaurent marked 2 inline comments as done. REVISION DETAIL https://phabricator.kde.org/D8367 To: mlaurent, renatoo, ngraham, franckarrecot, ervin Cc: ngraham, mlaurent, #frameworks
D8450: User can now hide an entire places group from KFilePlacesView
ervin accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://phabricator.kde.org/D8450 To: mlaurent, ngraham, renatoo, franckarrecot, ervin Cc: #frameworks
D8367: Hidding place groups implementation in KFilePlacesModel
ervin requested changes to this revision. ervin added a comment. This revision now requires changes to proceed. Couple more changes needed. INLINE COMMENTS > kfileplacesmodel.cpp:79-83 > +//static const QHash > s_groupTypeToStateName > +//{ > +//return *s_groupTypeToStateName; > +//} > + This can go away now > kfileplacesmodel.h:71-72 > bool isHidden(const QModelIndex &index) const; > +bool isPlaceGroupHidden(const GroupType type) const; > +bool isPlaceGroupHidden(const QModelIndex &index) const; > bool isDevice(const QModelIndex &index) const; Just realized now that it'd better be named "isGroupHidden". Otherwise it'll get confusing (especially since one of the types is "PlacesType"!) > kfileplacesmodel.h:89 > void setPlaceHidden(const QModelIndex &index, bool hidden); > +void setPlaceGroupHidden(const GroupType type, bool hidden); > Likewise: setGroupHidden. REVISION DETAIL https://phabricator.kde.org/D8367 To: mlaurent, renatoo, ngraham, franckarrecot, ervin Cc: ngraham, mlaurent, #frameworks
D8366: Factoring out lists of url data within KFilePlacesModelTest
ervin accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://phabricator.kde.org/D8366 To: mlaurent, renatoo, ervin, franckarrecot Cc: ervin, ngraham, mlaurent, #frameworks
D8367: Hidding place groups implementation in KFilePlacesModel
mlaurent updated this revision to Diff 21752. mlaurent added a comment. Rebase against master + other top patchs :) CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8367?vs=21645&id=21752 REVISION DETAIL https://phabricator.kde.org/D8367 AFFECTED FILES autotests/kfileplacesmodeltest.cpp src/filewidgets/kfileplacesitem.cpp src/filewidgets/kfileplacesitem_p.h src/filewidgets/kfileplacesmodel.cpp src/filewidgets/kfileplacesmodel.h To: mlaurent, renatoo, ngraham, franckarrecot, ervin Cc: ngraham, mlaurent, #frameworks
Re: Test failures with krunner 5.39.0
If the external process gets started then it is indeed weird. Dbus-monitor (or bustle) will be the best tools here, they'll show the traffic between the test and test helper. On 1 Nov 2017 23:18, "Hartmut Goebel" wrote: > Hallo, > > I'm packaging krunner 5.39.0 for GNU Guix [1]. GNU Guix builds all > software in an isolated environment (a container), which includes only > the packages and tools specified explicitly. > > When running the tests, dbusrunnertest faills, with this notable warning > and the error show below: > >DBusRunnerTest::testMatch() org.kde.krunner: Invalid entry: "DBus > runner test" > > Any idea what may be missing, what needs to be set up (env-var, > directory, package, paths)? Any idea hos to debug this further? > > All required packages and all optional/feature packages (except of QCH) > are installed. I tried running the tests with both dbus-launch and > without. The external program "testremoterunner" gets started. strace -e > trace=file" shows nothing relevant (as far as I can tell). > > * Start testing of DBusRunnerTest * > Config: Using QtTest library 5.9.2, Qt 5.9.2 (x86_64-little_endian-lp64 > shared (dynamic) release build; by GCC 5.4.0) > PASS : DBusRunnerTest::initTestCase() > QWARN : DBusRunnerTest::testMatch() inotify_add_watch("/etc/mtab") > failed: "No such file or directory" > QWARN : DBusRunnerTest::testMatch() inotify_add_watch("/etc/fstab") > failed: "No such file or directory" > QWARN : DBusRunnerTest::testMatch() org.kde.krunner: Invalid entry: > "DBus runner test" > FAIL! : DBusRunnerTest::testMatch() 'spy.wait()' returned FALSE. () >Loc: > [/tmp/guix-build-krunner-5.39.0.drv-0/krunner-5.39.0/autotes > ts/dbusrunnertest.cpp(82)] > PASS : DBusRunnerTest::cleanupTestCase() > Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 4931ms > * Finished testing of DBusRunnerTest * > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > > >
D8544: KTextEditor : avoiding QML crashes
cullmann added a comment. I could live with that change. It at least will avoid random crashs for the time being until we perhaps have a better solution. Other opinions? REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D8544 To: rjvbb, #frameworks Cc: cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, kfunk, sars, dhaumann
D8366: Factoring out lists of url data within KFilePlacesModelTest
mlaurent updated this revision to Diff 21750. mlaurent added a comment. Rebase it CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8366?vs=21646&id=21750 REVISION DETAIL https://phabricator.kde.org/D8366 AFFECTED FILES autotests/kfileplacesmodeltest.cpp To: mlaurent, renatoo, ervin, franckarrecot Cc: ervin, ngraham, mlaurent, #frameworks
D8332: Added baloo urls into places model
mlaurent requested changes to this revision. This revision now requires changes to proceed. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin, mlaurent Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks
D8332: Added baloo urls into places model
mlaurent added inline comments. INLINE COMMENTS > kfileplacesviewtest.cpp:2 > +/* This file is part of the KDE project > +Copyright (C) 2007 Kevin Ottens > + ? I don't think that you are kevin ottens :) and we are in 2017 :) > kfileplacesviewtest.cpp:20 > + > +#include > +#include QtCore/ is not necessary > kfileplacesviewtest.cpp:30 > + > +#include > +#include QtTest/ not necessart too > kfileplacesviewtest.cpp:70 > +} > +void KFilePlacesViewTest::testConvertUrl_data() > +{ new line before it > kfileplacesviewtest.cpp:111 > + > +QSignalSpy urlChangedSpy(&pv, SIGNAL(urlChanged(QUrl))); > +const QModelIndex targetIndex = pv.model()->index(row, 0); use new connect api for QSignalSpy REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D8332 To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, ervin Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks