Re: Review Request 115602: Rename kactivitymanagerd
On Feb. 21, 2014, 6:29 a.m., Kevin Ottens wrote: I understand Ivan point of view. Now I'm wondering about something: Are we sure the situation will be the same in the future for a 5 to 6 transition? I don't think we can be 100% sure and so we might want to start versioning to be ready for that and be consistent with other similar services. I wouldn't have a huge problem either way, just want to make sure we thought that through. KAMD keeps back-compatibility. Even in 5 - 6 transition, I will want that kept. I still don't see a point in having two different binaries that can not be run at the same time (unlike kded, for example) and where interchanging which one was started can lead to fun things. It would have even worse consequences if those were able to be run at the same time, and use different dbus paths. And to reiterate, if distributions want to include this patch, and deal with the resulting problems themselves, I'm fine with that.* (btw, kamd/5 is more stable than kamd/4) * I guess it will bring me headaches, while triaging bug reports, but that I can handle (I hope :) ) - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/#review50434 --- On Feb. 18, 2014, 9:50 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/ --- (Updated Feb. 18, 2014, 9:50 p.m.) Review request for KDE Frameworks and Ivan Čukić. Repository: kactivities Description --- ...so it can co-exists with kactivities4 in the same prefix Diffs - autotests/Process.cpp a7a0507 src/lib/core/manager_p.cpp 57f60be src/service/CMakeLists.txt 141e9b7 src/service/files/kactivitymanagerd.desktop ce68a49 Diff: https://git.reviewboard.kde.org/r/115602/diff/ Testing --- Both Plasma1 and Next ran fine with this patch and withouth kactivitymanagerd(4) installed. Haven't tested the case when they are both installed. Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: using KDBusConnectionPool in libraries
On Friday, 2014-02-21, 08:30:02, Kevin Ottens wrote: Hello, On Thursday 20 February 2014 20:03:20 Aaron J. Seigo wrote: I ran into an interesting situation the other day with libkactivities: it uses KDBusConnectionPool to create connections in a thread-safe manner. KDBusConnectionPool creates a connection in whatever thread it happens to be executed from. In libkactivities this creates a problem as a singleton that is internal to the library uses KDBusConnectionPool .. so whatever thread it happens to be called from first: that’s the thread it gets its QDBusConnection object put into. Well, isn't the problem that this singleton should be thread-safe or thread- local in the first place? While this particular issue was triggered by D-Bus usage, I think any singleton that is intended to be used by multiple threads and has some of its functionality depend on event processing, needs to be aware of per-thread event loops. Or, I suppose, we could invent a policy that applications should do all dbus related activities in a specific thread .. though that can be difficult to know as dbus calls are often hidden within libraries. .. or, does anyone have a pointer to what exactly in QDBusConnection is not thread safe? It wasn't (Qt4 times)... I have no idea if that's still the case today. It could be that this class isn't needed anymore. As for what exactly is not thread safe in QDBusConnection I don't remember. Since it was highlighted by Nepomuk at the time and forced upon us by its API (almost behind us too) Vishesh or Sebastian should know more (adding them in CC). I think some of the people who were working on the inital Kontact Touch also ran into this at some point, when trying to fit several agents into one process, each running in a different thread. My guess is that it is thread-safe for sending, i.e. messages won't be interleaved, but there always needs to be a thread that runs the event loop for receiving and it is probably also the one that gets all replies and incoming calls. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115602: Rename kactivitymanagerd
On Feb. 21, 2014, 6:29 a.m., Kevin Ottens wrote: I understand Ivan point of view. Now I'm wondering about something: Are we sure the situation will be the same in the future for a 5 to 6 transition? I don't think we can be 100% sure and so we might want to start versioning to be ready for that and be consistent with other similar services. I wouldn't have a huge problem either way, just want to make sure we thought that through. Ivan Čukić wrote: KAMD keeps back-compatibility. Even in 5 - 6 transition, I will want that kept. I still don't see a point in having two different binaries that can not be run at the same time (unlike kded, for example) and where interchanging which one was started can lead to fun things. It would have even worse consequences if those were able to be run at the same time, and use different dbus paths. And to reiterate, if distributions want to include this patch, and deal with the resulting problems themselves, I'm fine with that.* (btw, kamd/5 is more stable than kamd/4) * I guess it will bring me headaches, while triaging bug reports, but that I can handle (I hope :) ) OK, let's discard it then. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/#review50434 --- On Feb. 18, 2014, 9:50 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/ --- (Updated Feb. 18, 2014, 9:50 p.m.) Review request for KDE Frameworks and Ivan Čukić. Repository: kactivities Description --- ...so it can co-exists with kactivities4 in the same prefix Diffs - autotests/Process.cpp a7a0507 src/lib/core/manager_p.cpp 57f60be src/service/CMakeLists.txt 141e9b7 src/service/files/kactivitymanagerd.desktop ce68a49 Diff: https://git.reviewboard.kde.org/r/115602/diff/ Testing --- Both Plasma1 and Next ran fine with this patch and withouth kactivitymanagerd(4) installed. Haven't tested the case when they are both installed. Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115827: Add KMainWindow::initialGeometrySet to increase SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/#review50455 --- Ship it! Ship It! - Kevin Ottens On Feb. 21, 2014, 7:35 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/ --- (Updated Feb. 21, 2014, 7:35 a.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- Add KMainWindow::initialGeometrySet to increase SC Deprecated and just returns false. Diffs - src/kmainwindow.h 7072b51fa5e9bf44703636481ea26c0e47769b52 Diff: https://git.reviewboard.kde.org/r/115827/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: using KDBusConnectionPool in libraries
On Friday, February 21, 2014 08:30:02 Kevin Ottens wrote: Hello, On Thursday 20 February 2014 20:03:20 Aaron J. Seigo wrote: I ran into an interesting situation the other day with libkactivities: it uses KDBusConnectionPool to create connections in a thread-safe manner. KDBusConnectionPool creates a connection in whatever thread it happens to be executed from. In libkactivities this creates a problem as a singleton that is internal to the library uses KDBusConnectionPool .. so whatever thread it happens to be called from first: thatâs the thread it gets its QDBusConnection object put into. Well, isn't the problem that this singleton should be thread-safe or thread- local in the first place? Thread local is not really an option (as explained in my original email, there is no guarantee that the thread the object is created in continues to exist or even has an event loop in it). Thread safe and always living in the main app thread would be an option, however. Or living in its own thread, but I’d reserve that for functionality that is blocking (processing intensive, relies on synchronous calls, etc.) and which would be vital enough to an application’s value that it justifies another thread in the system. Of course, if that thread has no event loop and/or exits, then things stop working as expected. In the case of libkactivities, things just stop working, period. Either a better solution needs to be found for KDBusConnectionPool or a warning should be placed prominently in the apidox about this âgotchaâ and perhaps it should be completely avoided in other frameworks where it is impossible to know the threading model of the application that will be using it. Yes, adding a big fat warning sounds fair to me Ok, I’ll work something together. Or, I suppose, we could invent a policy that applications should do all dbus related activities in a specific thread .. though that can be difficult to know as dbus calls are often hidden within libraries. .. or, does anyone have a pointer to what exactly in QDBusConnection is not thread safe? It wasn't (Qt4 times)... I have no idea if that's still the case today. It could be that this class isn't needed anymore. According to the docs, the only non-thread-safe call is QDBusConnection::sender, which is apparently kept for compatibility only since one should use QDBusContext in such cases instead. Whether libdbus under it is thread safe (or used in a way that makes it thread safe), I don’t know. I’ll follow up with Thiago. It would be rather nice to see this class go away if possible. As for what exactly is not thread safe in QDBusConnection I don't remember. Since it was highlighted by Nepomuk at the time and forced upon us by its API (almost behind us too) Vishesh or Sebastian should know more (adding them in CC). That would be good information to have .. looking forward to their response. -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115827: Add KMainWindow::initialGeometrySet to increase SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/ --- (Updated Feb. 21, 2014, 10:23 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kxmlgui Description --- Add KMainWindow::initialGeometrySet to increase SC Deprecated and just returns false. Diffs - src/kmainwindow.h 7072b51fa5e9bf44703636481ea26c0e47769b52 Diff: https://git.reviewboard.kde.org/r/115827/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115827: Add KMainWindow::initialGeometrySet to increase SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/#review50456 --- This review has been submitted with commit db21f504bacc2ca10d2d13d6e555b0accf952695 by Martin Gräßlin to branch master. - Commit Hook On Feb. 21, 2014, 7:35 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/ --- (Updated Feb. 21, 2014, 7:35 a.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- Add KMainWindow::initialGeometrySet to increase SC Deprecated and just returns false. Diffs - src/kmainwindow.h 7072b51fa5e9bf44703636481ea26c0e47769b52 Diff: https://git.reviewboard.kde.org/r/115827/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115908: Remove Ki18n from KCompletion dependencies in cmake.in
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115908/ --- (Updated Feb. 21, 2014, 10:28 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Gil Oliva. Repository: kcompletion Description --- KI18n is unused in KCompletion code, so we shouldn't search for it as a dep... Diffs - KF5CompletionConfig.cmake.in 54403d9 Diff: https://git.reviewboard.kde.org/r/115908/diff/ Testing --- Builds ;-) Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115908: Remove Ki18n from KCompletion dependencies in cmake.in
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115908/#review50457 --- This review has been submitted with commit ac1ad127c3b440ba0c00485c1cb5ca6152117667 by Hrvoje Senjan to branch master. - Commit Hook On Feb. 20, 2014, 11:51 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115908/ --- (Updated Feb. 20, 2014, 11:51 a.m.) Review request for KDE Frameworks and David Gil Oliva. Repository: kcompletion Description --- KI18n is unused in KCompletion code, so we shouldn't search for it as a dep... Diffs - KF5CompletionConfig.cmake.in 54403d9 Diff: https://git.reviewboard.kde.org/r/115908/diff/ Testing --- Builds ;-) Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115907: Link tests with extra libraries as well
On Feb. 20, 2014, 10:46 a.m., Alex Merry wrote: Can you describe the problem this fixes? Are the tests directly using these libraries somehow? Adrián Chaves Fernández wrote: If I build with these steps: mkdir -p build cd build cmake ../kxmlgui-4.96.0 \ -DCMAKE_INSTALL_PREFIX=/usr/bin \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DLIB_INSTALL_DIR=lib \ -DSYSCONF_INSTALL_DIR=/etc make In Chakra, I cannot get it to build. Without these changes, I get something like this when building the tests: Linking CXX executable kbugreporttest cd /home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/tests /usr/bin/cmake -E cmake_link_script CMakeFiles/kbugreporttest.dir/link.txt --verbose=1 /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -g -fvar-tracking-assignments -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -O2 -g -DNDEBUG -Wl,--enable-new-dtags -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/kbugreporttest.dir/kbugreporttest.cpp.o CMakeFiles/kbugreporttest.dir/kbugreporttest_automoc.cpp.o -o kbugreporttest -rdynamic /usr/lib/libQt5Test.so.5.2.1 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 ../src/libKF5XmlGui.so.4.96.0 /usr/lib/libKF5ConfigWidgets.so.4.96.0 /usr/lib/libKF5Codecs.so.4.96.0 /usr/lib/libKF5Auth.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 /usr/lib/libKF5CoreAddons.so.4.96.0 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5ConfigGui.so.4.96.0 /usr/lib/libQt5Xml.so.5.2.1 /usr/lib/libKF5C onfigCore.so.4.96.0 /usr/lib/libQt5Widgets.so.5.2.1 /usr/lib/libQt5Gui.so.5.2.1 /usr/lib/libQt5DBus.so.5.2.1 /usr/lib/libQt5Core.so.5.2.1 -Wl,-rpath,/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/src /usr/bin/ld: warning: libKF5Attica.so.4, needed by ../src/libKF5XmlGui.so.4.96.0, not found (try using -rpath or -rpath-link) ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::~Person()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::~Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::city() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::extendedAttribute(QString const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ItemJobAttica::Person::result() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::~Metadata()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::country() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::ProviderManager(QFlagsAttica::ProviderManager::ProviderFlag const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providers() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::name() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::avatarUrl() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::loadDefaultProviders()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::error() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::~ProviderManager()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::staticMetaObject' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::start()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providerByUrl(QUrl const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::isValid() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::requestPerson(QString const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::homepage() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::operator=(Attica::Provider const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::metadata() const' collect2: error: ld returned 1 exit status make[2]: *** [tests/kbugreporttest] Error 1 make[2]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make[1]: *** [tests/CMakeFiles/kbugreporttest.dir/all] Error 2 make[1]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make: *** [all] Error 2
Re: Review Request 115742: KParts: Allow compilation on windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115742/#review50460 --- Ship it! Ship It! - Alex Merry On Feb. 20, 2014, 4:27 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115742/ --- (Updated Feb. 20, 2014, 4:27 p.m.) Review request for KDE Frameworks. Repository: kparts Description --- Allow compilation on windows Diffs - src/browserextension.h 3ccafcbf0f6628cf7b07ce0436036bb972f95107 src/readwritepart.cpp 693cb76e05d975066ff93e69da27cc25d9dfe35d Diff: https://git.reviewboard.kde.org/r/115742/diff/ Testing --- compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115775: Defer to CMake's find_dependency macro if it exists
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115775/#review50461 --- This review has been submitted with commit dfbbd75577d60299706e95ced5c4a245438f6a03 by Alex Merry to branch master. - Commit Hook On Feb. 18, 2014, 3:49 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115775/ --- (Updated Feb. 18, 2014, 3:49 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Defer to CMake's find_dependency macro if it exists This will be available in CMake 3.0.0. This way, we automatically pick up any new features from it. Diffs - modules/ECMPackageConfigHelpers.cmake 78017393afa6e35dd90df0bd15e08ceed9dff841 Diff: https://git.reviewboard.kde.org/r/115775/diff/ Testing --- Built some frameworks with CMake 2.8.12 (still works) and CMake git (properly defers to CMake's version, as shown by the fact that packages only searched for with find_dependency() are not shown in the feature summary). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115816: Remove strigi libs from kf5-frameworks-build-include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115816/#review50462 --- This review has been submitted with commit bf6cd416d3a15fd62ebf5ade6753a1bc9dec3e9d by Alex Merry to branch master. - Commit Hook On Feb. 19, 2014, 11:54 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115816/ --- (Updated Feb. 19, 2014, 11:54 a.m.) Review request for Build System, KDE Frameworks, David Faure, and Kevin Ottens. Repository: kdesrc-build Description --- Remove strigi libs from kf5-frameworks-build-include Nothing in frameworks actually uses anything strigi-related. Diffs - kf5-frameworks-build-include 937d182ad96eb3780756876087cb44233cc8f21e Diff: https://git.reviewboard.kde.org/r/115816/diff/ Testing --- kdesrc-build has got to KIO so far with no problems (clean build and install dirs, although I do actually have strigi 0.7.8 installed in /usr). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115816: Remove strigi libs from kf5-frameworks-build-include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115816/ --- (Updated Feb. 21, 2014, 11:19 a.m.) Status -- This change has been marked as submitted. Review request for Build System, KDE Frameworks, David Faure, and Kevin Ottens. Repository: kdesrc-build Description --- Remove strigi libs from kf5-frameworks-build-include Nothing in frameworks actually uses anything strigi-related. Diffs - kf5-frameworks-build-include 937d182ad96eb3780756876087cb44233cc8f21e Diff: https://git.reviewboard.kde.org/r/115816/diff/ Testing --- kdesrc-build has got to KIO so far with no problems (clean build and install dirs, although I do actually have strigi 0.7.8 installed in /usr). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115896: Import FindDocBook*.cmake from extra-cmake-modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/#review50464 --- This review has been submitted with commit ee71d477120c9d029c439fbed6e5df9d3b939f5a by Alex Merry on behalf of Aleix Pol to branch master. - Commit Hook On Feb. 19, 2014, 12:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/ --- (Updated Feb. 19, 2014, 12:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Commits imported with `git format-patch` (edited), followed by `git am`. Add the local cmake directory to the CMake module path Use the newer syntax in FindDocBook* It approprietly sets the _FOUND variables, we were defining the all uppercase instead. Sorry for the mess! Originally commit 190c79bb4e6bc8b8757bd890485a9bafb4a65219 of the extra-cmake-modules repository Move FindDocBook* to find-modules Originally commit d42d5889d25ac4c900a294f283dd802eccf96010 of the extra-cmake-modules repository Diffs - CMakeLists.txt d135e0caa55d126ba3c335b9f05f8125453c1e53 cmake/FindDocBookXML.cmake PRE-CREATION cmake/FindDocBookXSL.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115896/diff/ Testing --- Removed FindDocBook*.cmake from $PREFIX/share/ECM/find-modules, and a clean configure, build, install still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115896: Import FindDocBook*.cmake from extra-cmake-modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/#review50465 --- This review has been submitted with commit 8fc1e5ec74d3cdb20e19c3a9d4eb040d86620003 by Alex Merry to branch master. - Commit Hook On Feb. 19, 2014, 12:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/ --- (Updated Feb. 19, 2014, 12:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Commits imported with `git format-patch` (edited), followed by `git am`. Add the local cmake directory to the CMake module path Use the newer syntax in FindDocBook* It approprietly sets the _FOUND variables, we were defining the all uppercase instead. Sorry for the mess! Originally commit 190c79bb4e6bc8b8757bd890485a9bafb4a65219 of the extra-cmake-modules repository Move FindDocBook* to find-modules Originally commit d42d5889d25ac4c900a294f283dd802eccf96010 of the extra-cmake-modules repository Diffs - CMakeLists.txt d135e0caa55d126ba3c335b9f05f8125453c1e53 cmake/FindDocBookXML.cmake PRE-CREATION cmake/FindDocBookXSL.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115896/diff/ Testing --- Removed FindDocBook*.cmake from $PREFIX/share/ECM/find-modules, and a clean configure, build, install still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115896: Import FindDocBook*.cmake from extra-cmake-modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/ --- (Updated Feb. 21, 2014, 11:21 a.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Commits imported with `git format-patch` (edited), followed by `git am`. Add the local cmake directory to the CMake module path Use the newer syntax in FindDocBook* It approprietly sets the _FOUND variables, we were defining the all uppercase instead. Sorry for the mess! Originally commit 190c79bb4e6bc8b8757bd890485a9bafb4a65219 of the extra-cmake-modules repository Move FindDocBook* to find-modules Originally commit d42d5889d25ac4c900a294f283dd802eccf96010 of the extra-cmake-modules repository Diffs - CMakeLists.txt d135e0caa55d126ba3c335b9f05f8125453c1e53 cmake/FindDocBookXML.cmake PRE-CREATION cmake/FindDocBookXSL.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115896/diff/ Testing --- Removed FindDocBook*.cmake from $PREFIX/share/ECM/find-modules, and a clean configure, build, install still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115896: Import FindDocBook*.cmake from extra-cmake-modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/#review50463 --- This review has been submitted with commit de7d80c720851a8eead8f8e84f3ce73f46beb437 by Alex Merry on behalf of Aleix Pol to branch master. - Commit Hook On Feb. 19, 2014, 12:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/ --- (Updated Feb. 19, 2014, 12:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Commits imported with `git format-patch` (edited), followed by `git am`. Add the local cmake directory to the CMake module path Use the newer syntax in FindDocBook* It approprietly sets the _FOUND variables, we were defining the all uppercase instead. Sorry for the mess! Originally commit 190c79bb4e6bc8b8757bd890485a9bafb4a65219 of the extra-cmake-modules repository Move FindDocBook* to find-modules Originally commit d42d5889d25ac4c900a294f283dd802eccf96010 of the extra-cmake-modules repository Diffs - CMakeLists.txt d135e0caa55d126ba3c335b9f05f8125453c1e53 cmake/FindDocBookXML.cmake PRE-CREATION cmake/FindDocBookXSL.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115896/diff/ Testing --- Removed FindDocBook*.cmake from $PREFIX/share/ECM/find-modules, and a clean configure, build, install still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Figuring out kde-runtime: localization
Hi, Going through the information we have in kde-runtime [1] we found there are two subdirectories related to localization (localization and l10n) that we couldn't find a correct place to move to. Can anybody give us a hand and help us figure those out? - localization: has plenty of information regarding different currencies. - l10n: has information about different countries. Should these go to KI18n? Qt? Anybody has plans for those? Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Feb. 21, 2014, 12:26 p.m.) Review request for KDE Frameworks. Changes --- Move the QApplication initialization to setApplicationData() instead of in setupCommandLine(). It makes more sense, the previous API looked a bit hacky. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs (updated) - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115932: Add declarative plugin for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.h PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 CMakeLists.txt cbae838 Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review50466 --- src/lib/kaboutdata.h https://git.reviewboard.kde.org/r/115207/#comment35500 chosen I would actually rephrase this as In addition to changing the result of applicationData(), this initializes the relevant properties of QCoreApplication (and its subclasses) with information from @p aboutData. src/lib/kaboutdata.cpp https://git.reviewboard.kde.org/r/115207/#comment35499 No point changing this - Alex Merry On Feb. 21, 2014, 12:26 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Feb. 21, 2014, 12:26 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
desktoptojson and kservice
Hi ...
So, the next fun thing I’ve run into is desktoptojson. Currently in Sprinter
I’m just hand writing the json files for the plugins. However, in its TODO file
is this:
* Metadata
* localization/i18n in plugin metadata (name, description)
* license
* author information (name, email)
* icon
This is all information we currently have in .desktop files (along with the
infrastructure and people using it to translate them ..) so it makes sense to
stick to that and simply translate to json from them at build time.
Which brought me to desktoptojson .. and several questions:
While there are shortcomings in QSettings for parsing random INI files, I don’t
think any of these apply to the .desktop files we use. Would there be any
objection / reason against dropping the use of KConfig in desktop and moving to
QSettings, turning it into a Qt only application?
Assuming a move to QSettings, could it then be moved out of the kservice
repository, which is tier3, and into something more tier1? In a perfect world
this would come with ecm, even, or something similarly build-tools related.
Any suggestions there?
What are the plans for i18n in desktoptojson? It currently does not catch any
translations in the .desktop file.
Do we really want json files that look like this:
{
Comment: List and switch between desktop activities,
Icon: preferences-activities,
Name: Activities,
Type: Service,
X-KDE-Library: krunner_activities,
X-KDE-PluginInfo-Author: Plasma Team,
X-KDE-PluginInfo-Email: plasma-de...@kde.org,
X-KDE-PluginInfo-EnabledByDefault: true,
X-KDE-PluginInfo-License: LGPL,
X-KDE-PluginInfo-Name: org.kde.activities,
X-KDE-PluginInfo-Version: 1.0,
X-KDE-ServiceTypes: [
Plasma/Runner
],
X-Plasma-AdvertiseSingleRunnerQueryMode: true
}
While easier for KPluginInfo perhaps (as it can just use the same keys when
reading from .desktop files), this is imho really quite messy and makes it
precarious to use for applications that may want to use KPluginInfo (or other
tools) with json files with other data in them. Yes, we could continue to use
“X-Foo-” prefixes .. but this is very ugly json. Litmus test: would anyone
construct the above when told to come up with a json format to hold the above
information if they didn’t start with those .desktop files?
What would be nicer imho is sth like:
{
org.kde.PluginInfo: {
Description : {
c {
Name: Activities,
Comment: List and switch between desktop activities,
},
de: {
Name: Aktivitäten,
Comment: Aktivitäten anzeigen und zwischen ihnen
umschalten
}
},
Details: {
Author: Plasma Team,
Email: plasma-de...@kde.org,
EnabledByDefault: true,
License: LGPL,
Name: org.kde.activities,
Version: 1.0,
Icon: preferences-activities,
},
ServiceTypes: [ Plasma/Runner ]
},
Sprinter: {
AdvertiseSingleRunnerQueryMode: true
}
}
Note that this removes a few entries such as X-KDE-Library, which isn’t used i
KPluginInfo at all now, and Type: “Service”, which is now redundant. It also
introduces translations (though that means a bit more overhead as they will be
parsed at runtime and stored in memory as part of the QPluginLoader process),
and keeps those separate from non-translated items (Description vs Details ..
best names I could come up with on the spot, not necessarily the best ones
possible). It wraps it all up in a “org.kde.PluginInfo” block so that it
doesn’t interfere with other tools.
it would be easy to augment desktoptojson to take data from other files (INI or
json) passed in on the command line to merge them into the final product.
thoughts?
--
Aaron J. Seigo
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review50468 --- the approach looks good to me, just two small requests: * make it complete (everything Q_INVOKABLE what makes sense (not self or things which cannot be exported)) * provide an example app in tests/ - I assume you already have some QML? - Martin Gräßlin On Feb. 21, 2014, 1:27 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 21, 2014, 1:27 p.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.h PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 CMakeLists.txt cbae838 Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson and kservice
Aaron J. SeigoOn Friday, February 21, 2014 13:41:29 wrote: What are the plans for i18n in desktoptojson? It currently does not catch any translations in the .desktop file. actually, i think it might be worse than “does not catch any translations”: if it does what i suspect it does, it takes the translated versions of the strings of whatever locale the user currently has set. so if someone using german as their language, whenever they run desktoptojson they’ll get german strings rather than the default english ones. has anyone tested this with non-’c’ locales? -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115840: Rename Platform to Frameworks in both about dialogs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115840/ --- (Updated Feb. 21, 2014, 12:56 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kxmlgui Description --- Rename Platform to Frameworks in both about dialogs Diffs - src/kaboutapplicationdialog.cpp e7bd2fe4c50a4e13321e501608409a2f339636c2 src/kaboutkdedialog_p.cpp b97ad1071f107bde2e829c9de7b343a17fd4cfe9 Diff: https://git.reviewboard.kde.org/r/115840/diff/ Testing --- Started kwrite, new names appear correctly. File Attachments After and before https://git.reviewboard.kde.org/media/uploaded/files/2014/02/17/6ace6797-b82a-4c61-9bae-004ea7bdb654__aboutdialog.png Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115840: Rename Platform to Frameworks in both about dialogs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115840/#review50469 --- This review has been submitted with commit 3fa7abd2309bd3c8a0af45d7745aa09ada3981de by Sebastian Kügler to branch master. - Commit Hook On Feb. 17, 2014, 7:04 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115840/ --- (Updated Feb. 17, 2014, 7:04 p.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- Rename Platform to Frameworks in both about dialogs Diffs - src/kaboutapplicationdialog.cpp e7bd2fe4c50a4e13321e501608409a2f339636c2 src/kaboutkdedialog_p.cpp b97ad1071f107bde2e829c9de7b343a17fd4cfe9 Diff: https://git.reviewboard.kde.org/r/115840/diff/ Testing --- Started kwrite, new names appear correctly. File Attachments After and before https://git.reviewboard.kde.org/media/uploaded/files/2014/02/17/6ace6797-b82a-4c61-9bae-004ea7bdb654__aboutdialog.png Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Feb. 21, 2014, 2:03 p.m.) Review request for KDE Frameworks. Changes --- Address issues pointed out by Alex Merry. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs (updated) - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson and kservice
On Friday, February 21, 2014 13:57:07 Kevin Krammer wrote: If we want to be able to parse .desktop files without KConfig, we need a desktop file parser. valuable to know, indeed. thanks for sharing your experience, saves me some effort. The Razor-Qt and LxQt people might have one already. yeah, i was wondering the same thing ... will take a look around. a long while ago i had found such a class on the Internet. perhaps qt3 days? hm.. google, here i come. -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115909: Remove unused dependency from krunner
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115909/#review50475 --- Ship it! Ship It! - Sebastian Kügler On Feb. 20, 2014, 12:22 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115909/ --- (Updated Feb. 20, 2014, 12:22 p.m.) Review request for KDE Frameworks. Repository: krunner Description --- There does not appear to be any actual KCompletion usage, so remove it. Diffs - src/runnercontext.cpp 8b7461459ead6ff8c18549531f1b5c9baf1df3fa CMakeLists.txt ebae16d0610c5c53aac34e9134db5d4b0e47903b src/CMakeLists.txt 0f8221fc175f51da32a5abcc96bdeca2c9b0e17b src/abstractrunner.h cee292812075db59c13703de37dc1e983c3d8968 src/runnercontext.h c6441b7a1bb92df5549d26f45183c1ff7ce157e6 Diff: https://git.reviewboard.kde.org/r/115909/diff/ Testing --- Builds. Tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115875: kconfigtest: write everything into a subdirectory
On Feb. 21, 2014, 7:35 a.m., Kevin Ottens wrote: autotests/kconfigtest.cpp, line 219 https://git.reviewboard.kde.org/r/115875/diff/1/?file=244867#file244867line219 Hm we're loosing the test mode for QStandardPaths, I don't think that's desirable. It is done inside testConfigDir() - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/#review50435 --- On Feb. 18, 2014, 10:52 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/ --- (Updated Feb. 18, 2014, 10:52 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- kconfigtest: write everything into a subdirectory This test keeps deleting the whole ~/.qttest directory. By moving all data into a subdirectory it is now possible to run multiple tests that use kconfig in parallel. Diffs - autotests/kconfigtest.cpp 1c0dc1cf63539e29236ab57e1e848930b468053a Diff: https://git.reviewboard.kde.org/r/115875/diff/ Testing --- Test still passes. No files (except kdeglobals) are created in ~/.qttest Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115936: Split ki18n ktranscript tests into one using the plugin and one instantiating/destroying the class directly
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115936/ --- (Updated Feb. 21, 2014, 4:58 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Fixed a typo the CMakeLists.txt file, removed the extern C block from the test that uses direct instantiation Repository: ki18n Description --- Separate ktranscript plugin test into its own autotest The plugin based test of KTranscript performs all tests with a single instance of KTranscriptImp because the plugin uses Q_GLOBAL_STATIC to create and access that instance. The non-plugin test creates a new instance for every test. Currently all scripting tests are runnable in both situations, but the non-plugin test allows for tests that need a clean slate. Diffs (updated) - autotests/CMakeLists.txt eb73d21 autotests/ktranscriptplugintest.h PRE-CREATION autotests/ktranscriptplugintest.cpp PRE-CREATION autotests/ktranscripttest.h 53f3ce0 autotests/ktranscripttest.cpp 78aecb4 src/ktranscript.cpp c922e91 src/ktranscript_p.h f1cc132 Diff: https://git.reviewboard.kde.org/r/115936/diff/ Testing --- All three tests run without failure Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
