Re: Review Request 111701: Port away from kde_file in KDirOperator (KFile)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111701/#review36951 --- Ship it! Ship It! - Kevin Ottens On July 29, 2013, 9:22 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111701/ --- (Updated July 29, 2013, 9:22 p.m.) Review request for KDE Frameworks. Description --- Port away from kde_file in KDirOperator (KFile) REVIEW: 111701 Diffs - kfile/kdiroperator.cpp d4da9eb775fc8b3d2a8e035d82ebfb8d89b9aa5d Diff: http://git.reviewboard.kde.org/r/111701/diff/ Testing --- It builds. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111789: Improve KFileItemList memory usage and performance
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111789/#review36952 --- Ship it! Ship It! - Kevin Ottens On July 29, 2013, 10:39 p.m., Frank Reininghaus wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111789/ --- (Updated July 29, 2013, 10:39 p.m.) Review request for KDE Frameworks and David Faure. Description --- The other day, I noticed that KFileItem is not declared as a Q_MOVABLE_TYPE. Therefore, QList does not store KFileItems directly, but only pointers to them, and allocates memory for every single KFileItem separately. This wastes quite a bit of memory. It looks like now might be a good moment to fix this because we can break binary compatibility with KDE 4.x. Diffs - staging/kio/src/core/kfileitem.h 2c33f3c Diff: http://git.reviewboard.kde.org/r/111789/diff/ Testing --- My poor man's aproach to test the memory usage and performace is here: http://paste.kde.org/p46abc91f/ (the reason for the 10 second delay is that I needed some time to take a KSysGuard screen shot). It creates a KFileItemList with 1 million empty KFileItems. The memory usage change is shown in the pictures. I used both massif/massif-visualizer and KSysGuard to measure how much memory it uses. The KSysGuard measurement shows a far bigger difference - this is because massif only measures the net memory consumption and fails to consider the overhead which is caused by the memory allocator itself. The latter is quite considerable when many small memory allocations are made. Moreover, I also measured the runtime of the test (without massif). 5 measurements without patch required between 171 ms and 189 ms. 5 measurements with patch required between 98 ms and 106 ms. File Attachments Memory usage WITHOUT patch http://git.reviewboard.kde.org/media/uploaded/files/2013/07/29/before.png Memory usage WITH patch http://git.reviewboard.kde.org/media/uploaded/files/2013/07/29/after.png Thanks, Frank Reininghaus ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111792: XCB event handling for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/#review36954 --- Ship it! I don't feel like blocking this patch you know much more than me on this topic and I didn't spot anything obviously wrong. :-) There's a few style issues in the patch (mainly space in between parenthesis), but since this whole module is rather bad for following the style it's minor and will get fixed later. - Kevin Ottens On July 30, 2013, 8:34 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/ --- (Updated July 30, 2013, 8:34 a.m.) Review request for KDE Frameworks. Description --- Port KWindowSystemPrivate to QAbstractNativeEventFilter Obviously it's only filtering XCB events and the event filtering code is ported to use XCB data types. With this change the KSystemEventFilter is no longer needed and therefore dropped. Port NETWinInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib code by XCB equivalent. The logic of looped event compaction is dropped as inspecting the event queue is not possible on XCB. Port NETRootInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib functionality to XCB. The compaction logic got dropped as it was hard disabled anyway. Note: this change currently breaks KWindowSystem as it also needs to be ported. Coding style cleanup of event handling related methods Before adjusting the code let's have a proper coding style. Diffs - tier1/kwindowsystem/src/CMakeLists.txt PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter.cpp PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter_p.h PRE-CREATION tier1/kwindowsystem/src/kwindowsystem_x11.cpp PRE-CREATION tier1/kwindowsystem/src/netwm.h PRE-CREATION tier1/kwindowsystem/src/netwm.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111792/diff/ Testing --- Part of it indirectly tested through KWin on 5. Window caption gets updated and that is triggered through NETWinInfo, so I am positively optimistic that all of it works. 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 111833: Remove small dependency between KGlobalSettings::naturalCompare and KDirSortFilterProxyModel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111833/#review36955 --- Ship it! Ship It! - Kevin Ottens On Aug. 1, 2013, 11:03 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111833/ --- (Updated Aug. 1, 2013, 11:03 a.m.) Review request for KDE Frameworks. Description --- Directly read the config instead of using KGlobalSettings as a proxy for the setting. We lose the setting changed functionality but now we don't depend on KGlobalSettings class. There's KDE_DEFAULT_* but I'll see how to do that in a different patch, there are other cases where it's needed. Diffs - KDE5PORTING.html 9d84525 kfile/kdirsortfilterproxymodel.cpp c8ea9b2 Diff: http://git.reviewboard.kde.org/r/111833/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111834: Move KHelpClient into xmlgui
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111834/#review36956 --- Ship it! Ship It! - Kevin Ottens On Aug. 1, 2013, 3:23 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111834/ --- (Updated Aug. 1, 2013, 3:23 p.m.) Review request for KDE Frameworks. Description --- The class still was in kdeui so it had to be moved, after discussing with ervin, it seemed like it's a good place for the function to be. After all, it's just a helper function, we can always (hope to) instantiate the help using QDesktopServices::openUrl() Diffs - kdeui/CMakeLists.txt 5cbcfb0 staging/xmlgui/src/CMakeLists.txt 255960f staging/xmlgui/src/khelpclient.h e5f9946 staging/xmlgui/src/khelpclient.cpp dda0b13 Diff: http://git.reviewboard.kde.org/r/111834/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111792: XCB event handling for KWindowSystem
On Aug. 2, 2013, 10:18 a.m., Kevin Ottens wrote: I don't feel like blocking this patch you know much more than me on this topic and I didn't spot anything obviously wrong. :-) There's a few style issues in the patch (mainly space in between parenthesis), but since this whole module is rather bad for following the style it's minor and will get fixed later. There's a few style issues in the patch I tried to fix as many as possible. At least I run kdevelop's reformat source on the changed code paths. But I agree the whole module needs a proper automatic cleanup. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/#review36954 --- On July 30, 2013, 10:34 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/ --- (Updated July 30, 2013, 10:34 a.m.) Review request for KDE Frameworks. Description --- Port KWindowSystemPrivate to QAbstractNativeEventFilter Obviously it's only filtering XCB events and the event filtering code is ported to use XCB data types. With this change the KSystemEventFilter is no longer needed and therefore dropped. Port NETWinInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib code by XCB equivalent. The logic of looped event compaction is dropped as inspecting the event queue is not possible on XCB. Port NETRootInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib functionality to XCB. The compaction logic got dropped as it was hard disabled anyway. Note: this change currently breaks KWindowSystem as it also needs to be ported. Coding style cleanup of event handling related methods Before adjusting the code let's have a proper coding style. Diffs - tier1/kwindowsystem/src/CMakeLists.txt PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter.cpp PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter_p.h PRE-CREATION tier1/kwindowsystem/src/kwindowsystem_x11.cpp PRE-CREATION tier1/kwindowsystem/src/netwm.h PRE-CREATION tier1/kwindowsystem/src/netwm.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111792/diff/ Testing --- Part of it indirectly tested through KWin on 5. Window caption gets updated and that is triggered through NETWinInfo, so I am positively optimistic that all of it works. 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 111841: Prefer job-exec() to synchronousRun
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/#review36958 --- kio/tests/netaccesstest.cpp http://git.reviewboard.kde.org/r/111841/#comment27258 Well you're not testing NetAccess anymore then. :-) This one shouldn't be changed. staging/kiconthemes/autotests/kiconloader_unittest.cpp http://git.reviewboard.kde.org/r/111841/#comment27259 Why this change? - Kevin Ottens On Aug. 1, 2013, 5:52 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/ --- (Updated Aug. 1, 2013, 5:52 p.m.) Review request for KDE Frameworks. Description --- Ports all uses of NetAccess::synchronousRun to KJob::exec() but one in khtml, but there it should be re-thought, the change is not straight-forward (XmlHttpRequest). Diffs - kfile/kdirselectdialog.cpp 68c4b93 kfile/kfilewidget.cpp 2fa1d28 kio/kio/paste.cpp c7c43e1 kio/tests/fileundomanagertest.cpp 5fe746f kio/tests/jobguitest.cpp 5a6c950 kio/tests/jobremotetest.cpp 5759b21 kio/tests/jobtest.cpp ceaf605 kio/tests/kdirmodeltest.cpp 8059fa8 kio/tests/netaccesstest.cpp 174feb0 staging/kiconthemes/autotests/kiconloader_unittest.cpp 116203c staging/kunitconversion/src/kunitconversion/currency.cpp 8d18f633 Diff: http://git.reviewboard.kde.org/r/111841/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111689: desktoptojson -- convert .desktop files to .json for plugin metadata
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111689/#review36959 --- staging/kservice/tools/CMakeLists.txt http://git.reviewboard.kde.org/r/111689/#comment27260 Should be under src staging/kservice/tools/desktoptojson/kconfigtojson.h http://git.reviewboard.kde.org/r/111689/#comment27261 Why those default parameters? The implementation code actually doesn't seem ready to be called with no parameters, and is never called that way. You probably want to drop the default values here. staging/kservice/tools/desktoptojson/main.cpp http://git.reviewboard.kde.org/r/111689/#comment27262 Why 2.0 and not 1.0? :-) - Kevin Ottens On Aug. 1, 2013, 6:59 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111689/ --- (Updated Aug. 1, 2013, 6:59 p.m.) Review request for KDE Frameworks and David Faure. Description --- Small program which takes a .desktop file and converts it to json. This is useful to convert plugins which have their metadata in .desktop files (i.e. all KDE plugins) to Qt's new plugin system. Diffs - staging/kservice/tools/CMakeLists.txt PRE-CREATION staging/kservice/tools/desktoptojson/CMakeLists.txt PRE-CREATION staging/kservice/tools/desktoptojson/kconfigtojson.h PRE-CREATION staging/kservice/tools/desktoptojson/kconfigtojson.cpp PRE-CREATION staging/kservice/tools/desktoptojson/main.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111689/diff/ Testing --- Converted metadata of several plugins and used them from QPluginLoader -- works. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111689: desktoptojson -- convert .desktop files to .json for plugin metadata
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111689/#review36960 --- staging/kservice/tools/desktoptojson/kconfigtojson.h http://git.reviewboard.kde.org/r/111689/#comment27263 I don't like file-static QStrings (global objects), and even less in headers (it creates an unused variable in any user of the header). My suggestion: define the command-line options in the KConfigToJson constructor or runMain(). To go even further and avoid the need for shared strings completely: store the two QCommandLineOptions as members of the class, and pass them to isSet() and value(), instead of strings. staging/kservice/tools/desktoptojson/kconfigtojson.cpp http://git.reviewboard.kde.org/r/111689/#comment27266 ;; - ; staging/kservice/tools/desktoptojson/kconfigtojson.cpp http://git.reviewboard.kde.org/r/111689/#comment27265 ;; - ; staging/kservice/tools/desktoptojson/main.cpp http://git.reviewboard.kde.org/r/111689/#comment27264 It makes no difference in this particular case, but it's always better to create the app first, and then use any other Qt API = swap the first two lines. - David Faure On Aug. 1, 2013, 6:59 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111689/ --- (Updated Aug. 1, 2013, 6:59 p.m.) Review request for KDE Frameworks and David Faure. Description --- Small program which takes a .desktop file and converts it to json. This is useful to convert plugins which have their metadata in .desktop files (i.e. all KDE plugins) to Qt's new plugin system. Diffs - staging/kservice/tools/CMakeLists.txt PRE-CREATION staging/kservice/tools/desktoptojson/CMakeLists.txt PRE-CREATION staging/kservice/tools/desktoptojson/kconfigtojson.h PRE-CREATION staging/kservice/tools/desktoptojson/kconfigtojson.cpp PRE-CREATION staging/kservice/tools/desktoptojson/main.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111689/diff/ Testing --- Converted metadata of several plugins and used them from QPluginLoader -- works. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Ki18n mostly ready
On Wednesday 31 July 2013 19:58:52 Chusslove Illich wrote: /** - * Inserts the catalog in the main locale object if it exists. - * Otherwise the catalog name is stored and added once the main locale gets created - * @since 4.6 - * @deprecated since 5.0, use KLocalizedString::insertCatalog - */ -KDE4SUPPORT_DEPRECATED_EXPORT void insertCatalog(const QString catalog); - There's no way to keep the method for source compatibility and implement it somehow on top of the new solution? I'm afraid of the porting effort created by all these source incompatible changes. If we can minimize that, it's all for the better. -- 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 111792: XCB event handling for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/#review36961 --- Ship it! Looks good to me (I wrote the native-event-filter API in Qt5), thanks for killing KSystemEventFilter -- but please add a porting note to KDE5PORTING.html about that class. It's used outside kdelibs: http://lxr.kde.org/ident?i=KSystemEventFilter - David Faure On July 30, 2013, 8:34 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/ --- (Updated July 30, 2013, 8:34 a.m.) Review request for KDE Frameworks. Description --- Port KWindowSystemPrivate to QAbstractNativeEventFilter Obviously it's only filtering XCB events and the event filtering code is ported to use XCB data types. With this change the KSystemEventFilter is no longer needed and therefore dropped. Port NETWinInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib code by XCB equivalent. The logic of looped event compaction is dropped as inspecting the event queue is not possible on XCB. Port NETRootInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib functionality to XCB. The compaction logic got dropped as it was hard disabled anyway. Note: this change currently breaks KWindowSystem as it also needs to be ported. Coding style cleanup of event handling related methods Before adjusting the code let's have a proper coding style. Diffs - tier1/kwindowsystem/src/CMakeLists.txt PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter.cpp PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter_p.h PRE-CREATION tier1/kwindowsystem/src/kwindowsystem_x11.cpp PRE-CREATION tier1/kwindowsystem/src/netwm.h PRE-CREATION tier1/kwindowsystem/src/netwm.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111792/diff/ Testing --- Part of it indirectly tested through KWin on 5. Window caption gets updated and that is triggered through NETWinInfo, so I am positively optimistic that all of it works. 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 111841: Prefer job-exec() to synchronousRun
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/ --- (Updated Aug. 2, 2013, 9:38 a.m.) Review request for KDE Frameworks. Changes --- revert crazy change and unrelated debug entry. Description --- Ports all uses of NetAccess::synchronousRun to KJob::exec() but one in khtml, but there it should be re-thought, the change is not straight-forward (XmlHttpRequest). Diffs (updated) - kfile/kdirselectdialog.cpp 68c4b93 kfile/kfilewidget.cpp 2fa1d28 kio/kio/paste.cpp c7c43e1 kio/tests/fileundomanagertest.cpp 5fe746f kio/tests/jobguitest.cpp 5a6c950 kio/tests/jobremotetest.cpp 5759b21 kio/tests/jobtest.cpp ceaf605 kio/tests/kdirmodeltest.cpp 8059fa8 staging/kunitconversion/src/kunitconversion/currency.cpp 8d18f633 Diff: http://git.reviewboard.kde.org/r/111841/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111841: Prefer job-exec() to synchronousRun
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/#review36962 --- Ship it! Ship It! - Kevin Ottens On Aug. 2, 2013, 9:38 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/ --- (Updated Aug. 2, 2013, 9:38 a.m.) Review request for KDE Frameworks. Description --- Ports all uses of NetAccess::synchronousRun to KJob::exec() but one in khtml, but there it should be re-thought, the change is not straight-forward (XmlHttpRequest). Diffs - kfile/kdirselectdialog.cpp 68c4b93 kfile/kfilewidget.cpp 2fa1d28 kio/kio/paste.cpp c7c43e1 kio/tests/fileundomanagertest.cpp 5fe746f kio/tests/jobguitest.cpp 5a6c950 kio/tests/jobremotetest.cpp 5759b21 kio/tests/jobtest.cpp ceaf605 kio/tests/kdirmodeltest.cpp 8059fa8 staging/kunitconversion/src/kunitconversion/currency.cpp 8d18f633 Diff: http://git.reviewboard.kde.org/r/111841/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Ki18n mostly ready
[: David Faure :] There's no way to keep the [insertCatalog] method for source compatibility and implement it somehow on top of the new solution? The problem is that insertCatalog no longer has a meaning. Its purpose was to add more translation catalogs into the current process, and all of them would be searched for translation on a given i18n call. While in the new system, all i18n calls are bound to a particular catalog (either through TRANSLATION_DOMAIN define or setApplicationCatalog). I'm afraid of the porting effort created by all these source incompatible changes. If we can minimize that, it's all for the better. For porting, my focus was on the case where for each library/application there exists a different maintainer who will perform the update. In this case, it is not much effort: throw out any insertCatalog methods, replace with one TRANSLATION_DOMAIN define in private header (for libraries and applications) or one setApplicationCatalog call (easier alternative for applications). Of course, in reality there is sometimes no maintainer, or an incidental maintainer with piles of other things in the queue, and then porting becomes some effort. I'll help :) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111833: Remove small dependency between KGlobalSettings::naturalCompare and KDirSortFilterProxyModel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111833/ --- (Updated Aug. 2, 2013, 10:16 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Description --- Directly read the config instead of using KGlobalSettings as a proxy for the setting. We lose the setting changed functionality but now we don't depend on KGlobalSettings class. There's KDE_DEFAULT_* but I'll see how to do that in a different patch, there are other cases where it's needed. Diffs - KDE5PORTING.html 9d84525 kfile/kdirsortfilterproxymodel.cpp c8ea9b2 Diff: http://git.reviewboard.kde.org/r/111833/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111834: Move KHelpClient into xmlgui
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111834/#review36964 --- This review has been submitted with commit 0caf023573326992d1fcfe9dc5980d720209fe8f by Aleix Pol to branch frameworks. - Commit Hook On Aug. 1, 2013, 3:23 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111834/ --- (Updated Aug. 1, 2013, 3:23 p.m.) Review request for KDE Frameworks. Description --- The class still was in kdeui so it had to be moved, after discussing with ervin, it seemed like it's a good place for the function to be. After all, it's just a helper function, we can always (hope to) instantiate the help using QDesktopServices::openUrl() Diffs - kdeui/CMakeLists.txt 5cbcfb0 staging/xmlgui/src/CMakeLists.txt 255960f staging/xmlgui/src/khelpclient.h e5f9946 staging/xmlgui/src/khelpclient.cpp dda0b13 Diff: http://git.reviewboard.kde.org/r/111834/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111834: Move KHelpClient into xmlgui
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111834/ --- (Updated Aug. 2, 2013, 10:16 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Description --- The class still was in kdeui so it had to be moved, after discussing with ervin, it seemed like it's a good place for the function to be. After all, it's just a helper function, we can always (hope to) instantiate the help using QDesktopServices::openUrl() Diffs - kdeui/CMakeLists.txt 5cbcfb0 staging/xmlgui/src/CMakeLists.txt 255960f staging/xmlgui/src/khelpclient.h e5f9946 staging/xmlgui/src/khelpclient.cpp dda0b13 Diff: http://git.reviewboard.kde.org/r/111834/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111833: Remove small dependency between KGlobalSettings::naturalCompare and KDirSortFilterProxyModel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111833/#review36963 --- This review has been submitted with commit 09eecac88cc1c3e7bd525ec8c2eb50be30bfec1c by Aleix Pol to branch frameworks. - Commit Hook On Aug. 1, 2013, 11:03 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111833/ --- (Updated Aug. 1, 2013, 11:03 a.m.) Review request for KDE Frameworks. Description --- Directly read the config instead of using KGlobalSettings as a proxy for the setting. We lose the setting changed functionality but now we don't depend on KGlobalSettings class. There's KDE_DEFAULT_* but I'll see how to do that in a different patch, there are other cases where it's needed. Diffs - KDE5PORTING.html 9d84525 kfile/kdirsortfilterproxymodel.cpp c8ea9b2 Diff: http://git.reviewboard.kde.org/r/111833/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111841: Prefer job-exec() to synchronousRun
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/#review36965 --- This review has been submitted with commit a3df15c674a1f515645ee5a6fcedc298c5a47811 by Aleix Pol to branch frameworks. - Commit Hook On Aug. 2, 2013, 9:38 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/ --- (Updated Aug. 2, 2013, 9:38 a.m.) Review request for KDE Frameworks. Description --- Ports all uses of NetAccess::synchronousRun to KJob::exec() but one in khtml, but there it should be re-thought, the change is not straight-forward (XmlHttpRequest). Diffs - kfile/kdirselectdialog.cpp 68c4b93 kfile/kfilewidget.cpp 2fa1d28 kio/kio/paste.cpp c7c43e1 kio/tests/fileundomanagertest.cpp 5fe746f kio/tests/jobguitest.cpp 5a6c950 kio/tests/jobremotetest.cpp 5759b21 kio/tests/jobtest.cpp ceaf605 kio/tests/kdirmodeltest.cpp 8059fa8 staging/kunitconversion/src/kunitconversion/currency.cpp 8d18f633 Diff: http://git.reviewboard.kde.org/r/111841/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111841: Prefer job-exec() to synchronousRun
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111841/ --- (Updated Aug. 2, 2013, 10:18 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Description --- Ports all uses of NetAccess::synchronousRun to KJob::exec() but one in khtml, but there it should be re-thought, the change is not straight-forward (XmlHttpRequest). Diffs - kfile/kdirselectdialog.cpp 68c4b93 kfile/kfilewidget.cpp 2fa1d28 kio/kio/paste.cpp c7c43e1 kio/tests/fileundomanagertest.cpp 5fe746f kio/tests/jobguitest.cpp 5a6c950 kio/tests/jobremotetest.cpp 5759b21 kio/tests/jobtest.cpp ceaf605 kio/tests/kdirmodeltest.cpp 8059fa8 staging/kunitconversion/src/kunitconversion/currency.cpp 8d18f633 Diff: http://git.reviewboard.kde.org/r/111841/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_frameworks_qt5 #956
See http://build.kde.org/job/kdelibs_frameworks_qt5/956/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 111843: cut some kglobalsettings.h uses
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111843/ --- Review request for KDE Frameworks. Description --- Some uses of kglobalsettings.h was using some defines as a default value for some settings. This patch replaces those uses by the defined value. Diffs - kdeui/kernel/kstyle.cpp 7386e38 kfile/kdirsortfilterproxymodel.cpp 4f10852 khtml/khtml_settings.cpp a78a93b Diff: http://git.reviewboard.kde.org/r/111843/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111792: XCB event handling for KWindowSystem
On Aug. 2, 2013, 11:29 a.m., David Faure wrote: Looks good to me (I wrote the native-event-filter API in Qt5), thanks for killing KSystemEventFilter -- but please add a porting note to KDE5PORTING.html about that class. It's used outside kdelibs: http://lxr.kde.org/ident?i=KSystemEventFilter done - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/#review36961 --- On July 30, 2013, 10:34 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111792/ --- (Updated July 30, 2013, 10:34 a.m.) Review request for KDE Frameworks. Description --- Port KWindowSystemPrivate to QAbstractNativeEventFilter Obviously it's only filtering XCB events and the event filtering code is ported to use XCB data types. With this change the KSystemEventFilter is no longer needed and therefore dropped. Port NETWinInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib code by XCB equivalent. The logic of looped event compaction is dropped as inspecting the event queue is not possible on XCB. Port NETRootInfo::event from XEvent to xcb_generic_event_t Straight forward port just replacing the XLib functionality to XCB. The compaction logic got dropped as it was hard disabled anyway. Note: this change currently breaks KWindowSystem as it also needs to be ported. Coding style cleanup of event handling related methods Before adjusting the code let's have a proper coding style. Diffs - tier1/kwindowsystem/src/CMakeLists.txt PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter.cpp PRE-CREATION tier1/kwindowsystem/src/ksystemeventfilter_p.h PRE-CREATION tier1/kwindowsystem/src/kwindowsystem_x11.cpp PRE-CREATION tier1/kwindowsystem/src/netwm.h PRE-CREATION tier1/kwindowsystem/src/netwm.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111792/diff/ Testing --- Part of it indirectly tested through KWin on 5. Window caption gets updated and that is triggered through NETWinInfo, so I am positively optimistic that all of it works. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_stable #735
See http://build.kde.org/job/kdelibs_stable/735/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111844: Port last use of NetAccess in kio
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111844/#review36989 --- For testing I suppose one would need a webpage with a synchronous XmlHttpRequest. Dawit, do you have an example, based on when you wrote this code? (One could test by backporting the patch to kdelibs4...) BTW the next step in my kio splitup is to move this class, that's why I'm pushing for it to not use KIO::NetAccess anymore (so we can deprecate KIO::NetAcess altogether). staging/kio/src/widgets/accessmanager.cpp http://git.reviewboard.kde.org/r/111844/#comment27294 The class name could be improved, but let's see what's left after my other suggested changes... staging/kio/src/widgets/accessmanager.cpp http://git.reviewboard.kde.org/r/111844/#comment27293 Ah. Using KIO::storedGet instead of KIO::get would take care of this part already, the data collection. Same for http_post, there's a KIO::storedHttpPost for this. I think this would simplify the code. No need to connect to data() at all. Hmm, I see that this can even run a KIO::delete synchronously. So some casting will be needed to check if the job is a StoredTransferJob. staging/kio/src/widgets/accessmanager.cpp http://git.reviewboard.kde.org/r/111844/#comment27295 Hmm, so all we're missing is an accessor for the redirection url in some job classes? Maybe we could add that. ListJob has it, maybe we could move it up to SimpleJob. And then you wouldn't need this JobInfo at all, right? staging/kio/src/widgets/accessmanager.cpp http://git.reviewboard.kde.org/r/111844/#comment27292 Why not just create it on the stack? - David Faure On Aug. 2, 2013, 1:07 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111844/ --- (Updated Aug. 2, 2013, 1:07 p.m.) Review request for KDE Frameworks. Description --- Forgot to port this one, it was the complex one to change. Since it needs to gather some data, it uses a helper class that does so, for data and for the final url. Diffs - staging/kio/src/widgets/accessmanager.cpp 7120226 Diff: http://git.reviewboard.kde.org/r/111844/diff/ Testing --- I don't know if there's a test for the access manager... 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 111844: Port last use of NetAccess in kio
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111844/ --- (Updated Aug. 2, 2013, 2:13 p.m.) Review request for KDE Frameworks and Dawit Alemayehu. Changes --- Added Dawit Description --- Forgot to port this one, it was the complex one to change. Since it needs to gather some data, it uses a helper class that does so, for data and for the final url. Diffs - staging/kio/src/widgets/accessmanager.cpp 7120226 Diff: http://git.reviewboard.kde.org/r/111844/diff/ Testing --- I don't know if there's a test for the access manager... Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Ki18n mostly ready
El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure: On Thursday 01 August 2013 22:03:36 Albert Astals Cid wrote: El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure: Hello, On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote: [: Kevin Ottens :] What's needed for kconfig_compiler? Because currently kconfig isn't supposed to depend on ki18n at all. It does generate translation calls as necessary, and currently it accepts an option (from .kcfgc file) whether to generate tr or i18n calls. So another option to specify the translation domain would be added. OK, sounds good. We should make tr the default if that's not already the case though. Disagree. ki18n is our i18n framework. If something else that depends on kconfig_compiler wants to use the poor man's solution, it's up to them, but i don't see why we should force it by default to everyone. Well, the default has to make sense to someone who just makes a Qt application and use KConfig as an extra. If kconfig_compiler generates by default something which doesn't build for them we're doing something wrong. But as far as I remember we agreed we won't do the tr()-gettext(.mo) bridge either (since tr() code will just use .qm and i18n() code will just use .po) so if you default to tr() you break all the i18n() apps, no? Cheers, Albert Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: plasma-framework_master_qt5 #537
See http://build.kde.org/job/plasma-framework_master_qt5/537/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
frameworks and plasma partially link to wrong libs? ehh..
Hi, I followed the exact instructions from here: http://community.kde.org/Frameworks/Building my .bashrc looks like: export KF5=/home/kde-devel/kf5 export QTDIR=/home/kde-devel/qt5dev/qtbase export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg export PATH=$KF5/bin:$QTDIR/bin:$PATH export QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH export QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH Building Qt from the dev branch: all ok, no problem at all. Building frameworks: it compiles and probably because it doesn't need the wrong linked libs, but CMakeCache.txt includes the following: //The directory containing a CMake configuration file for Qt5OpenGL. Qt5OpenGL_DIR:PATH=/usr/lib64/cmake/Qt5OpenGL //The directory containing a CMake configuration file for Qt5PrintSupport. Qt5PrintSupport_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5PrintSupport //The directory containing a CMake configuration file for Qt5Qml. Qt5Qml_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Qml //The directory containing a CMake configuration file for Qt5Quick. Qt5Quick_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Quick //The directory containing a CMake configuration file for Qt5Script. Qt5Script_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Script //The directory containing a CMake configuration file for Qt5Sensors. Qt5Sensors_DIR:PATH=/usr/lib64/cmake/Qt5Sensors //The directory containing a CMake configuration file for Qt5Svg. Qt5Svg_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Svg //The directory containing a CMake configuration file for Qt5Test. Qt5Test_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Test //The directory containing a CMake configuration file for Qt5UiTools. Qt5UiTools_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5UiTools //The directory containing a CMake configuration file for Qt5WebKitWidgets. Qt5WebKitWidgets_DIR:PATH=/usr/lib64/cmake/Qt5WebKitWidgets //The directory containing a CMake configuration file for Qt5WebKit. Qt5WebKit_DIR:PATH=/usr/lib64/cmake/Qt5WebKit --- Note that Qt5OpenGL, Qt5Sensors and Qt5WebKit have the wrong path. It should start with(in my case): /home/kde-devel/qt5dev/qtbase/lib/cmake/module For frameworks this seems to compile just fine. I'm guessing frameworks never links to any of those libraries. However, for plasma the story is a bit different. It includes the following lines in CMakeCache.txt: //The directory containing a CMake configuration file for Qt5Network. Qt5Network_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Network //The directory containing a CMake configuration file for Qt5OpenGL. Qt5OpenGL_DIR:PATH=/usr/lib64/cmake/Qt5OpenGL //The directory containing a CMake configuration file for Qt5PrintSupport. Qt5PrintSupport_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5PrintSupport //The directory containing a CMake configuration file for Qt5Qml. Qt5Qml_DIR:PATH=/usr/lib64/cmake/Qt5Qml //The directory containing a CMake configuration file for Qt5Quick. Qt5Quick_DIR:PATH=/usr/lib64/cmake/Qt5Quick //The directory containing a CMake configuration file for Qt5ScriptTools. Qt5ScriptTools_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5ScriptTools //The directory containing a CMake configuration file for Qt5Script. Qt5Script_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Script //The directory containing a CMake configuration file for Qt5Sensors. Qt5Sensors_DIR:PATH=/usr/lib64/cmake/Qt5Sensors -- There Qt5Qml, Qt5Quick and Qt5Sensors are linked wrong where Qt5Qml and Qt5Quick are an issue. They cause the following linker errors: /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::V8::DisposeGlobal(v8::internal::Object**)' /usr/lib/libQt5Qml.so.5.1.0: undefined reference to `v8::V8::MakeWeak(v8::internal::Object**, void*, void (*)(v8::Persistentv8::Value, void*))' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::FunctionTemplate::New(v8::Handlev8::Value (*)(v8::Arguments const), v8::Handlev8::Value, v8::Handlev8::Signature)' /usr/lib/libQt5Qml.so.5.1.0: undefined reference to `v8::HeapProfiler::TakeSnapshot(v8::Handlev8::String, v8::HeapSnapshot::Type, v8::ActivityControl*)' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::V8::GlobalizeReference(v8::internal::Object**)' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::Object::CheckedGetInternalField(int)' Now manually correcting the paths for Qt5Qml and Qt5Quick works and makes plasma-shell (the one giving me the linker errors) compile just fine. I'm guessing that's not the intended way ;) Is this a known issue and do i need to update something to fix it? Note that i have the latest version of the KF5 chain since ~2 hours before this mail. That includes Extra CMake Modules where the last
Re: Ki18n mostly ready
On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote: El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure: Well, the default has to make sense to someone who just makes a Qt application and use KConfig as an extra. If kconfig_compiler generates by default something which doesn't build for them we're doing something wrong. But as far as I remember we agreed we won't do the tr()-gettext(.mo) bridge either (since tr() code will just use .qm and i18n() code will just use .po) so if you default to tr() you break all the i18n() apps, no? Apps which use both ki18n and kconfig shouldn't use the default but ask for i18n explicitely. It's really just about changing the default behavior to be ready for third parties who just pick one, but we still need to be able to override that for our own needs of course. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111701: Port away from kde_file in KDirOperator (KFile)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111701/#review37002 --- This review has been submitted with commit 5c674a9920c175fd1bef776788d0c826dba1803a by David Gil to branch frameworks. - Commit Hook On July 29, 2013, 9:22 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111701/ --- (Updated July 29, 2013, 9:22 p.m.) Review request for KDE Frameworks. Description --- Port away from kde_file in KDirOperator (KFile) REVIEW: 111701 Diffs - kfile/kdiroperator.cpp d4da9eb775fc8b3d2a8e035d82ebfb8d89b9aa5d Diff: http://git.reviewboard.kde.org/r/111701/diff/ Testing --- It builds. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 111701: Port away from kde_file in KDirOperator (KFile)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111701/ --- (Updated Aug. 2, 2013, 7:57 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Description --- Port away from kde_file in KDirOperator (KFile) REVIEW: 111701 Diffs - kfile/kdiroperator.cpp d4da9eb775fc8b3d2a8e035d82ebfb8d89b9aa5d Diff: http://git.reviewboard.kde.org/r/111701/diff/ Testing --- It builds. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: frameworks and plasma partially link to wrong libs? ehh..
On Fri, Aug 2, 2013 at 8:47 PM, Mark mark...@gmail.com wrote: Hi, I followed the exact instructions from here: http://community.kde.org/Frameworks/Building my .bashrc looks like: export KF5=/home/kde-devel/kf5 export QTDIR=/home/kde-devel/qt5dev/qtbase export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg export PATH=$KF5/bin:$QTDIR/bin:$PATH export QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH export QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH Building Qt from the dev branch: all ok, no problem at all. Building frameworks: it compiles and probably because it doesn't need the wrong linked libs, but CMakeCache.txt includes the following: //The directory containing a CMake configuration file for Qt5OpenGL. Qt5OpenGL_DIR:PATH=/usr/lib64/cmake/Qt5OpenGL //The directory containing a CMake configuration file for Qt5PrintSupport. Qt5PrintSupport_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5PrintSupport //The directory containing a CMake configuration file for Qt5Qml. Qt5Qml_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Qml //The directory containing a CMake configuration file for Qt5Quick. Qt5Quick_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Quick //The directory containing a CMake configuration file for Qt5Script. Qt5Script_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Script //The directory containing a CMake configuration file for Qt5Sensors. Qt5Sensors_DIR:PATH=/usr/lib64/cmake/Qt5Sensors //The directory containing a CMake configuration file for Qt5Svg. Qt5Svg_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Svg //The directory containing a CMake configuration file for Qt5Test. Qt5Test_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Test //The directory containing a CMake configuration file for Qt5UiTools. Qt5UiTools_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5UiTools //The directory containing a CMake configuration file for Qt5WebKitWidgets. Qt5WebKitWidgets_DIR:PATH=/usr/lib64/cmake/Qt5WebKitWidgets //The directory containing a CMake configuration file for Qt5WebKit. Qt5WebKit_DIR:PATH=/usr/lib64/cmake/Qt5WebKit --- Note that Qt5OpenGL, Qt5Sensors and Qt5WebKit have the wrong path. It should start with(in my case): /home/kde-devel/qt5dev/qtbase/lib/cmake/module For frameworks this seems to compile just fine. I'm guessing frameworks never links to any of those libraries. However, for plasma the story is a bit different. It includes the following lines in CMakeCache.txt: //The directory containing a CMake configuration file for Qt5Network. Qt5Network_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Network //The directory containing a CMake configuration file for Qt5OpenGL. Qt5OpenGL_DIR:PATH=/usr/lib64/cmake/Qt5OpenGL //The directory containing a CMake configuration file for Qt5PrintSupport. Qt5PrintSupport_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5PrintSupport //The directory containing a CMake configuration file for Qt5Qml. Qt5Qml_DIR:PATH=/usr/lib64/cmake/Qt5Qml //The directory containing a CMake configuration file for Qt5Quick. Qt5Quick_DIR:PATH=/usr/lib64/cmake/Qt5Quick //The directory containing a CMake configuration file for Qt5ScriptTools. Qt5ScriptTools_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5ScriptTools //The directory containing a CMake configuration file for Qt5Script. Qt5Script_DIR:PATH=/home/kde-devel/qt5dev/qtbase/lib/cmake/Qt5Script //The directory containing a CMake configuration file for Qt5Sensors. Qt5Sensors_DIR:PATH=/usr/lib64/cmake/Qt5Sensors -- There Qt5Qml, Qt5Quick and Qt5Sensors are linked wrong where Qt5Qml and Qt5Quick are an issue. They cause the following linker errors: /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::V8::DisposeGlobal(v8::internal::Object**)' /usr/lib/libQt5Qml.so.5.1.0: undefined reference to `v8::V8::MakeWeak(v8::internal::Object**, void*, void (*)(v8::Persistentv8::Value, void*))' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::FunctionTemplate::New(v8::Handlev8::Value (*)(v8::Arguments const), v8::Handlev8::Value, v8::Handlev8::Signature)' /usr/lib/libQt5Qml.so.5.1.0: undefined reference to `v8::HeapProfiler::TakeSnapshot(v8::Handlev8::String, v8::HeapSnapshot::Type, v8::ActivityControl*)' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::V8::GlobalizeReference(v8::internal::Object**)' /usr/lib/libQt5Quick.so.5.1.0: undefined reference to `v8::Object::CheckedGetInternalField(int)' Now manually correcting the paths for Qt5Qml and Qt5Quick works and makes plasma-shell (the one giving me the linker errors) compile just fine. I'm guessing that's not the intended way ;) Is this a known issue and do i need to update something
