Re: Jenkins build is back to stable : kdelibs_frameworks_qt5 #1386
On Wednesday 09 October 2013 06:22:55 KDE CI System wrote: See http://build.kde.org/job/kdelibs_frameworks_qt5/1386/changes \o/ Let's keep kdelibs-frameworks and plasma-framework green now, shall we? Note however that I still have a pesky issue with kded5 getting stuck, but build.kde.org seems unaffected. So don't label me as a happy camper just yet. 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
Jenkins build became unstable: kdelibs_stable #854
See http://build.kde.org/job/kdelibs_stable/854/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112880: Added KColorSchemeToken class.
On Oct. 1, 2013, 2:47 p.m., Sebastian Kügler wrote: kdeui/colors/kcolorschemetoken.h, line 70 http://git.reviewboard.kde.org/r/112880/diff/6/?file=192050#file192050line70 using int here loses the type-safety. Why no use the corresponding enums? It would also make the code more readable. (Same issue for all the other methods.) Denis Kuplyakov wrote: I have tried it, but have such errors: Error: Unknown method parameter type: QPalette::ColorGroup See this: http://qt-project.org/forums/viewthread/10308/ . It seems that the int is only way to make it works correct. Sebastian Kügler wrote: Have you tried registering that enum using qmlRegisterType? Yes, I have, but 0 is always go to function. Have you read the link above, such behaviour was described there. - Denis --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review41068 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113181: Add KDebug porting notes to KDE5PORTING.html
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html 3171afc Diff: http://git.reviewboard.kde.org/r/113181/diff/ Testing --- 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 113181: Add KDebug porting notes to KDE5PORTING.html
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/#review41430 --- Hi Martin, Your notes might not hold anymore. A month ago they would have been fine, but now we also have the Categorized debugging in Qt. The qCDebug,Notice,Warning, ... macros: http://doc-snapshot.qt-project.org/qt5-stable/qloggingcategory.html What are we - KDE devs - going to use now? just the qDebug, Notice, Warning macros or the categorized versions? I will bring this up on k-f-d as well since i think more people will have the same question as i just asked. - Mark Gaiser On Oct. 9, 2013, 12:59 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/ --- (Updated Oct. 9, 2013, 12:59 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html 3171afc Diff: http://git.reviewboard.kde.org/r/113181/diff/ Testing --- Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Categorized logging in KDE?
Hi, As you all probably know by now, Qt has included of categorized logging [1] as of 5.2. In KDE we've had categorized logging for ages, but while porting to Frameworks we started using the simple Qt logging qDebug, Notice and Warning. However, we now again have categorized logging from within Qt. That makes me wonder, do we still need to port back to qDebug, Notice and Warning or are we now going to use the categorized versions: qCDebug, Notice and Warning? Cheers, Mark [1] http://doc-snapshot.qt-project.org/qt5-stable/qloggingcategory.html ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113181: Add KDebug porting notes to KDE5PORTING.html
On Oct. 9, 2013, 1:21 p.m., Mark Gaiser wrote: Hi Martin, Your notes might not hold anymore. A month ago they would have been fine, but now we also have the Categorized debugging in Qt. The qCDebug,Notice,Warning, ... macros: http://doc-snapshot.qt-project.org/qt5-stable/qloggingcategory.html What are we - KDE devs - going to use now? just the qDebug, Notice, Warning macros or the categorized versions? I will bring this up on k-f-d as well since i think more people will have the same question as i just asked. Ah, that's great! I didn't know about it, I was told to drop the categories, but this looks neat. Thanks for bringing that up - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/#review41430 --- On Oct. 9, 2013, 12:59 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/ --- (Updated Oct. 9, 2013, 12:59 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html 3171afc Diff: http://git.reviewboard.kde.org/r/113181/diff/ Testing --- 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 113174: Cleanup KJsEmbed
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113174/#review41435 --- kjsembed/examples/kjsconsole/numberedtextview.cpp http://git.reviewboard.kde.org/r/113174/#comment30310 why not just do width(QString(1032)) or maybe this was originally meant to be fontMetrics().width(QString()) + 10 + 32; ? kjsembed/kjscmd/kjscmd.cpp http://git.reviewboard.kde.org/r/113174/#comment30311 this seems to break whitespace for no reason? staging/kjsembed/CMakeLists.txt http://git.reviewboard.kde.org/r/113174/#comment30312 It may be better to do if (not Qt5UiTools) return endif so you don't install all the Config.cmake files etc. on something that didn't actually build. (see a change stervie did in khtml) - David Edmundson On Oct. 8, 2013, 2:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113174/ --- (Updated Oct. 8, 2013, 2:09 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adopt directory organization, naming scheme, cmake structures, documents dependencies. Diffs - CMakeLists.txt 368584e kjsembed/AUTHORS kjsembed/CMakeLists.txt 6cb6727 kjsembed/Mainpage.dox kjsembed/examples/calc/calc.js kjsembed/examples/calc/calc.ui kjsembed/examples/console/console.js kjsembed/examples/console/console.ui kjsembed/examples/docviewer/docviewer.js kjsembed/examples/docviewer/docviewer.ui kjsembed/examples/fancy/fancy.js kjsembed/examples/grammar/grammar.js kjsembed/examples/kjsconsole/CMakeLists.txt d06f27b kjsembed/examples/kjsconsole/console.h kjsembed/examples/kjsconsole/console.cpp f65f39b kjsembed/examples/kjsconsole/console.qrc kjsembed/examples/kjsconsole/images/bug.png kjsembed/examples/kjsconsole/images/class.png kjsembed/examples/kjsconsole/images/constant.png kjsembed/examples/kjsconsole/images/method.png kjsembed/examples/kjsconsole/images/next.png kjsembed/examples/kjsconsole/images/no.png kjsembed/examples/kjsconsole/images/property.png kjsembed/examples/kjsconsole/images/runto.png kjsembed/examples/kjsconsole/images/start.png kjsembed/examples/kjsconsole/images/step.png kjsembed/examples/kjsconsole/images/stop.png kjsembed/examples/kjsconsole/jsconsole.ui kjsembed/examples/kjsconsole/kjs_object_model.h kjsembed/examples/kjsconsole/kjs_object_model.cpp kjsembed/examples/kjsconsole/main.cpp kjsembed/examples/kjsconsole/numberedtextview.h kjsembed/examples/kjsconsole/numberedtextview.cpp f144502 kjsembed/examples/scribble/scribble.js kjsembed/examples/tests/args.js kjsembed/examples/tests/brush.js kjsembed/examples/tests/builtins.js kjsembed/examples/tests/class.js kjsembed/examples/tests/colortest.js kjsembed/examples/tests/conio.js kjsembed/examples/tests/domtest.js kjsembed/examples/tests/events.js kjsembed/examples/tests/fileio.js kjsembed/examples/tests/fonttest.js kjsembed/examples/tests/frame.js kjsembed/examples/tests/gc.js kjsembed/examples/tests/include.js kjsembed/examples/tests/inner.js kjsembed/examples/tests/jsslot.js kjsembed/examples/tests/layout.js kjsembed/examples/tests/library.js kjsembed/examples/tests/listproperties.js kjsembed/examples/tests/matt.js kjsembed/examples/tests/paintertest.js kjsembed/examples/tests/paintevent.js kjsembed/examples/tests/pixmap.js kjsembed/examples/tests/recttest.js kjsembed/examples/tests/settings.js kjsembed/examples/tests/signslots.js kjsembed/examples/tests/statictest.js kjsembed/examples/tests/stylesheet.js kjsembed/examples/tests/svgtest.js kjsembed/examples/tests/system.js kjsembed/examples/tests/test.svg kjsembed/examples/tests/test.ui kjsembed/examples/tests/typecheck.js kjsembed/examples/tests/uitest.js kjsembed/examples/tests/uitest2.js kjsembed/examples/tests/url.js kjsembed/examples/tests/widgettest.js kjsembed/kjscmd/CMakeLists.txt eeb5667 kjsembed/kjscmd/console.js kjsembed/kjscmd/kjscmd.cpp df833db kjsembed/kjscmd/kjscmd.qrc kjsembed/kjsembed/CMakeLists.txt 8089c4b kjsembed/kjsembed/QBrush_bind.h kjsembed/kjsembed/QBrush_bind.cpp kjsembed/kjsembed/application.h kjsembed/kjsembed/application.cpp kjsembed/kjsembed/binding_support.h kjsembed/kjsembed/binding_support.cpp kjsembed/kjsembed/brush.h kjsembed/kjsembed/brush.cpp
Re: Review Request 113173: Reduce warnings noise when including wtf/Platform.h in KJS
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113173/#review41436 --- It makes sense to me. I would like someone else to approve. - David Edmundson On Oct. 8, 2013, 1:20 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113173/ --- (Updated Oct. 8, 2013, 1:20 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Modifies how features are checked. This file has some pre-processor macros that are used to checking for OS features. These are defined with 1 if acceptable and undefined if the feature is not present. These macros are being checked with #if, so the pre-processor will complain whenever it's asked about one of the variables that haven't been defined. This patch adds a defined() first, before checking the value, so the pre-processor doesn't need to consider the variable value, if it's not present. This change makes it possible to read the compilation logs from modules that use KJS. Diffs - tier1/kjs/src/wtf/Platform.h 843cfd2 Diff: http://git.reviewboard.kde.org/r/113173/diff/ Testing --- Builds, KJS tests pass. 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 112367: Include the icon's theme in the cache key
On Aug. 31, 2013, 7:11 a.m., David Faure wrote: I disagree. Making things slow to cover a really really corner case (mixing kde4 and kde5), while the solution already exists (clearing the cache when switching icon themes), doesn't seem very sensible to me. The point is really that you can only use one icon theme at a time. Àlex Fiestas wrote: While it is a corner case I think we should find a solution to make this more solid. Perhaps we could set the theme name in the cache, and then check if it has changed, if so remove cache. What is a bug imho is that theme can be changed without the cache getting cleaned somehow, corner case if you want but a bug. David Faure wrote: There's a *lot* of things that break if you run two separate DBus sessions and do things in one session and expect the other session to react. IMHO it's actually a feature that this isn't the case ;) But indeed we get into bugs when we have such broken dbus communication because of using two sessions, but these two sessions share some files, e.g. config files. Because then they see the changed files at some point, but didn't get change notification. However fixing all such occurences is a HUGE amount of work, and it's not worth it IMHO. But first, am I right that this is the case you're having? Different dbus sessions between your kde4 and kde5 code, but shared config files? (or symlinks, if the chosen icon theme is a symlink - I forgot how that works exactly) Àlex Fiestas wrote: I think it is much simpler than that: -Theme is changed but cache is not nuked, we get wrong icons. My case is, KIconLoader should realize that the theme has changed and nuke it without any external help. What is happening is, that KSharedDataCache::deleteCache(icon-cache); is removing the cache from KDE4 (in /tmp/... I guess) instead of using the new standard paths which is what it should do. Kevin Ottens wrote: Are you sure about that? It uses QStandardPaths internally... Any news about that patch? Is it still an issue? Is it abandoned? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112367/#review38986 --- On Aug. 29, 2013, 8 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112367/ --- (Updated Aug. 29, 2013, 8 p.m.) Review request for KDE Frameworks, kdelibs and Michael Pyne. Repository: kdelibs Description --- If we make no difference between an icon from oxygen and an icon from gnome, when we change themes for example from oxygen to gnome, the icon will be found in the cache and won't be upgraded. Diffs - kdeui/icons/kiconloader.cpp ce6aeea Diff: http://git.reviewboard.kde.org/r/112367/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: 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/#review41439 --- Any news about that patch? It hasn't seen activity lately. - Kevin Ottens On Sept. 17, 2013, 5:42 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112755/ --- (Updated Sept. 17, 2013, 5:42 a.m.) Review request for KDE Frameworks. 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 - tier1/kwindowsystem/src/kxutils.cpp 33bd678 tier1/kwindowsystem/src/kxutils_p.h 84d639b 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 112918: Add index argument to KWidgetItemDelegate::createItemWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112918/#review41441 --- Ship it! OK, that's a small SIC... but OK, we don't have that many users of that class anyway and it's easy to port. - Kevin Ottens On Sept. 24, 2013, 2:33 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112918/ --- (Updated Sept. 24, 2013, 2:33 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add index argument to KWidgetItemDelegate::createItemWidgets This fixes a KDE5 TODO which used to pass an argument as a property Diffs - staging/kcmutils/src/kpluginselector.cpp 77cbfda5987195f15341e41c3280726e5583d87e KDE5PORTING.html 57ecf2e007e270b634cc8d16462b73e96553c92d staging/kcmutils/src/kpluginselector_p.h 2dffae05dd87cc299ecdb05612f02dd2ad37cd2c staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.h 0e325915070006d2cfa093719d5c967f3181737d staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.cpp 84f9ca548068088c0bc0ff99fa460e5f7fecbccd tier1/itemviews/src/kwidgetitemdelegate.h b874c10e9a7ab9ee9bf756ae82ce99bd64ec92d1 tier1/itemviews/src/kwidgetitemdelegatepool.cpp e9bbcad0b030c8d03fadeb6635bfa0d69d996ac9 tier1/itemviews/tests/kwidgetitemdelegatetest.cpp cfca1f9ae3df9bec1e8a570f03b5256cc935e8bb Diff: http://git.reviewboard.kde.org/r/112918/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Is this patch abandoned or it'll see another revision soon? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 7:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in 18b6e2f tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112785/diff/ Testing --- Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112896: Rework NETWM classes
On Sept. 26, 2013, 2:27 a.m., Fredrik Höglund wrote: I'm just going to point out something I know you already know since we've discussed it many times; that an xcb port of the NETWM classes already exists in a branch. Martin Gräßlin wrote: my aim was to write the unit test and that was the big junk of this work compared to the xcb changes (which I thought to be easier than trying to rebase the branch :-( ) Fredrik Höglund wrote: The problem with rebasing the branch was solved a long time ago. There shouldn't be any conflicts except maybe in CMakeLists.txt files. Martin Gräßlin wrote: ah, I didn't know that. I will have a look and see whether I can integrate the unit tests and the bug fixes on top of your branch. Any news about that patch? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112896/#review40840 --- On Sept. 23, 2013, 1:11 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112896/ --- (Updated Sept. 23, 2013, 1:11 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- This is a patch series, if needed I can push the branch. The patches address the following topics: * add unit tests for NETRootInfo and NETWinInfo which do not require a running window manager. Test coverage of netwm.h is: ** line coverage: 75 % ** functions coverage: 84 % ** branch coverage: 62 % The tests start their own Xvfb to have a clean state and not mess up with the Window Manager of a user or cause followint tests to fail on the CI system * areas which are covered by unit tests are changed from XLib to XCB. This mostly affects changing and reading window properties * API is changed from XLib types to XCB types. E.g. xcb_window_t instead of Window. Note: this is an API break, which I consider as necessary, given that especially the type Window is problematic. * several bugs which were discovered through the added tests are fixed * NETWinInfo2 is merged into NETWinInfo (marked as TODO KDE5) * Small wrapper class for intern atom added to KXUtils. Similar code already in usage in KWin. = Commits: commit 2e50845a5d0df436106aeb776e3936691c32a753 Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 14:31:42 2013 +0200 Use XCB for reading properties in NETRootInfo::update Viewport handling was incorrect and is adjusted to be read correctly. commit 23887726c03c49b4e0021c01f319653d3b9f36c5 Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 11:41:26 2013 +0200 Use XCB for reading properties in NETWinInfo::update Those areas which are covered by unit tests are migrated from XGetWindowProperty to the xcb variant. BlocksCompositing had an incorrect read - it expected a string atom, but actually uses a cardinal. This bug is fixed. commit 2731ebbc85eddb885700232f98e0e429cb0e066b Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 09:41:28 2013 +0200 Use XCB to change the Client dependent properties of NETWinInfo Those properties for which we have unit tests are changed to XCB to either change or delete the property. commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a Author: Martin Gräßlin mgraess...@kde.org Date: Fri Sep 20 09:58:09 2013 +0200 Unit test for Client aspect of NETWinInfo Similar to the NETWinInfo test with WindowManager aspect, just verifying the properties which can only be set by a Client. The test found highlights a few possible problems: * for some window types a fallback type is specified, but the lenght is set to 1, thus the fallback type is not set at all * Fullscreen monitors property is not handled in the event function commit 2731ebbc85eddb885700232f98e0e429cb0e066b Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 09:41:28 2013 +0200 Use XCB to change the Client dependent properties of NETWinInfo Those properties for which we have unit tests are changed to XCB to either change or delete the property. commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a Author: Martin Gräßlin mgraess...@kde.org Date: Fri Sep 20 09:58:09 2013 +0200 Unit test for Client aspect of NETWinInfo Similar to the NETWinInfo test with WindowManager aspect, just verifying the properties which can only be set by a Client. The test found highlights a few possible problems: * for some window types a fallback type is specified, but the lenght is set to 1, thus the fallback type is not set
Re: Review Request 112913: Move KModifierKeyInfo from GuiAddons to KWindowSystem
On Sept. 29, 2013, 4:38 p.m., David Faure wrote: -1, see https://git.reviewboard.kde.org/r/112443/ Well... See Nicolas comment there, even the API is tied to the way X works. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112913/#review41004 --- On Sept. 24, 2013, 8:15 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112913/ --- (Updated Sept. 24, 2013, 8:15 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- As discussed in https://git.reviewboard.kde.org/r/112443/ It's quite windowing system specific and only implemented for X11 so it makes more sense in the framework which is about the windowing system specific code. Diffs - tier1/kguiaddons/src/lib/CMakeLists.txt dc6aafa tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.h a5b1785 tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.cpp 7068d6f tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider.cpp 696c577 tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_dummy.cpp 7913d29 tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_p.h ee8e82e tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_x11.cpp 2f28d41 tier1/kguiaddons/tests/CMakeLists.txt 4d91ed8 tier1/kguiaddons/tests/kmodifierkeyinfotest.cpp 39984a0 tier1/kwindowsystem/src/CMakeLists.txt 31fb53e tier1/kwindowsystem/src/kmodifierkeyinfo.h PRE-CREATION tier1/kwindowsystem/src/kmodifierkeyinfo.cpp PRE-CREATION tier1/kwindowsystem/src/kmodifierkeyinfoprovider.cpp PRE-CREATION tier1/kwindowsystem/src/kmodifierkeyinfoprovider_dummy.cpp PRE-CREATION tier1/kwindowsystem/src/kmodifierkeyinfoprovider_p.h PRE-CREATION tier1/kwindowsystem/src/kmodifierkeyinfoprovider_x11.cpp PRE-CREATION tier1/kwindowsystem/tests/CMakeLists.txt 5cf5868 tier1/kwindowsystem/tests/kmodifierkeyinfotest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112913/diff/ Testing --- compiled 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 112929: Remove KPluginVerificationData
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112929/ --- (Updated Oct. 9, 2013, 4:49 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Remove KPluginVerificationData This only ever checked against major KDE version, so it's not that useful. As we'll install into different subdirectories anyway, we can get rid of it. Diffs - staging/kservice/src/plugin/kexportplugin.h 216923e staging/kservice/src/plugin/kpluginloader.cpp 91a3857 Diff: http://git.reviewboard.kde.org/r/112929/diff/ Testing --- It builds, the warning is gone. 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 112443: Native event filter porting for KModifierKeyInfoProvider
On Sept. 23, 2013, 10:07 a.m., Kevin Ottens wrote: Tested the patch in my tree, works for caps lock too. Now it highlights a dependency problem... We don't want a dependency on QX11Extras from KGuiAddons. So maybe we should move KModifierKeyInfo to your proposed KX11Extras? Martin Gräßlin wrote: Then I would suggest to move this class to KWindowSystem for the moment. For the module KX11Extras I still need some code changes first (for some reason netwm is using KWindowSystem - it's wrong IMHO and needs fixing) Kevin Ottens wrote: Well, if you remember it was my first choice to put KModifierKeyInfo in KWindowSystem, but you pushed back. :-) I'm ok if you move it there then, looking forward to the patches. ;-) David Faure wrote: You know, if the dependency on QX11Extras is only for QX11Info::display(), that's really easy to write by hand in kmodifierkeyinfo_x11.cpp (see the 5 lines in QX11Info::display). Although I suspect after porting to XCB it would rather be about QX11Info::connection(), same thing though (accessible via QPlatformNativeInterface). QX11Info mostly exists for Qt4 source compat and for convenience, it's not mandatory to go through it. I'm not convinced about this going to KWindowSystem. An application developer who would want to display a Caps Lock indicator in the statusbar of his wordprocessor (say kile, which does exactly this) would first look at Qt, then notice you can't query it for the status of CapsLock, and would then look at kguiaddons and find it. But why would they look into KWindowSystem for this? This has nothing to do with window management. It's a key handling feature, complementing what's in QtGui. I certainly expect it to be implemented on Windows and/or Mac at some point in the future, it definitely makes sense there too (unlike, say, NETWM). Martin Gräßlin wrote: Ok, I can see how to get away from QX11Extras, but Kevin also complained about XLib and XCB. And I do not see how I can interact with X11 without using either of those two. So either I'm allowed to use X-specific code in this module or the code cannot go into this module. XCB is less of an issue if that's an optional dependency. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112443/#review40510 --- On Sept. 4, 2013, 6:37 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112443/ --- (Updated Sept. 4, 2013, 6:37 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Ported to native event filter and to xcb-xkb by reimplementing the events. Most parts are kept on xlib though as we don't have xkb.h to get proper defines. Diffs - tier1/kguiaddons/CMakeLists.txt 3124c4d tier1/kguiaddons/src/lib/CMakeLists.txt dc6aafa tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_dummy.cpp 7913d29 tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_p.h ee8e82e tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_x11.cpp 2f28d41 Diff: http://git.reviewboard.kde.org/r/112443/diff/ Testing --- used kmodifierkeyinfotest application. Would appreciate if someone else could run it as I don't have a caps lock. 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 113050: Use enum for KMessageBox return types
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113050/#review41448 --- Ship it! Ship It! - Kevin Ottens On Oct. 2, 2013, 2:43 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113050/ --- (Updated Oct. 2, 2013, 2:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Use enum for KMessageBox return types instead of int. Diffs - staging/kde4support/src/kdeui/kmessagebox_queued.cpp 00e9eb0 tier1/kwidgetsaddons/src/kmessagebox.h 4d1306b tier1/kwidgetsaddons/src/kmessagebox.cpp d974cd6 Diff: http://git.reviewboard.kde.org/r/113050/diff/ Testing --- Builds, tests pass. 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 112797: Bring back KStringHandler::naturalCompare()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112797/#review41449 --- Ship it! Ship It! - Kevin Ottens On Oct. 4, 2013, 5:26 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112797/ --- (Updated Oct. 4, 2013, 5:26 p.m.) Review request for KDE Frameworks, Frank Reininghaus and Mark Gaiser. Repository: kdelibs Description --- Apparently there's people who still want to have it. Leave it in KCoreAddons for the moment, until we decide that it can be replaced for good by QCollator. Diffs - KDE5PORTING.html 88700b0 staging/kde4support/autotests/CMakeLists.txt 473bdba staging/kde4support/autotests/naturalcomparetest.cpp PRE-CREATION staging/kde4support/src/CMakeLists.txt 51519a3 staging/kde4support/src/kdecore/kstringhandler_deprecated.h PRE-CREATION staging/kde4support/src/kdecore/kstringhandler_deprecated.cpp PRE-CREATION tier1/kcoreaddons/autotests/kstringhandlertest.cpp 93da351 tier1/kcoreaddons/src/lib/text/kstringhandler.h 442b97a tier1/kcoreaddons/src/lib/text/kstringhandler.cpp ea3bbf5 Diff: http://git.reviewboard.kde.org/r/112797/diff/ Testing --- Builds, tests pass. 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 112985: Adjust API in KEmoticons framework: map and index methods
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112985/#review41450 --- I'm not sure what this patch is trying to achieve. It doesn't look much more clearer API to me than what we had before. :-) Could you share a bit more of the rationale? I guess I'm missing something. - Kevin Ottens On Oct. 6, 2013, 9:02 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112985/ --- (Updated Oct. 6, 2013, 9:02 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: map and index methods -Make map and index KEmoticons API slightly clearer and deprecate the methods that are confusing. -Use the new methods in the plugins. Diffs - staging/kemoticons/src/core/kemoticonsprovider.h 85fc7efb8923d76476f0a16f70f8ebb15e451081 staging/kemoticons/src/core/kemoticonsprovider.cpp d04c76e87b118f5d45717b3b2ccd9dea47dc2526 staging/kemoticons/src/providers/adium/adium_emoticons.cpp a3aaa0fdc0b3dcc862f98865d2e6419e716f4f17 staging/kemoticons/src/providers/kde/kde_emoticons.cpp 5b5114a14dd94a6ebcba8a6f7dd163f73048189a staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp e9f89eecce3d6e6407113a84cb5200ff66564c19 staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 0dc92ed092d87a559fe7fa1a40e804843ab73d59 Diff: http://git.reviewboard.kde.org/r/112985/diff/ Testing --- It builds. It installs. 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
Re: Review Request 113179: Make the runners compile again
On Oct. 8, 2013, 9:15 p.m., Aleix Pol Gonzalez wrote:
There's also runner-related code in
src/declarativeimports/{core,runnermodel}, these should be reenabled as
well. Possibly, they also need changes to make built. I had disabled this
after a discussion with Aaron (who has refactored these classes) and
Vishesh, who plans to work on them. I'm not sure what's the most useful, I
can imagine this leading to a lot of conflicts when merging this
refactoring, while the benefits of this patch are then just going away.
Aaron can weigh in here to say what's easiest moving forward. Mirko is the
best person to review the ThreadWeaver API changes you implement. Could you
add him to the reviewers for this request?
thanks...
Aleix Pol Gonzalez wrote:
Well, the only reason I did this was because kickoff in kde-workspace
requires runners as well. If those are not good anymore, maybe it's wiser to
disable them there as well?
Sebastian Kügler wrote:
Ah, I've missed these. I was operating under the assumption that nobody
would use runners in Plasma2 yet -- wrong. We can do both, disable runners in
kickoff or merge this. Let's hear others' opinions.
It overall looks fine to me. We'd need someone with a more intimate knowledge
of krunner to look at it though.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113179/#review41412
---
On Oct. 8, 2013, 5:14 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113179/
---
(Updated Oct. 8, 2013, 5:14 p.m.)
Review request for KDE Frameworks and Plasma.
Repository: plasma-framework
Description
---
Recently there's been some big changes in the ThreadWeaver API. So big that
they break the source compatibility we were supposed to maintain, big time.
This patch tries to port plasma-framework to that new API.
Diffs
-
src/plasma/CMakeLists.txt 411256a
src/plasma/private/runnerjobs.cpp d11f7e9
src/plasma/private/runnerjobs_p.h 7fd7076
src/plasma/private/storage.cpp 35b222e
src/plasma/runnermanager.cpp 135279e
src/plasma/scripting/runnerscript.cpp d5142a2
Diff: http://git.reviewboard.kde.org/r/113179/diff/
Testing
---
Everything builds, including kde-workspace.
Couldn't test it, there's no tests for it or even an application to test it
:/.
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 112880: Added KColorSchemeToken class.
On Oct. 1, 2013, 2:47 p.m., Sebastian Kügler wrote: kdeui/colors/kcolorschemetoken.h, line 70 http://git.reviewboard.kde.org/r/112880/diff/6/?file=192050#file192050line70 using int here loses the type-safety. Why no use the corresponding enums? It would also make the code more readable. (Same issue for all the other methods.) Denis Kuplyakov wrote: I have tried it, but have such errors: Error: Unknown method parameter type: QPalette::ColorGroup See this: http://qt-project.org/forums/viewthread/10308/ . It seems that the int is only way to make it works correct. Sebastian Kügler wrote: Have you tried registering that enum using qmlRegisterType? Denis Kuplyakov wrote: Yes, I have, but 0 is always go to function. Have you read the link above, such behaviour was described there. Likely missing a Q_ENUMS somewhere to get that to work. You might want to roll your own enum type and map it to QPalette::* internally. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review41068 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112880: Added KColorSchemeToken class.
On Sept. 24, 2013, 6:55 a.m., Kevin Ottens wrote: I'm not sure we can let that in for kdelibs 4.x / kdeui... David? Any opinion? If we ignore that point for the moment, and think in terms of KF5, ATM it would go with KColorScheme in KConfigWidgets. I'm not quite sold on the Token name though. It comes from the fact that it attempts to be the QML API but provided as a C++ API, shouldn't it be in a declarative import plugin with no C++ API? That'd put less pressure on the class name. I still don't like having that in kdeui... What about kdeclarative instead? Not sure the dependencies are acceptable for it though. I'd say let's land it there first and then we'll see. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40635 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113181: Add KDebug porting notes to KDE5PORTING.html
On Oct. 9, 2013, 1:21 p.m., Mark Gaiser wrote: Hi Martin, Your notes might not hold anymore. A month ago they would have been fine, but now we also have the Categorized debugging in Qt. The qCDebug,Notice,Warning, ... macros: http://doc-snapshot.qt-project.org/qt5-stable/qloggingcategory.html What are we - KDE devs - going to use now? just the qDebug, Notice, Warning macros or the categorized versions? I will bring this up on k-f-d as well since i think more people will have the same question as i just asked. Martin Klapetek wrote: Ah, that's great! I didn't know about it, I was told to drop the categories, but this looks neat. Thanks for bringing that up Yep, we have the category feature now... So it's the right time to evaluate it properly as part of the porting notes. We also have to check qC*() against the old features of kDebug() like enabling/disabling an area without recompiling. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/#review41430 --- On Oct. 9, 2013, 12:59 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/ --- (Updated Oct. 9, 2013, 12:59 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html 3171afc Diff: http://git.reviewboard.kde.org/r/113181/diff/ Testing --- 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 112880: Added KColorSchemeToken class.
On Oct. 1, 2013, 2:47 p.m., Sebastian Kügler wrote: kdeui/colors/kcolorschemetoken.h, line 70 http://git.reviewboard.kde.org/r/112880/diff/6/?file=192050#file192050line70 using int here loses the type-safety. Why no use the corresponding enums? It would also make the code more readable. (Same issue for all the other methods.) Denis Kuplyakov wrote: I have tried it, but have such errors: Error: Unknown method parameter type: QPalette::ColorGroup See this: http://qt-project.org/forums/viewthread/10308/ . It seems that the int is only way to make it works correct. Sebastian Kügler wrote: Have you tried registering that enum using qmlRegisterType? Denis Kuplyakov wrote: Yes, I have, but 0 is always go to function. Have you read the link above, such behaviour was described there. Kevin Ottens wrote: Likely missing a Q_ENUMS somewhere to get that to work. You might want to roll your own enum type and map it to QPalette::* internally. If there are no Q_ENUMS it will not work as it is now. You can see QPalette source and it has it. - Denis --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review41068 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112932: Update superbuild to include all tiered libraries
On Wednesday 09 October 2013, Kevin Ottens wrote: On Sept. 25, 2013, 2:03 p.m., Aleix Pol Gonzalez wrote: Looks good to me, not adding the shipit because I'm clueless about superbuild. Why do we need to specify the dependencies from superbuild? Shouldn't they depend on the Config.cmake files? Alexander Neundorf wrote: You mean after DEPENDS ? Because the superbuild CMakeLists.txt has no information otherwise which sub-builds depend on which other sub-builds, so this information must be there to make sure e.g. tier1 libs are built before tier2 libs etc. It looks fine to me too... but I'm rather clueless about superbuild. Alexander any chance you could take a look and push ship it if you see no problem with that one? I don't maintain it anymore, so I don't ship it, but I also don't object. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113174: Cleanup KJsEmbed
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113174/#review41456 --- kjsembed/examples/kjsconsole/console.cpp http://git.reviewboard.kde.org/r/113174/#comment30317 Hm actually surprising, where does this include come from? kjsembed/kjscmd/kjscmd.cpp http://git.reviewboard.kde.org/r/113174/#comment30318 Yep looks like changes in this file should be reverted. staging/kjsembed/CMakeLists.txt http://git.reviewboard.kde.org/r/113174/#comment30319 Hm... if this if really needed? UiTools being declared as a REQUIRED component in the find_package above. - Kevin Ottens On Oct. 8, 2013, 2:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113174/ --- (Updated Oct. 8, 2013, 2:09 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adopt directory organization, naming scheme, cmake structures, documents dependencies. Diffs - CMakeLists.txt 368584e kjsembed/AUTHORS kjsembed/CMakeLists.txt 6cb6727 kjsembed/Mainpage.dox kjsembed/examples/calc/calc.js kjsembed/examples/calc/calc.ui kjsembed/examples/console/console.js kjsembed/examples/console/console.ui kjsembed/examples/docviewer/docviewer.js kjsembed/examples/docviewer/docviewer.ui kjsembed/examples/fancy/fancy.js kjsembed/examples/grammar/grammar.js kjsembed/examples/kjsconsole/CMakeLists.txt d06f27b kjsembed/examples/kjsconsole/console.h kjsembed/examples/kjsconsole/console.cpp f65f39b kjsembed/examples/kjsconsole/console.qrc kjsembed/examples/kjsconsole/images/bug.png kjsembed/examples/kjsconsole/images/class.png kjsembed/examples/kjsconsole/images/constant.png kjsembed/examples/kjsconsole/images/method.png kjsembed/examples/kjsconsole/images/next.png kjsembed/examples/kjsconsole/images/no.png kjsembed/examples/kjsconsole/images/property.png kjsembed/examples/kjsconsole/images/runto.png kjsembed/examples/kjsconsole/images/start.png kjsembed/examples/kjsconsole/images/step.png kjsembed/examples/kjsconsole/images/stop.png kjsembed/examples/kjsconsole/jsconsole.ui kjsembed/examples/kjsconsole/kjs_object_model.h kjsembed/examples/kjsconsole/kjs_object_model.cpp kjsembed/examples/kjsconsole/main.cpp kjsembed/examples/kjsconsole/numberedtextview.h kjsembed/examples/kjsconsole/numberedtextview.cpp f144502 kjsembed/examples/scribble/scribble.js kjsembed/examples/tests/args.js kjsembed/examples/tests/brush.js kjsembed/examples/tests/builtins.js kjsembed/examples/tests/class.js kjsembed/examples/tests/colortest.js kjsembed/examples/tests/conio.js kjsembed/examples/tests/domtest.js kjsembed/examples/tests/events.js kjsembed/examples/tests/fileio.js kjsembed/examples/tests/fonttest.js kjsembed/examples/tests/frame.js kjsembed/examples/tests/gc.js kjsembed/examples/tests/include.js kjsembed/examples/tests/inner.js kjsembed/examples/tests/jsslot.js kjsembed/examples/tests/layout.js kjsembed/examples/tests/library.js kjsembed/examples/tests/listproperties.js kjsembed/examples/tests/matt.js kjsembed/examples/tests/paintertest.js kjsembed/examples/tests/paintevent.js kjsembed/examples/tests/pixmap.js kjsembed/examples/tests/recttest.js kjsembed/examples/tests/settings.js kjsembed/examples/tests/signslots.js kjsembed/examples/tests/statictest.js kjsembed/examples/tests/stylesheet.js kjsembed/examples/tests/svgtest.js kjsembed/examples/tests/system.js kjsembed/examples/tests/test.svg kjsembed/examples/tests/test.ui kjsembed/examples/tests/typecheck.js kjsembed/examples/tests/uitest.js kjsembed/examples/tests/uitest2.js kjsembed/examples/tests/url.js kjsembed/examples/tests/widgettest.js kjsembed/kjscmd/CMakeLists.txt eeb5667 kjsembed/kjscmd/console.js kjsembed/kjscmd/kjscmd.cpp df833db kjsembed/kjscmd/kjscmd.qrc kjsembed/kjsembed/CMakeLists.txt 8089c4b kjsembed/kjsembed/QBrush_bind.h kjsembed/kjsembed/QBrush_bind.cpp kjsembed/kjsembed/application.h kjsembed/kjsembed/application.cpp kjsembed/kjsembed/binding_support.h kjsembed/kjsembed/binding_support.cpp kjsembed/kjsembed/brush.h kjsembed/kjsembed/brush.cpp kjsembed/kjsembed/builtins.h kjsembed/kjsembed/builtins.cpp kjsembed/kjsembed/color.h kjsembed/kjsembed/color.cpp kjsembed/kjsembed/dom.h kjsembed/kjsembed/dom.cpp kjsembed/kjsembed/eventproxy.h
Re: Review Request 112932: Update superbuild to include all tiered libraries
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112932/ --- (Updated Oct. 9, 2013, 5:22 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kdelibs Description --- Add missing find_packages to kunitconversion -- Update superbuild to include all tiered libraries (separate commits) superbuild dependencies were taken from the relevant CMake.in files, which may or may not be correct. Diffs - tier3/kunitconversion/KUnitConversionConfig.cmake.in 7bbf71c superbuild/CMakeLists.txt 86e3389 Diff: http://git.reviewboard.kde.org/r/112932/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112932: Update superbuild to include all tiered libraries
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112932/#review41457 --- It seems no-one uses superbuild, so I'm discarding it. - David Edmundson On Oct. 9, 2013, 5:22 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112932/ --- (Updated Oct. 9, 2013, 5:22 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add missing find_packages to kunitconversion -- Update superbuild to include all tiered libraries (separate commits) superbuild dependencies were taken from the relevant CMake.in files, which may or may not be correct. Diffs - tier3/kunitconversion/KUnitConversionConfig.cmake.in 7bbf71c superbuild/CMakeLists.txt 86e3389 Diff: http://git.reviewboard.kde.org/r/112932/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113173: Reduce warnings noise when including wtf/Platform.h in KJS
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113173/#review41458 --- Ship it! Ship It! - Kevin Ottens On Oct. 8, 2013, 1:20 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113173/ --- (Updated Oct. 8, 2013, 1:20 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Modifies how features are checked. This file has some pre-processor macros that are used to checking for OS features. These are defined with 1 if acceptable and undefined if the feature is not present. These macros are being checked with #if, so the pre-processor will complain whenever it's asked about one of the variables that haven't been defined. This patch adds a defined() first, before checking the value, so the pre-processor doesn't need to consider the variable value, if it's not present. This change makes it possible to read the compilation logs from modules that use KJS. Diffs - tier1/kjs/src/wtf/Platform.h 843cfd2 Diff: http://git.reviewboard.kde.org/r/113173/diff/ Testing --- Builds, KJS tests pass. 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 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/#review41459 --- Ship it! Makes sense, as long as there's a replacement. :) Maybe you should put a note on KDE5Porting.hml - Aleix Pol Gonzalez On Oct. 7, 2013, 5:01 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- (Updated Oct. 7, 2013, 5:01 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113173: Reduce warnings noise when including wtf/Platform.h in KJS
Aleix Pol Gonzalez wrote: This patch adds a defined() first, before checking the value, so the pre-processor doesn't need to consider the variable value, if it's not present. This seems like a bad idea. These are defined with 1 if acceptable and undefined if the feature is not present. This is the problem that should be fixed. It should be 0 if the feature is not present. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112797: Bring back KStringHandler::naturalCompare()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112797/#review41463 --- This review has been submitted with commit 7bfff9a0e10a71adf9aaa92ddac85f05a6a86bad by Aleix Pol to branch frameworks. - Commit Hook On Oct. 4, 2013, 5:26 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112797/ --- (Updated Oct. 4, 2013, 5:26 p.m.) Review request for KDE Frameworks, Frank Reininghaus and Mark Gaiser. Repository: kdelibs Description --- Apparently there's people who still want to have it. Leave it in KCoreAddons for the moment, until we decide that it can be replaced for good by QCollator. Diffs - KDE5PORTING.html 88700b0 staging/kde4support/autotests/CMakeLists.txt 473bdba staging/kde4support/autotests/naturalcomparetest.cpp PRE-CREATION staging/kde4support/src/CMakeLists.txt 51519a3 staging/kde4support/src/kdecore/kstringhandler_deprecated.h PRE-CREATION staging/kde4support/src/kdecore/kstringhandler_deprecated.cpp PRE-CREATION tier1/kcoreaddons/autotests/kstringhandlertest.cpp 93da351 tier1/kcoreaddons/src/lib/text/kstringhandler.h 442b97a tier1/kcoreaddons/src/lib/text/kstringhandler.cpp ea3bbf5 Diff: http://git.reviewboard.kde.org/r/112797/diff/ Testing --- Builds, tests pass. 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 112797: Bring back KStringHandler::naturalCompare()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112797/ --- (Updated Oct. 9, 2013, 6:07 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Frank Reininghaus and Mark Gaiser. Repository: kdelibs Description --- Apparently there's people who still want to have it. Leave it in KCoreAddons for the moment, until we decide that it can be replaced for good by QCollator. Diffs - KDE5PORTING.html 88700b0 staging/kde4support/autotests/CMakeLists.txt 473bdba staging/kde4support/autotests/naturalcomparetest.cpp PRE-CREATION staging/kde4support/src/CMakeLists.txt 51519a3 staging/kde4support/src/kdecore/kstringhandler_deprecated.h PRE-CREATION staging/kde4support/src/kdecore/kstringhandler_deprecated.cpp PRE-CREATION tier1/kcoreaddons/autotests/kstringhandlertest.cpp 93da351 tier1/kcoreaddons/src/lib/text/kstringhandler.h 442b97a tier1/kcoreaddons/src/lib/text/kstringhandler.cpp ea3bbf5 Diff: http://git.reviewboard.kde.org/r/112797/diff/ Testing --- Builds, tests pass. 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 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 12:37 p.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... - Chusslove --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 9:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 9:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in 18b6e2f tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112785/diff/ Testing --- Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113173: Reduce warnings noise when including wtf/Platform.h in KJS
Can we keep all discussions on reviewboard? If you mix replying to the mailing list we lose track of messages very quickly. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113160: Move KDeclarative to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113160/#review41465 --- This review has been submitted with commit b986e512054c3a9423226bb26863911a69aafc98 by Aleix Pol to branch frameworks. - Commit Hook On Oct. 7, 2013, 6:18 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113160/ --- (Updated Oct. 7, 2013, 6:18 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KDeclarative to tier3 Also trim down the test so that it uses the module but it doesn't use something from upstream (such as plasma components) Diffs - tier3/CMakeLists.txt 11be8e4 staging/kdeclarative/tests/testobject_p.h staging/kdeclarative/tests/test.qml 060c265 staging/kdeclarative/tests/kdeclarativetest.cpp d5b9f96 staging/kdeclarative/tests/CMakeLists.txt ad4a7db staging/kdeclarative/src/qmlobject_p.h staging/kdeclarative/src/qmlobject.cpp staging/kdeclarative/src/qmlobject.h staging/kdeclarative/src/private/rootcontext_p.h staging/kdeclarative/src/private/rootcontext.cpp staging/kdeclarative/src/private/kiconprovider_p.h staging/kdeclarative/src/private/kiconprovider.cpp staging/kdeclarative/src/private/kdeclarative_p.h staging/kdeclarative/src/kdeclarative.cpp staging/kdeclarative/src/kdeclarative.h staging/kdeclarative/src/configpropertymap.cpp staging/kdeclarative/src/configpropertymap.h staging/kdeclarative/src/bindings/url.cpp staging/kdeclarative/src/bindings/qscriptnonguibookkeeping.cpp staging/kdeclarative/src/bindings/icon.cpp staging/kdeclarative/src/bindings/i18n_p.h staging/kdeclarative/src/bindings/i18n.cpp staging/kdeclarative/src/bindings/backportglobal.h staging/kdeclarative/src/CMakeLists.txt staging/kdeclarative/KDeclarativeConfig.cmake.in staging/kdeclarative/CMakeLists.txt eefa756 staging/CMakeLists.txt 4f64e8a tier3/kdeclarative/tests/CMakeLists.txt PRE-CREATION tier3/kdeclarative/tests/test.qml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113160/diff/ Testing --- the test starts and seems to work. 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 113160: Move KDeclarative to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113160/ --- (Updated Oct. 9, 2013, 6:30 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KDeclarative to tier3 Also trim down the test so that it uses the module but it doesn't use something from upstream (such as plasma components) Diffs - tier3/CMakeLists.txt 11be8e4 staging/kdeclarative/tests/testobject_p.h staging/kdeclarative/tests/test.qml 060c265 staging/kdeclarative/tests/kdeclarativetest.cpp d5b9f96 staging/kdeclarative/tests/CMakeLists.txt ad4a7db staging/kdeclarative/src/qmlobject_p.h staging/kdeclarative/src/qmlobject.cpp staging/kdeclarative/src/qmlobject.h staging/kdeclarative/src/private/rootcontext_p.h staging/kdeclarative/src/private/rootcontext.cpp staging/kdeclarative/src/private/kiconprovider_p.h staging/kdeclarative/src/private/kiconprovider.cpp staging/kdeclarative/src/private/kdeclarative_p.h staging/kdeclarative/src/kdeclarative.cpp staging/kdeclarative/src/kdeclarative.h staging/kdeclarative/src/configpropertymap.cpp staging/kdeclarative/src/configpropertymap.h staging/kdeclarative/src/bindings/url.cpp staging/kdeclarative/src/bindings/qscriptnonguibookkeeping.cpp staging/kdeclarative/src/bindings/icon.cpp staging/kdeclarative/src/bindings/i18n_p.h staging/kdeclarative/src/bindings/i18n.cpp staging/kdeclarative/src/bindings/backportglobal.h staging/kdeclarative/src/CMakeLists.txt staging/kdeclarative/KDeclarativeConfig.cmake.in staging/kdeclarative/CMakeLists.txt eefa756 staging/CMakeLists.txt 4f64e8a tier3/kdeclarative/tests/CMakeLists.txt PRE-CREATION tier3/kdeclarative/tests/test.qml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113160/diff/ Testing --- the test starts and seems to work. 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 113179: Make the runners compile again
On Oct. 8, 2013, 9:15 p.m., Aleix Pol Gonzalez wrote:
There's also runner-related code in
src/declarativeimports/{core,runnermodel}, these should be reenabled as
well. Possibly, they also need changes to make built. I had disabled this
after a discussion with Aaron (who has refactored these classes) and
Vishesh, who plans to work on them. I'm not sure what's the most useful, I
can imagine this leading to a lot of conflicts when merging this
refactoring, while the benefits of this patch are then just going away.
Aaron can weigh in here to say what's easiest moving forward. Mirko is the
best person to review the ThreadWeaver API changes you implement. Could you
add him to the reviewers for this request?
thanks...
Aleix Pol Gonzalez wrote:
Well, the only reason I did this was because kickoff in kde-workspace
requires runners as well. If those are not good anymore, maybe it's wiser to
disable them there as well?
Sebastian Kügler wrote:
Ah, I've missed these. I was operating under the assumption that nobody
would use runners in Plasma2 yet -- wrong. We can do both, disable runners in
kickoff or merge this. Let's hear others' opinions.
Kevin Ottens wrote:
It overall looks fine to me. We'd need someone with a more intimate
knowledge of krunner to look at it though.
if Mirko can say the changes in threadweaver are correct, for me is fine as
well, the lest we keep dead code in the repo the better it is
- Marco
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113179/#review41412
---
On Oct. 8, 2013, 5:14 p.m., Aleix Pol Gonzalez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113179/
---
(Updated Oct. 8, 2013, 5:14 p.m.)
Review request for KDE Frameworks and Plasma.
Repository: plasma-framework
Description
---
Recently there's been some big changes in the ThreadWeaver API. So big that
they break the source compatibility we were supposed to maintain, big time.
This patch tries to port plasma-framework to that new API.
Diffs
-
src/plasma/CMakeLists.txt 411256a
src/plasma/private/runnerjobs.cpp d11f7e9
src/plasma/private/runnerjobs_p.h 7fd7076
src/plasma/private/storage.cpp 35b222e
src/plasma/runnermanager.cpp 135279e
src/plasma/scripting/runnerscript.cpp d5142a2
Diff: http://git.reviewboard.kde.org/r/113179/diff/
Testing
---
Everything builds, including kde-workspace.
Couldn't test it, there's no tests for it or even an application to test it
:/.
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 112730: add CMake changes to knewstuff
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/ --- (Updated Oct. 9, 2013, 2:24 p.m.) Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Chusslove Illich. Changes --- Ok all updated and cleaned up. This should be good to go, pending any issues found in review of course. Repository: kdelibs Description --- This makes it so I can mkdir build; cd build; cmake ../; make install from knewstuff sources. It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio libraries have been split out apparently. I'm not sure why sources had to be changed, but I had to add includes of klocalizedstring where we didn't need them before somehow. Diffs (updated) - knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a knewstuff/KNewStuffConfig.cmake.in PRE-CREATION knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 knewstuff/src/ui/entrydetailsdialog.cpp 65b75d79941d9026f368f82c7b6df91d754e0925 knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 Diff: http://git.reviewboard.kde.org/r/112730/diff/ Testing --- It builds and installs. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
libnm-qt Qt5 port: -fPIC or fPIE needed?
Hi, While porting libnm-qt to Qt5, I'm running into the following problem when building the tests. I've not seen this error before, and I'd like advice how to fix it. [ 59%] Building CXX object tests/CMakeFiles/test_8021xsetting.dir/8021xsetting.cpp.o In file included from /home/sebas/kf5/qt5/qtbase/include/QtCore/qglobal.h:1:0, from /home/sebas/kf5/qt5/qtbase/include/QtCore/../../src/corelib/global/qnamespace.h:45, from /home/sebas/kf5/qt5/qtbase/include/QtCore/qnamespace.h:1, from /home/sebas/kf5/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qobjectdefs.h:45, from /home/sebas/kf5/qt5/qtbase/include/QtCore/qobjectdefs.h:1, from /home/sebas/kf5/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qobject.h:48, from /home/sebas/kf5/qt5/qtbase/include/QtCore/qobject.h:1, from /home/sebas/kf5/qt5/qtbase/include/QtCore/QObject:1, from /home/sebas/kf5/src/libnm-qt/tests/8021xsetting.h:24, from /home/sebas/kf5/src/libnm-qt/tests/8021xsetting.cpp:21: /home/sebas/kf5/qt5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:991:4: error: #error You must build your code with position independent code if Qt was built with -reduce-relocations. Compile your code with -fPIC or -fPIE. make[2]: *** [tests/CMakeFiles/test_8021xsetting.dir/8021xsetting.cpp.o] Error 1 This error comes up for a whole slew of tests. I've tried adding -fpie and PIE to the CMAKE_EXE_LINKER_FLAGS (also tried CMAKE_LIBRARY_LINKER_FLAGS) by just setting this variable, but to no avail. The rest of libnm-qt builds fine. Could anyone give me a hint how to fix this? Code is in the qt5 branch of libnm-qt. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112985: Adjust API in KEmoticons framework: map and index methods
On Oct. 9, 2013, 5:05 p.m., Kevin Ottens wrote: I'm not sure what this patch is trying to achieve. It doesn't look much more clearer API to me than what we had before. :-) Could you share a bit more of the rationale? I guess I'm missing something. Ok, let's see. We have a method in KEmoticonsProvider that creates a map and another method that creates an index: /** * Returns a QHash that contains the emoticon path as keys and the text as values */ QHashQString, QStringList emoticonsMap() const; /** * Returns a QHash that contains emoticons indexed by the first char */ QHashQChar, QListEmoticon emoticonsIndex() const; We have a method that clears the map: /** * Clears the emoticons map */ void clearEmoticonsMap(); And then we have the original methods that manage the map and the index. The problem I see with them is that addEmoticonsMap(), for example, doesn't actually do what it says. If you don't read the documentation, addEmoticonsMap() seems to add (somewhere) a new (or existing) emoticon map. Instead, it inserts a NEW ITEM in the emoticon map: /** * Inserts a new item in the emoticon map * */ void addEmoticonsMap(QString key, QStringList value); That's why I've changed it to addMapItem(). I could've used addEmoticonsMapItem(), but I thought it was too long and since there's only one map and there's only one index in KEmoticonsProvider, addMapItem() is clear enough (and clearer than clearEmoticonsMap()). Besides, it now points to the documentation of emoticonsMap(), which explains where does that map come from: /** * Inserts a new item in the emoticon map * @since 5.0 * @see emoticonsMap() */ void addMapItem(QString key, QStringList value); The same applies to the rest: Deprecated: /** * Removes an item from the emoticon map * */ void removeEmoticonsMap(QString key); New: /** * Removes an item from the emoticon map * @since 5.0 * @see emoticonsMap() */ void removeMapItem(QString key); -- Deprecated: /** * Adds an emoticon to the index * @param path path to the emoticon * @param emoList list of text associated with this emoticon * */ void addEmoticonIndex(const QString path, const QStringList emoList); New: /** * Adds an emoticon to the index * @param path path to the emoticon * @param emoList list of text associated with this emoticon * @since 5.0 * @see emoticonsIndex() */ void addIndexItem(const QString path, const QStringList emoList); --- Deprecated: /** * Removes an emoticon from the index * @param path path to the emoticon * @param emoList list of text associated with this emoticon */ void removeEmoticonIndex(const QString path, const QStringList emoList); New: /** * Removes an emoticon from the index * @param path path to the emoticon * @param emoList list of text associated with this emoticon * @since 5.0 * @see emoticonsIndex() */ void removeIndexItem(const QString path, const QStringList emoList); - When I began to work with KEmoticons I found much code that wasn't very good, so I want to try to make the API better, because is now or never :-) . Anyway, I understand it's a delicate issue. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112985/#review41450 --- On Oct. 6, 2013, 9:02 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112985/ --- (Updated Oct. 6, 2013, 9:02 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: map and index methods -Make map and index KEmoticons API slightly clearer and deprecate the methods that are confusing. -Use the new methods in the plugins. Diffs - staging/kemoticons/src/core/kemoticonsprovider.h 85fc7efb8923d76476f0a16f70f8ebb15e451081 staging/kemoticons/src/core/kemoticonsprovider.cpp d04c76e87b118f5d45717b3b2ccd9dea47dc2526 staging/kemoticons/src/providers/adium/adium_emoticons.cpp a3aaa0fdc0b3dcc862f98865d2e6419e716f4f17 staging/kemoticons/src/providers/kde/kde_emoticons.cpp 5b5114a14dd94a6ebcba8a6f7dd163f73048189a staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp e9f89eecce3d6e6407113a84cb5200ff66564c19 staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 0dc92ed092d87a559fe7fa1a40e804843ab73d59 Diff: http://git.reviewboard.kde.org/r/112985/diff/ Testing
Re: [Kde-hardware-devel] libnm-qt Qt5 port: -fPIC or fPIE needed?
On Wednesday, October 09, 2013 18:14:10 Daniel Nicoletti wrote: I have added this to some of my qt5 projects and it worked: add_definitions(-fPIC) Thanks Daniel, that helps. :) 2013/10/9 Sebastian Kügler se...@kde.org: /home/sebas/kf5/qt5/qtbase/include/QtCore/../../src/corelib/global/qglobal .h:991:4: error: #error You must build your code with position independent code if Qt was built with -reduce-relocations. Compile your code with -fPIC or -fPIE. make[2]: *** -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Compiling Plasma-Framework with a QT5 compiled with -egl -opengl es2
Hi. I am trying to compile plasma-framework against a qt5 that is ready for Wayland, which does not have Desktop GL enabled. However I seem to get an error that seems to be related to opengl in QT. Is this a bug I should file? This is the relevant output: [ 81%] Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/plasma_dataengine_example_sourcesOnRequest_automoc.cpp.o [ 82%] Building CXX object src/plasmaquick/CMakeFiles/PlasmaQuick.dir/configview.cpp.o In file included from /opt/include/GL/glx.h:32:0, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/gl.h:162:17: error: conflicting declaration ‘typedef double GLdouble’ typedef double GLdouble; /* double precision float */ ^ In file included from /opt/include/QtQuick/qsggeometry.h:46:0, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/QtGui/qopengl.h:97:17: error: ‘GLdouble’ has a previous declaration as ‘typedef GLfloat GLdouble’ typedef GLfloat GLdouble; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:459:19: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptr’ typedef ptrdiff_t GLsizeiptr; ^ In file included from /opt/include/QtGui/qopengl.h:82:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/GLES2/gl2.h:39:26: error: ‘GLsizeiptr’ has a previous declaration as ‘typedef khronos_ssize_t GLsizeiptr’ typedef khronos_ssize_t GLsizeiptr; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:460:19: error: conflicting declaration ‘typedef ptrdiff_t GLintptr’ typedef ptrdiff_t GLintptr; ^ In file included from /opt/include/QtGui/qopengl.h:82:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/GLES2/gl2.h:38:26: error: ‘GLintptr’ has a previous declaration as ‘typedef khronos_intptr_t GLintptr’ typedef khronos_intptr_t GLintptr; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:2169:149: error: conflicting declaration ‘typedef void (* GLDEBUGPROC)(GLenum, GLenum, GLuint, GLenum, GLsizei, const GLchar*, const void*)’ typedef void (APIENTRY *GLDEBUGPROC)(GLenum source,GLenum type,GLuint id,GLenum severity,GLsizei length,const GLchar *message,const void *userParam); ^ In file included from /opt/include/QtGui/qopengl.h:92:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/QtGui/qopengles2ext.h:192:28: error: ‘GLDEBUGPROC’ has a previous declaration as ‘typedef void (* GLDEBUGPROC)(GLenum, GLenum, GLuint, GLenum, GLsizei, const GLchar*, GLvoid*)’ typedef void (GL_APIENTRYP GLDEBUGPROC)(GLenum source,GLenum
Re: Compiling Plasma-Framework with a QT5 compiled with -egl -opengl es2
2013/10/9 nerdopolis bluescreen_aven...@verizon.net: Hi. I am trying to compile plasma-framework against a qt5 that is ready for Wayland, which does not have Desktop GL enabled. However I seem to get an error that seems to be related to opengl in QT. Is this a bug I should file? This is the relevant output: [ 81%] Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/plasma_dataengine_example_sourcesOnRequest_automoc.cpp.o [ 82%] Building CXX object src/plasmaquick/CMakeFiles/PlasmaQuick.dir/configview.cpp.o In file included from /opt/include/GL/glx.h:32:0, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/gl.h:162:17: error: conflicting declaration ‘typedef double GLdouble’ typedef double GLdouble; /* double precision float */ ^ In file included from /opt/include/QtQuick/qsggeometry.h:46:0, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/QtGui/qopengl.h:97:17: error: ‘GLdouble’ has a previous declaration as ‘typedef GLfloat GLdouble’ typedef GLfloat GLdouble; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:459:19: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptr’ typedef ptrdiff_t GLsizeiptr; ^ In file included from /opt/include/QtGui/qopengl.h:82:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/GLES2/gl2.h:39:26: error: ‘GLsizeiptr’ has a previous declaration as ‘typedef khronos_ssize_t GLsizeiptr’ typedef khronos_ssize_t GLsizeiptr; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:460:19: error: conflicting declaration ‘typedef ptrdiff_t GLintptr’ typedef ptrdiff_t GLintptr; ^ In file included from /opt/include/QtGui/qopengl.h:82:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/GLES2/gl2.h:38:26: error: ‘GLintptr’ has a previous declaration as ‘typedef khronos_intptr_t GLintptr’ typedef khronos_intptr_t GLintptr; ^ In file included from /opt/include/GL/gl.h:2085:0, from /opt/include/GL/glx.h:32, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:32: /opt/include/GL/glext.h:2169:149: error: conflicting declaration ‘typedef void (* GLDEBUGPROC)(GLenum, GLenum, GLuint, GLenum, GLsizei, const GLchar*, const void*)’ typedef void (APIENTRY *GLDEBUGPROC)(GLenum source,GLenum type,GLuint id,GLenum severity,GLsizei length,const GLchar *message,const void *userParam); ^ In file included from /opt/include/QtGui/qopengl.h:92:0, from /opt/include/QtQuick/qsggeometry.h:46, from /opt/include/QtQuick/qsgnode.h:45, from /opt/include/QtQuick/qsgsimpletexturenode.h:45, from /opt/include/QtQuick/QSGSimpleTextureNode:1, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.h:24, from /srcbuild/plasma-framework/src/declarativeimports/core/windowthumbnail.cpp:19: /opt/include/QtGui/qopengles2ext.h:192:28: error: ‘GLDEBUGPROC’ has a previous declaration as ‘typedef void (*
