Re: Review Request 113370: move KDED to Tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113370/#review42261 --- kded/CMakeLists.txt http://git.reviewboard.kde.org/r/113370/#comment30755 should be replaced with? it already is kded/CMakeLists.txt http://git.reviewboard.kde.org/r/113370/#comment30756 Why not use the version number of *this* framework? The same risks for discrepancies exist whichever framework is used for the version checking. kioslave/http/kcookiejar/CMakeLists.txt http://git.reviewboard.kde.org/r/113370/#comment30758 ok, we'll have to change that, obviously. kded should install that xml file, and kcookiejar should use the installed xml file (or the one from tier3/kded when building kdelibs all-in-one) - David Faure On Oct. 21, 2013, 3:56 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113370/ --- (Updated Oct. 21, 2013, 3:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KDED to tier3. I have removed any use of X11/Properties used to communicate with KSplash since we want to use either DBus or Wayland but certainly not X11. I plan to work on session startup in a few weeks so I will fix (if nobody else does before me) KSplash --- KDED communication by then. Diffs - CMakeLists.txt 4ea56ae kded/CMakeLists.txt a06ed09 kded/DESIGN kded/HOWTO kded/Info.plist.template kded/Mainpage.dox kded/README.kded kded/config-kded.h.cmake 21210ab kded/kded.h kded/kded.cpp aab548b kded/kdedadaptor.h kded/kdedadaptor.cpp kded/kdedmodule.desktop kded/org.kde.kded5.service.in kioslave/http/kcookiejar/CMakeLists.txt 8d61c01 tier3/CMakeLists.txt eed8acb Diff: http://git.reviewboard.kde.org/r/113370/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kio kfilewidget.h problem
On Wednesday 23 October 2013 11:10:17 Treeve Jelbert wrote: kio installs kfilewidget.h which references kio/kiofilewidgets_export.h which is not installed Fixed, thanks for the report. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Keep the Things You Forgot
Am Mittwoch, 23. Oktober 2013, 21.49:27 schrieb Mark: Morning [snip] A blog post that i'd very much like from you (Aaron) is about the next big KDE version, the naming and how the complete collection is going to be called or if there even will be a collection release (what KDE SC is now). Press is still getting that wrong, i tend to get it wrong and other people talking about KDE seem to get it wrong. Usually it's just being referred to as KDE 5 which is wrong. (Frameworks 5, Plasma 2, ...). So if you have the time, a blog about that would be wonderful and very educational ^_^ What about all the recent dot articles about KF5, Plasma 2 and Co? I think you won't get it clearer than that. Best Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Config files naming policy
On Wednesday 23 October 2013 19:37:21 Ivan Čukić wrote: I guess I'll rename my config file then. I've been using activitymanagerrc, while the binary was actually prefixed with a 'k' and suffixed with a 'd'. Hmm, if you use KGlobal::config() (in kde4) or KSharedConfig::openConfig() (in KF5), the name of the config file would be automatically generated from the application name. (assuming this is about an application like the daemon, not a library) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113402: Fix KI18n standalone build
On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/ --- (Updated Oct. 23, 2013, 4:30 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KI18n depends on KJS to build the ktranscript plugin. This plugin requires an internal KJS Perl script as well as headers which were not installed. This is a 3-commit patches, which does the following: 1. Install kjs headers 2. Install wtf headers, using wtf/ and kjs/ in include directives (because some kjs headers includes wtf headers) 3. Fix KI18n: - Format top-level CMakeLists.txt according to CMake template - Duplicate KJS create_hash_table script - Add call to find_package(KJS) Individual patches available from http://agateau.com/tmp/ki18n-standalone.patch Diffs - superbuild/CMakeLists.txt 5cdec94 tier1/kjs/src/CMakeLists.txt 8629716 tier1/kjs/src/kjs/CMakeLists.txt 9523e89 tier1/kjs/src/wtf/CMakeLists.txt 83b4417 tier1/kjs/src/wtf/FastMalloc.h 29a72a5 tier1/kjs/src/wtf/HashCountedSet.h be3c387 tier1/kjs/src/wtf/HashFunctions.h f665447 tier1/kjs/src/wtf/HashMap.h ba2971c tier1/kjs/src/wtf/HashSet.h e84b349 tier1/kjs/src/wtf/HashTable.h 0b2c22c tier1/kjs/src/wtf/HashTable.cpp e08d09a tier1/kjs/src/wtf/HashTraits.h 4d01726 tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 tier1/kjs/src/wtf/OwnPtr.h 188a1dc tier1/kjs/src/wtf/PassRefPtr.h 25b9906 tier1/kjs/src/wtf/RefPtr.h 493ab05 tier1/kjs/src/wtf/Vector.h 9b0f38a tier1/kjs/src/wtf/VectorTraits.h 31ae028 tier2/ki18n/CMakeLists.txt 4cc8e30 tier2/ki18n/src/CMakeLists.txt 7f8259b4 tier2/ki18n/src/create_hash_table PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113402/diff/ Testing --- Builds within kdelibs and standalone. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113402: Fix KI18n standalone build
On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Aurélien Gâteau wrote: Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, QtQuick uses the QJS* classes from QtQML, so this is what we should be using. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/ --- (Updated Oct. 23, 2013, 4:30 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KI18n depends on KJS to build the ktranscript plugin. This plugin requires an internal KJS Perl script as well as headers which were not installed. This is a 3-commit patches, which does the following: 1. Install kjs headers 2. Install wtf headers, using wtf/ and kjs/ in include directives (because some kjs headers includes wtf headers) 3. Fix KI18n: - Format top-level CMakeLists.txt according to CMake template - Duplicate KJS create_hash_table script - Add call to find_package(KJS) Individual patches available from http://agateau.com/tmp/ki18n-standalone.patch Diffs - superbuild/CMakeLists.txt 5cdec94 tier1/kjs/src/CMakeLists.txt 8629716 tier1/kjs/src/kjs/CMakeLists.txt 9523e89 tier1/kjs/src/wtf/CMakeLists.txt 83b4417 tier1/kjs/src/wtf/FastMalloc.h 29a72a5 tier1/kjs/src/wtf/HashCountedSet.h be3c387 tier1/kjs/src/wtf/HashFunctions.h f665447 tier1/kjs/src/wtf/HashMap.h ba2971c tier1/kjs/src/wtf/HashSet.h e84b349 tier1/kjs/src/wtf/HashTable.h 0b2c22c tier1/kjs/src/wtf/HashTable.cpp e08d09a tier1/kjs/src/wtf/HashTraits.h 4d01726 tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 tier1/kjs/src/wtf/OwnPtr.h 188a1dc tier1/kjs/src/wtf/PassRefPtr.h 25b9906 tier1/kjs/src/wtf/RefPtr.h 493ab05 tier1/kjs/src/wtf/Vector.h 9b0f38a tier1/kjs/src/wtf/VectorTraits.h 31ae028 tier2/ki18n/CMakeLists.txt 4cc8e30 tier2/ki18n/src/CMakeLists.txt 7f8259b4 tier2/ki18n/src/create_hash_table PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113402/diff/ Testing --- Builds within kdelibs and standalone. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112755: Reimplement KXUtils::createPixmapFromHandle with XCB
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112755/ --- (Updated Oct. 24, 2013, 12:22 p.m.) Review request for KDE Frameworks. Changes --- * added a small test app which is able to render the icon of a passed in window id into a QLabel * added a byte order check, if not LSB no image conversion is done * added better depth and visual conversion. Only a small subset is checked with inspiration from kde-workspace/ksmserver/logouteffect.cpp For testing I used iceweasel and xclock. Both work fine. Repository: kdelibs Description --- Implements the createPixmapFromHandle by getting the image for the pixmaps and using it as either the Pixmap or the bitmap mask. Diffs (updated) - tier1/kwindowsystem/src/kxutils.cpp 33bd678 tier1/kwindowsystem/src/kxutils_p.h 84d639b tier1/kwindowsystem/tests/CMakeLists.txt 5cf5868 tier1/kwindowsystem/tests/createpixmapfromhandletest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112755/diff/ Testing --- Adjusted KWin to take this codepath and say thanks to Iceweasel for having a mask 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 113402: Fix KI18n standalone build
On Oct. 23, 2013, 2:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Aurélien Gâteau wrote: Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. Aurélien Gâteau wrote: Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, QtQuick uses the QJS* classes from QtQML, so this is what we should be using. I would definitely welcome such a port... I remember asking ktranscript to be ported away from KJS. Would also make ki18n tier 1. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 2:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/ --- (Updated Oct. 23, 2013, 2:30 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KI18n depends on KJS to build the ktranscript plugin. This plugin requires an internal KJS Perl script as well as headers which were not installed. This is a 3-commit patches, which does the following: 1. Install kjs headers 2. Install wtf headers, using wtf/ and kjs/ in include directives (because some kjs headers includes wtf headers) 3. Fix KI18n: - Format top-level CMakeLists.txt according to CMake template - Duplicate KJS create_hash_table script - Add call to find_package(KJS) Individual patches available from http://agateau.com/tmp/ki18n-standalone.patch Diffs - superbuild/CMakeLists.txt 5cdec94 tier1/kjs/src/CMakeLists.txt 8629716 tier1/kjs/src/kjs/CMakeLists.txt 9523e89 tier1/kjs/src/wtf/CMakeLists.txt 83b4417 tier1/kjs/src/wtf/FastMalloc.h 29a72a5 tier1/kjs/src/wtf/HashCountedSet.h be3c387 tier1/kjs/src/wtf/HashFunctions.h f665447 tier1/kjs/src/wtf/HashMap.h ba2971c tier1/kjs/src/wtf/HashSet.h e84b349 tier1/kjs/src/wtf/HashTable.h 0b2c22c tier1/kjs/src/wtf/HashTable.cpp e08d09a tier1/kjs/src/wtf/HashTraits.h 4d01726 tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 tier1/kjs/src/wtf/OwnPtr.h 188a1dc tier1/kjs/src/wtf/PassRefPtr.h 25b9906 tier1/kjs/src/wtf/RefPtr.h 493ab05 tier1/kjs/src/wtf/Vector.h 9b0f38a tier1/kjs/src/wtf/VectorTraits.h 31ae028 tier2/ki18n/CMakeLists.txt 4cc8e30 tier2/ki18n/src/CMakeLists.txt 7f8259b4 tier2/ki18n/src/create_hash_table PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113402/diff/ Testing --- Builds within kdelibs and standalone. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Some changes to buildsystem files
Hello, I've just pushed some changes to the buildsystem files. KF5 CMake config files no longer define a Foo_LIBRARIES variable. Instead the KF5::Foo should be used in target_link_libraries. I tested the build of plasma-frameworks, kactivities, konsole and kde- workspace after my changes and they built for me. If they don't build for you then replace those variables with target names or post here for help. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Keep the Things You Forgot
Am Donnerstag, 24. Oktober 2013, 14.02:16 schrieb Mark: Morning [snip] You probably mean dot.kde.org/2013/09/25/frameworks-5 And this: http://dot.kde.org/2013/09/04/kde-release-structure-evolves That would work but not if that's it. This kind of change is one that has to sink in over time so this has to be repeated from time to time. Of course. That's why there are some more stories in the tube. See promo list and co for hints. Best Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113406: Add a macro to automatically generate forward headers
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113406/ --- (Updated Oct. 24, 2013, 1:40 p.m.) Review request for Build System, KDE Frameworks and Stephen Kelly. Changes --- Adopt changes proposed by Neundorf. - Improved documentation. - Added different arguments to configure how the macro works. Repository: extra-cmake-modules Description --- Create a macro that will generate the forward headers like we used to, in cmake configure time. Here's an example of how we'd port KParts to that macro: http://paste.opensuse.org/9880051 After the change, these are the installed headers: http://paste.opensuse.org/90980400 Diffs (updated) - modules/ECMGenerateHeaders.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113406/diff/ Testing --- Ported KParts and still everything works. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113406: Add a macro to automatically generate forward headers
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113406/#review42280 --- modules/ECMGenerateHeaders.cmake http://git.reviewboard.kde.org/r/113406/#comment30766 I really think the answers to my questions here need to be found first: http://thread.gmane.org/gmane.comp.kde.cvs/1272841 It should be more-simple than it currently is. modules/ECMGenerateHeaders.cmake http://git.reviewboard.kde.org/r/113406/#comment30767 This variable shouldn't be needed at all. modules/ECMGenerateHeaders.cmake http://git.reviewboard.kde.org/r/113406/#comment30768 I recommend not putting this in the API of the function, and instead users should use install(DIRECTORY) to install the generated files. - Stephen Kelly On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113406/ --- (Updated Oct. 24, 2013, 1:40 p.m.) Review request for Build System, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Create a macro that will generate the forward headers like we used to, in cmake configure time. Here's an example of how we'd port KParts to that macro: http://paste.opensuse.org/9880051 After the change, these are the installed headers: http://paste.opensuse.org/90980400 Diffs - modules/ECMGenerateHeaders.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113406/diff/ Testing --- Ported KParts and still everything works. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42281 --- Ship it! Looks ok. It will need testing with the startkde/startactive. - Ivan Čukić On Oct. 24, 2013, 2:04 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:04 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Keep the Things You Forgot
On 24 October 2013 14:54, Mario Fux KDE ML kde...@unormal.org wrote: You probably mean dot.kde.org/2013/09/25/frameworks-5 And this: http://dot.kde.org/2013/09/04/kde-release-structure-evolves Yes, that explains Frameworks and Workspaces, albeit a little fuzzy on Workspaces vs Plasma, but it kinda leaves Applications hanging, and with good reason as we really don't know what's happening there yet. Talking to a few people there does seem to be an interest in having a clean-up of the modules and apps, reducing the number of apps in the official release, having fewer essential applications of higher quality, and killing off the SC name once and for all. I'm also keen on breaking down the whole Modules vs Extragear distinction, they're all KDE Applications built by the same KDE Community, just with different release schedules. How that all might work is something the community as a whole needs to discuss. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42283 --- This review has been submitted with commit 90e2c0b65cce3f899d4fd5514493beaa60151f1e by Martin Klapetek to branch master. - Commit Hook On Oct. 24, 2013, 2:04 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:04 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On 24 October 2013 07:33, Kevin Ottens er...@kde.org wrote: On Wednesday 23 October 2013 20:40:19 John Layt wrote: * The obviously place to move it is k18n, as either part of KLocalizedString or in a new KByteFormatter class? Hm, wouldn't that fit in KCoreAddons? * No locale file overrides the default BinaryUnitDialect, so we only have to worry about reading any user override from kglobals Or have that done by the caller (thinking about KCoreAddons there, it couldn't use KConfig for the default). Well, that becomes the central question then, if we allow users to set a global override or not? I don't think its very useful to tell all apps that they need to read the global config themselves to see how to format the bytes, they would reasonably expect that that is what the method is there to hide from them. It would effectively become an application-level setting depending on if the app decides to read the config. On the other hand, if Qt eventually gains support it can use the setting from there. If we're happy to ignore user settings for now then KCoreAddons will be fine. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113406: Add a macro to automatically generate forward headers
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote: modules/ECMGenerateHeaders.cmake, line 29 http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line29 This variable shouldn't be needed at all. Variable? Or argument? Why? On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote: modules/ECMGenerateHeaders.cmake, line 32 http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line32 I recommend not putting this in the API of the function, and instead users should use install(DIRECTORY) to install the generated files. Why? On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote: modules/ECMGenerateHeaders.cmake, line 11 http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line11 I really think the answers to my questions here need to be found first: http://thread.gmane.org/gmane.comp.kde.cvs/1272841 It should be more-simple than it currently is. I think that this patch answers most of these questions, leaving up to discussion if we expect people to include module/something.h or just something.h. I'd say that if Qt5 transition teaches something is that it's not very flexible to namespace the include files, but that's up to the developer anyway... - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113406/#review42280 --- On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113406/ --- (Updated Oct. 24, 2013, 1:40 p.m.) Review request for Build System, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Create a macro that will generate the forward headers like we used to, in cmake configure time. Here's an example of how we'd port KParts to that macro: http://paste.opensuse.org/9880051 After the change, these are the installed headers: http://paste.opensuse.org/90980400 Diffs - modules/ECMGenerateHeaders.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113406/diff/ Testing --- Ported KParts and still everything works. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On Thursday 24 October 2013 16:56:47 John Layt wrote: On 24 October 2013 07:33, Kevin Ottens er...@kde.org wrote: On Wednesday 23 October 2013 20:40:19 John Layt wrote: * The obviously place to move it is k18n, as either part of KLocalizedString or in a new KByteFormatter class? Hm, wouldn't that fit in KCoreAddons? * No locale file overrides the default BinaryUnitDialect, so we only have to worry about reading any user override from kglobals Or have that done by the caller (thinking about KCoreAddons there, it couldn't use KConfig for the default). Well, that becomes the central question then, if we allow users to set a global override or not? I don't think its very useful to tell all apps that they need to read the global config themselves to see how to format the bytes, they would reasonably expect that that is what the method is there to hide from them. It would effectively become an application-level setting depending on if the app decides to read the config. On the other hand, if Qt eventually gains support it can use the setting from there. If we're happy to ignore user settings for now then KCoreAddons will be fine. I think we can go this route. Worst case we can channel the default setting through a dynamic property on the application object which would be set by the platform theme plugin. We used to do that for some other features. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com 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
Review Request 113422: Port kconfigtest and kconfignokdehometest to QStandardPaths
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113422/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Port kconfigtest and kconfignokdehometest to QStandardPaths They relied on setting XDG_CONFIG_HOME which will not work on Windows Diffs - tier1/kconfig/autotests/kconfigtest.h e0d7f7350159187e7611ddefd99d7d6faabde6ac tier1/kconfig/autotests/kconfignokdehometest.cpp ce53ca58fc7e1ce5a4345cce8a17de0e05866019 tier1/kconfig/autotests/kconfigtest.cpp 26e6a781bedf226ef0ca0d9030e107d3c412bd35 Diff: http://git.reviewboard.kde.org/r/113422/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113424: Use whoami as the command in KDesktopFileTest::testSuccessfulTryExec()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113424/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Use whoami as the command in KDesktopFileTest::testSuccessfulTryExec() Unlike /bin/ls this also works on Windows Diffs - tier1/kconfig/autotests/kdesktopfiletest.cpp 8f2ed2047e39f4f6b5d24a620474c3894f7986cc Diff: http://git.reviewboard.kde.org/r/113424/diff/ Testing --- Test passes on both linux and windows 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. - Fredrik Höglund On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113423: Fix KConfigCompiler_Test::testRunning() on Windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113423/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Fix KConfigCompiler_Test::testRunning() on Windows The test expects that the executables to find have no suffix Diffs - tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp 7f2697ad94ac6d433d18fb16a99ed1435433547d Diff: http://git.reviewboard.kde.org/r/113423/diff/ Testing --- Test passes. Although IMO it might make sense to drop this test, it takes ages due to spawning all those programs that do nothing useful. Compiling these generated files to see that they contain no errors is enough. 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 113422: Port kconfigtest and kconfignokdehometest to QStandardPaths
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113422/#review42297 --- tier1/kconfig/autotests/kconfignokdehometest.cpp http://git.reviewboard.kde.org/r/113422/#comment30774 Please review what you changed. You're removing the config directory of the test user, sounds dangerous! Note that it was changing the value of the XDG_CONFIG_HOME before running the test. I'm unsure what's the proper cross-platform fix to it. - Aleix Pol Gonzalez On Oct. 24, 2013, 3:55 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113422/ --- (Updated Oct. 24, 2013, 3:55 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Port kconfigtest and kconfignokdehometest to QStandardPaths They relied on setting XDG_CONFIG_HOME which will not work on Windows Diffs - tier1/kconfig/autotests/kconfigtest.h e0d7f7350159187e7611ddefd99d7d6faabde6ac tier1/kconfig/autotests/kconfignokdehometest.cpp ce53ca58fc7e1ce5a4345cce8a17de0e05866019 tier1/kconfig/autotests/kconfigtest.cpp 26e6a781bedf226ef0ca0d9030e107d3c412bd35 Diff: http://git.reviewboard.kde.org/r/113422/diff/ Testing --- 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 6:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 4:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 4:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113423: Fix KConfigCompiler_Test::testRunning() on Windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113423/#review42298 --- Ship it! Ship It! tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp http://git.reviewboard.kde.org/r/113423/#comment30775 You can pass CMAKE_EXECUTABLE_SUFFIX from cmake. - Aleix Pol Gonzalez On Oct. 24, 2013, 3:59 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113423/ --- (Updated Oct. 24, 2013, 3:59 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix KConfigCompiler_Test::testRunning() on Windows The test expects that the executables to find have no suffix Diffs - tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp 7f2697ad94ac6d433d18fb16a99ed1435433547d Diff: http://git.reviewboard.kde.org/r/113423/diff/ Testing --- Test passes. Although IMO it might make sense to drop this test, it takes ages due to spawning all those programs that do nothing useful. Compiling these generated files to see that they contain no errors is enough. 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 113402: Fix KI18n standalone build
On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Aurélien Gâteau wrote: Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. Aurélien Gâteau wrote: Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, QtQuick uses the QJS* classes from QtQML, so this is what we should be using. Kevin Ottens wrote: I would definitely welcome such a port... I remember asking ktranscript to be ported away from KJS. Would also make ki18n tier 1. I started diving into this today. No change for now, but I wrote some unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests for now. Chusslove: would you be interested in extending the test coverage? - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/ --- (Updated Oct. 23, 2013, 4:30 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KI18n depends on KJS to build the ktranscript plugin. This plugin requires an internal KJS Perl script as well as headers which were not installed. This is a 3-commit patches, which does the following: 1. Install kjs headers 2. Install wtf headers, using wtf/ and kjs/ in include directives (because some kjs headers includes wtf headers) 3. Fix KI18n: - Format top-level CMakeLists.txt according to CMake template - Duplicate KJS create_hash_table script - Add call to find_package(KJS) Individual patches available from http://agateau.com/tmp/ki18n-standalone.patch Diffs - superbuild/CMakeLists.txt 5cdec94 tier1/kjs/src/CMakeLists.txt 8629716 tier1/kjs/src/kjs/CMakeLists.txt 9523e89 tier1/kjs/src/wtf/CMakeLists.txt 83b4417 tier1/kjs/src/wtf/FastMalloc.h 29a72a5 tier1/kjs/src/wtf/HashCountedSet.h be3c387 tier1/kjs/src/wtf/HashFunctions.h f665447 tier1/kjs/src/wtf/HashMap.h ba2971c tier1/kjs/src/wtf/HashSet.h e84b349 tier1/kjs/src/wtf/HashTable.h 0b2c22c tier1/kjs/src/wtf/HashTable.cpp e08d09a tier1/kjs/src/wtf/HashTraits.h 4d01726 tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 tier1/kjs/src/wtf/OwnPtr.h 188a1dc tier1/kjs/src/wtf/PassRefPtr.h 25b9906 tier1/kjs/src/wtf/RefPtr.h 493ab05 tier1/kjs/src/wtf/Vector.h 9b0f38a tier1/kjs/src/wtf/VectorTraits.h 31ae028 tier2/ki18n/CMakeLists.txt 4cc8e30 tier2/ki18n/src/CMakeLists.txt 7f8259b4 tier2/ki18n/src/create_hash_table PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113402/diff/ Testing --- Builds within kdelibs and standalone. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Stephen Kelly wrote: Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. I.e. both will have copies of ECMSetupVersion.cmake, ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and KDECMakeSettings.cmake ? This is just so much against what was originally, at least my, idea of e-c-m: make cmake stuff we have in KDE, but which can be useful also in other projects, easier and quicker available to others (instead of not being able to release it when the first frameworks are released). But I don't object, it's your decision. - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Thomas Lübking wrote: Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. I've never done any (useful) startup benchmarks, but I'd be happy to try. Can you suggest some ways to measure cold startup time? Then I'll test both and post my findings. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113402: Fix KI18n standalone build
On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Aurélien Gâteau wrote: Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. Aurélien Gâteau wrote: Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, QtQuick uses the QJS* classes from QtQML, so this is what we should be using. Kevin Ottens wrote: I would definitely welcome such a port... I remember asking ktranscript to be ported away from KJS. Would also make ki18n tier 1. Aurélien Gâteau wrote: I started diving into this today. No change for now, but I wrote some unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests for now. Chusslove: would you be interested in extending the test coverage? Yes, I most certainly would be interested in extending the test coverage. But I intended to do it full-range, that is starting from test PO files (which are already there), once I get to it. And first I need to document it better :) Currently all there is is this wiki page: http://techbase.kde.org/Localization/Concepts/Transcript As for the port away from KJS, I have to state again that I see no value in that. Having ki18n be tier 1 is of no use: if someone is so tight on dependencies that using a tier 2 framework is a problem, then ki18n is the first thing to dump in favor of built-in Qt translation system, tier 1 or not. Note that ki18n also brings into play all the Gettext tools, as opposed to self-contained Qt translation tools. The only possible advantage of ki18n in tier 1 is that it can be used by tier 2 frameworks, of which there is not much by my estimate (and between tier 1 and tier 3, I also fail to see the reason for existence of tier 2). - Chusslove --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/ --- (Updated Oct. 23, 2013, 4:30 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KI18n depends on KJS to build the ktranscript plugin. This plugin requires an internal KJS Perl script as well as headers which were not installed. This is a 3-commit patches, which does the following: 1. Install kjs headers 2. Install wtf headers, using wtf/ and kjs/ in include directives (because some kjs headers includes wtf headers) 3. Fix KI18n: - Format top-level CMakeLists.txt according to CMake template - Duplicate KJS create_hash_table script - Add call to find_package(KJS) Individual patches available from http://agateau.com/tmp/ki18n-standalone.patch Diffs - superbuild/CMakeLists.txt 5cdec94 tier1/kjs/src/CMakeLists.txt 8629716 tier1/kjs/src/kjs/CMakeLists.txt 9523e89 tier1/kjs/src/wtf/CMakeLists.txt 83b4417 tier1/kjs/src/wtf/FastMalloc.h 29a72a5
Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Thomas Lübking wrote: Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. Martin Klapetek wrote: I've never done any (useful) startup benchmarks, but I'd be happy to try. Can you suggest some ways to measure cold startup time? Then I'll test both and post my findings. If loading Qt took 5 seconds, loading the rest would take 10 minutes. As I said doesn't seem to be noticeably slower. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Thomas Lübking wrote: Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. Martin Klapetek wrote: I've never done any (useful) startup benchmarks, but I'd be happy to try. Can you suggest some ways to measure cold startup time? Then I'll test both and post my findings. Ivan Čukić wrote: If loading Qt took 5 seconds, loading the rest would take 10 minutes. As I said doesn't seem to be noticeably slower. echo 1 /proc/sys/vm/drop_caches Clears all filesystem caches, so that everything has to be loaded from disk, that's essentially what you have after a cold boot. - Sebastian --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Thomas Lübking wrote: Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. Martin Klapetek wrote: I've never done any (useful) startup benchmarks, but I'd be happy to try. Can you suggest some ways to measure cold startup time? Then I'll test both and post my findings. Ivan Čukić wrote: If loading Qt took 5 seconds, loading the rest would take 10 minutes. As I said doesn't seem to be noticeably slower. Sebastian Kügler wrote: echo 1 /proc/sys/vm/drop_caches Clears all filesystem caches, so that everything has to be loaded from disk, that's essentially what you have after a cold boot. but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. It was a long time ago, but that doesn't mean you should undo what is essentially a bug fix without checking if the bug is still reproducible. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. The point isn't whether it slows down the boot process or not, the point is that the splash screen should appear immediately so the user isn't left staring at a blank screen for N seconds. - Fredrik --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)
On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote: What's the cold startup time like for KSplashQML compared to KSplashX? Let's not forget that the reason KPlash was rewritten to only depend on X + libjpeg + libpng was so that the startup time would be limited by the time it takes to load the images for the theme. Martin Gräßlin wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. Ivan Čukić wrote: We haven't done any real benchmarks, but it doesn't seem to be noticeably slower. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. Thomas Lübking wrote: Isn't the splash screen supposed to cover (also) those loading costs? If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place. Martin Klapetek wrote: I've never done any (useful) startup benchmarks, but I'd be happy to try. Can you suggest some ways to measure cold startup time? Then I'll test both and post my findings. Ivan Čukić wrote: If loading Qt took 5 seconds, loading the rest would take 10 minutes. As I said doesn't seem to be noticeably slower. Sebastian Kügler wrote: echo 1 /proc/sys/vm/drop_caches Clears all filesystem caches, so that everything has to be loaded from disk, that's essentially what you have after a cold boot. Fredrik Höglund wrote: but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal. It was a long time ago, but that doesn't mean you should undo what is essentially a bug fix without checking if the bug is still reproducible. It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded. The point isn't whether it slows down the boot process or not, the point is that the splash screen should appear immediately so the user isn't left staring at a blank screen for N seconds. This is a review for a patch. It is really not the place for discussing the pros and cons of ksplashqml. If anyone wants to maintain ksplashx and create ksplashwayland, they are free to do so. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/#review42299 --- On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113415/ --- (Updated Oct. 24, 2013, 2:19 p.m.) Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't. KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit. I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as Classic or KDE 4 theme. Diffs - ksplash/ksplashqml/CMakeLists.txt 8cd5305 ksplash/ksplashqml/SplashApp.h 3c55be9 ksplash/ksplashqml/SplashApp.cpp 7c528d0 ksplash/ksplashqml/SplashWindow.h 9680c1e ksplash/ksplashqml/SplashWindow.cpp 4417643 ksplash/ksplashqml/SystemInfo.h 7a74554 ksplash/ksplashqml/main.cpp c2722ab9 ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 Diff: http://git.reviewboard.kde.org/r/113415/diff/ Testing --- Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself. 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 113406: Add a macro to automatically generate forward headers
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
modules/ECMGenerateHeaders.cmake, line 11
http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line11
I really think the answers to my questions here need to be found first:
http://thread.gmane.org/gmane.comp.kde.cvs/1272841
It should be more-simple than it currently is.
Aleix Pol Gonzalez wrote:
I think that this patch answers most of these questions, leaving up to
discussion if we expect people to include module/something.h or just
something.h.
I'd say that if Qt5 transition teaches something is that it's not very
flexible to namespace the include files, but that's up to the developer
anyway...
I'm not sure it does...
For example, grantlee installs headers like this:
include/grantlee/engine.h
include/grantlee_export.h
include/grantlee/engine.h has include grantlee_export.h and even if it is
grantlee_export.h, the intent is that the user only needs -Iinclude/, and
does not need -Iinclude/grantlee.
The same is not true of where KF5 installs headers and how they are included.
There is scope for improvement there, and this patch does not affect that.
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
modules/ECMGenerateHeaders.cmake, line 29
http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line29
This variable shouldn't be needed at all.
Aleix Pol Gonzalez wrote:
Variable? Or argument? Why?
Argument, yes, sorry.
I think that because the source dir is already in the
INTERFACE_INCLUDE_DIRECTORIES of the target, there is no need to have to
specify it, and there should be no need to use ${EGH_HEADERS_DIR}/ in the
generated include.
I guess you have some reason for doing that, but that just points to
non-uniformity which should maybe be fixed, as I wrote in the KIO commit I
linked to.
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
modules/ECMGenerateHeaders.cmake, line 32
http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line32
I recommend not putting this in the API of the function, and instead
users should use
install(DIRECTORY) to install the generated files.
Aleix Pol Gonzalez wrote:
Why?
I think it's better API. It's what all existing functions which generate
headers do.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---
On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/
---
(Updated Oct. 24, 2013, 1:40 p.m.)
Review request for Build System, KDE Frameworks and Stephen Kelly.
Repository: extra-cmake-modules
Description
---
Create a macro that will generate the forward headers like we used to, in
cmake configure time.
Here's an example of how we'd port KParts to that macro:
http://paste.opensuse.org/9880051
After the change, these are the installed headers:
http://paste.opensuse.org/90980400
Diffs
-
modules/ECMGenerateHeaders.cmake PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/113406/diff/
Testing
---
Ported KParts and still everything works.
Thanks,
Aleix Pol Gonzalez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113406: Add a macro to automatically generate forward headers
On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
modules/ECMGenerateHeaders.cmake, line 29
http://git.reviewboard.kde.org/r/113406/diff/2/?file=205462#file205462line29
This variable shouldn't be needed at all.
Aleix Pol Gonzalez wrote:
Variable? Or argument? Why?
Stephen Kelly wrote:
Argument, yes, sorry.
I think that because the source dir is already in the
INTERFACE_INCLUDE_DIRECTORIES of the target, there is no need to have to
specify it, and there should be no need to use ${EGH_HEADERS_DIR}/ in the
generated include.
I guess you have some reason for doing that, but that just points to
non-uniformity which should maybe be fixed, as I wrote in the KIO commit I
linked to.
I don't see any target involved here...
- Alexander
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---
On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/
---
(Updated Oct. 24, 2013, 1:40 p.m.)
Review request for Build System, KDE Frameworks and Stephen Kelly.
Repository: extra-cmake-modules
Description
---
Create a macro that will generate the forward headers like we used to, in
cmake configure time.
Here's an example of how we'd port KParts to that macro:
http://paste.opensuse.org/9880051
After the change, these are the installed headers:
http://paste.opensuse.org/90980400
Diffs
-
modules/ECMGenerateHeaders.cmake PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/113406/diff/
Testing
---
Ported KParts and still everything works.
Thanks,
Aleix Pol Gonzalez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113402: Fix KI18n standalone build
On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote: I can only say that whatever is the proper fix here, it is fine with me. Since non-installed headers are being used, maybe ki18n is using KJS in a way which became deprecated somewhere along the way? If so, I've nothing against fixing that instead. Aleix Pol Gonzalez wrote: Well the thing is that ki18n was using private API (since it was in the same module, kdelibs). Aurélien: what about installing these headers in a private/ directory? Chusslove Illich wrote: If I recall, when implementing that I mimicked what khtml was doing. And apparently is still doing. Aleix Pol Gonzalez wrote: khtml is in kdelibs as well, nobody has tried to build it standalone just yet, I guess. Chusslove Illich wrote: Right, but, how is then KJS supposed to be used in a different way? Are these private headers really private, or actually necessary to use KJS as a JS interpreter in random client code? Aurélien Gâteau wrote: The ideal solution would be for ktranscript to only use public headers, but I assume there is no way to do so (I haven't taken the time to study ktranscript enough to understand what it does), Chusslove, it would be awesome if you could have a look at it. If it is definitely not possible, then I am going to update my changes to install to a private/ directory, like Aleix suggests. Aurélien Gâteau wrote: Actually, the even more ideal solution would be for ktranscript to use QtScript instead of KJS. In the future we will have more and more applications developed with QtQuick, so they will already link to QtScript, loading another JavaScript interpreter sounds wasteful to me. Do you think this is doable? I would be quite interested in helping making it happen. Aurélien Gâteau wrote: Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, QtQuick uses the QJS* classes from QtQML, so this is what we should be using. Kevin Ottens wrote: I would definitely welcome such a port... I remember asking ktranscript to be ported away from KJS. Would also make ki18n tier 1. Aurélien Gâteau wrote: I started diving into this today. No change for now, but I wrote some unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests for now. Chusslove: would you be interested in extending the test coverage? Chusslove Illich wrote: Yes, I most certainly would be interested in extending the test coverage. But I intended to do it full-range, that is starting from test PO files (which are already there), once I get to it. And first I need to document it better :) Currently all there is is this wiki page: http://techbase.kde.org/Localization/Concepts/Transcript As for the port away from KJS, I have to state again that I see no value in that. Having ki18n be tier 1 is of no use: if someone is so tight on dependencies that using a tier 2 framework is a problem, then ki18n is the first thing to dump in favor of built-in Qt translation system, tier 1 or not. Note that ki18n also brings into play all the Gettext tools, as opposed to self-contained Qt translation tools. The only possible advantage of ki18n in tier 1 is that it can be used by tier 2 frameworks, of which there is not much by my estimate (and between tier 1 and tier 3, I also fail to see the reason for existence of tier 2). There is value in both full-range tests and tests exercising smaller parts of the code as well IMO. Thanks for the link, I am going to look at it. Regarding the port to QJSEngine, I see the following advantages to it: - It solves the build issue I have been trying to fix with this request: no need for uninstalled headers anymore. - The code is going to be simpler: from what I read of QJSEngine and KJS, exposing an object using QJSEngine is simpler than with KJS: no need for lookup tables or things like that, just a QObject with slots. - I expect QJSEngine to be better maintained than KJS, given that it is the backbone of QtQuick. - Having ki18n in tier1 would make it more attractive to Qt developers since it brings superior translation support. Right now the cost of dragging in a separate JavaScript interpreter, can be perceived as a burden especially for QtQuick developers. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/#review4 --- On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113402/
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Stephen Kelly wrote: Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. Alexander Neundorf wrote: I.e. both will have copies of ECMSetupVersion.cmake, ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and KDECMakeSettings.cmake ? This is just so much against what was originally, at least my, idea of e-c-m: make cmake stuff we have in KDE, but which can be useful also in other projects, easier and quicker available to others (instead of not being able to release it when the first frameworks are released). But I don't object, it's your decision. Stephen Kelly wrote: It's not my decision either. It's just a recommendation. I object. What's the big impediment of releasing ECM? If there's an impediment, let's fix it. - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
extra-cmake-modules: remove ECMPrintVariables.cmake
Hi, e-c-m has a macro ecm_print_variables() From the documentation: # Example: # ecm_print_variables(CMAKE_C_COMPILER # CMAKE_MAJOR_VERSION THIS_ONE_DOES_NOT_EXIST) # Gives: # -- CMAKE_C_COMPILER=/usr/bin/gcc ; CMAKE_MAJOR_VERSION=2 ; # THIS_ONE_DOES_NOT_EXIST= Now that kde frameworks depends on cmake 2.8.12, this could be removed, since cmake now has something similar. include(CMakePrintHelpers) cmake_print_variables(CMAKE_C_COMPILER CMAKE_MAJOR_VERSION THIS_ONE_DOES_NOT_EXIST) and additionally for printing properties (again from the docs): cmake_print_properties(TARGETS foo bar PROPERTIES LOCATION INTERFACE_INCLUDE_DIRS) # This will print the LOCATION and INTERFACE_INCLUDE_DIRS properties for both # targets foo and bar. These two functions are useful mostly for debugging, and make this more convenient. If somebody feels like it, I think it would be a good idea to remove ECMPrintVariables.cmake, now that there is a replacement in cmake. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113424: Use whoami as the command in KDesktopFileTest::testSuccessfulTryExec()
On Oct. 24, 2013, 4:25 p.m., Alex Merry wrote: whoami is part of coreutils, so should be available everywhere. The only possible issue I see is that we've gone from a test that doesn't depend on PATH to one that does. This isn't necessarily a problem, but it will test slightly different code paths. part of coreutils is irrelevant for Windows, there's no such thing as coreutils. The point is that Windows also happens to have a command called 'whoami'. - Nicolás --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113424/#review42320 --- On Oct. 24, 2013, 12:59 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113424/ --- (Updated Oct. 24, 2013, 12:59 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Use whoami as the command in KDesktopFileTest::testSuccessfulTryExec() Unlike /bin/ls this also works on Windows Diffs - tier1/kconfig/autotests/kdesktopfiletest.cpp 8f2ed2047e39f4f6b5d24a620474c3894f7986cc Diff: http://git.reviewboard.kde.org/r/113424/diff/ Testing --- Test passes on both linux and windows 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 113426: Adjust API in KEmoticons framework: createNew method
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113426/ --- (Updated Oct. 24, 2013, 9:54 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: createNew method -To make KEmoticons API more consistent, deprecate KEmoticonsProvider::createNew() and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way, we have loadTheme(), saveTheme() and newTheme(). -Adjust plugins. -Before the cleanup, KEmoticonsTheme was calling KEmoticonsProvider::createNew(), which was empty. Therefore, I deprecate it and advice subclassing KEmoticonsProvider. Diffs - KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 staging/kemoticons/src/core/kemoticons.cpp 43dac6517b77a0d0040912958fe76687b475d85c staging/kemoticons/src/core/kemoticonsprovider.h 2ec0de8d1dfb846188bd458b49a4028fee115431 staging/kemoticons/src/core/kemoticonsprovider.cpp 7374966c65922c3e7a5be881c198a8f8f52fee29 staging/kemoticons/src/core/kemoticonstheme.h 25fc29453535d7e73f4e2d0752ce3f989c83fa96 staging/kemoticons/src/core/kemoticonstheme.cpp e54d015e7f0f866d199d8eed7863fafd28576c13 staging/kemoticons/src/providers/adium/adium_emoticons.h 01d89e13834c345765e696d66560071dc10291af staging/kemoticons/src/providers/adium/adium_emoticons.cpp e6719d112a14478bdfd7f8c47633c18108a5633a staging/kemoticons/src/providers/kde/kde_emoticons.h 0738b79dcf734b7904e061b5eb41807ccaf443ff staging/kemoticons/src/providers/kde/kde_emoticons.cpp a99c6d84f5ab7e0e2f41027c37a97f170333dca8 staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h a51b736f7702d7af1f1367dd1f13271647212fee staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 7596e30e8e5153185a3dd365858567c69477ff4a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 4ba706f519cebedaa6c9c3f2f02331e85745e89a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 Diff: http://git.reviewboard.kde.org/r/113426/diff/ Testing --- Builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113426: Adjust API in KEmoticons framework: createNew method
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113426/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: createNew method -To make KEmoticons API more consistent, deprecate KEmoticonsProvider::createNew() and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way, we have loadTheme(), saveTheme() and newTheme(). -Adjust plugins. -Before the cleanup, KEmoticonsTheme was calling KEmoticonsProvider::createNew(), which was empty. Therefore, I deprecate it and advice subclassing KEmoticonsProvider. Diffs - KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 staging/kemoticons/src/core/kemoticons.cpp 43dac6517b77a0d0040912958fe76687b475d85c staging/kemoticons/src/core/kemoticonsprovider.h 2ec0de8d1dfb846188bd458b49a4028fee115431 staging/kemoticons/src/core/kemoticonsprovider.cpp 7374966c65922c3e7a5be881c198a8f8f52fee29 staging/kemoticons/src/core/kemoticonstheme.h 25fc29453535d7e73f4e2d0752ce3f989c83fa96 staging/kemoticons/src/core/kemoticonstheme.cpp e54d015e7f0f866d199d8eed7863fafd28576c13 staging/kemoticons/src/providers/adium/adium_emoticons.h 01d89e13834c345765e696d66560071dc10291af staging/kemoticons/src/providers/adium/adium_emoticons.cpp e6719d112a14478bdfd7f8c47633c18108a5633a staging/kemoticons/src/providers/kde/kde_emoticons.h 0738b79dcf734b7904e061b5eb41807ccaf443ff staging/kemoticons/src/providers/kde/kde_emoticons.cpp a99c6d84f5ab7e0e2f41027c37a97f170333dca8 staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h a51b736f7702d7af1f1367dd1f13271647212fee staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 7596e30e8e5153185a3dd365858567c69477ff4a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 4ba706f519cebedaa6c9c3f2f02331e85745e89a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 Diff: http://git.reviewboard.kde.org/r/113426/diff/ Testing --- Builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KDirWatch vs QFileSystemWatcher
Hi
If your KDirWatch backend is QFileSystemWatcher, one of the testcases
fails.
The last QVERIFY in testMoveTo never receives the signal dirty-signal it
is looking for.
Apparantly, the watch.removeFile apparantly somehow turns off the QFSW
to not do any further notifications for what happens in the directory
that it also is supposed to be watching.
I haven't yet fully understood what's going on here, but if someone is
up for it, fixing it would be nice. Among others, it is the only backend
available on windows.
This dirty patch seems to ensure that QFSW is used on your platform:
diff --git a/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
b/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
index 2a89372..8bc9d9b 100644
--- a/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
+++ b/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
@@ -103,12 +103,7 @@ static KDirWatch::Method methodFromString(const QString
method) {
} else if (method == QLatin1String(QFSWatch)) {
return KDirWatch::QFSWatch;
} else {
-#ifdef Q_OS_LINUX
-// inotify supports delete+recreate+modify, which QFSWatch doesn't support
-return KDirWatch::INotify;
-#else
return KDirWatch::QFSWatch;
-#endif
}
}
Anyone looking into it would be nice.
/Sune
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113426: Adjust API in KEmoticons framework: createNew method
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113426/ --- (Updated Oct. 24, 2013, 9:54 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: createNew method -To make KEmoticons API more consistent, deprecate KEmoticonsProvider::createNew() and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way, we have loadTheme(), saveTheme() and newTheme(). -Adjust plugins. -Before the cleanup, KEmoticonsTheme was calling KEmoticonsProvider::createNew(), which was empty. Therefore, I deprecate it and advice subclassing KEmoticonsProvider. Diffs - KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 staging/kemoticons/src/core/kemoticons.cpp 43dac6517b77a0d0040912958fe76687b475d85c staging/kemoticons/src/core/kemoticonsprovider.h 2ec0de8d1dfb846188bd458b49a4028fee115431 staging/kemoticons/src/core/kemoticonsprovider.cpp 7374966c65922c3e7a5be881c198a8f8f52fee29 staging/kemoticons/src/core/kemoticonstheme.h 25fc29453535d7e73f4e2d0752ce3f989c83fa96 staging/kemoticons/src/core/kemoticonstheme.cpp e54d015e7f0f866d199d8eed7863fafd28576c13 staging/kemoticons/src/providers/adium/adium_emoticons.h 01d89e13834c345765e696d66560071dc10291af staging/kemoticons/src/providers/adium/adium_emoticons.cpp e6719d112a14478bdfd7f8c47633c18108a5633a staging/kemoticons/src/providers/kde/kde_emoticons.h 0738b79dcf734b7904e061b5eb41807ccaf443ff staging/kemoticons/src/providers/kde/kde_emoticons.cpp a99c6d84f5ab7e0e2f41027c37a97f170333dca8 staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h a51b736f7702d7af1f1367dd1f13271647212fee staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 7596e30e8e5153185a3dd365858567c69477ff4a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 4ba706f519cebedaa6c9c3f2f02331e85745e89a staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 Diff: http://git.reviewboard.kde.org/r/113426/diff/ Testing --- Builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
