Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
On Oct. 16, 2013, 12:15 p.m., John Layt wrote: Wow, there sure is a lot of code in there catering for all the possible corner cases :-) QTimeZone has a lot less places it checks, so I'll need to do an in-depth comparison, but given Qt5 will only support modern distros I think most of it is redundant. One thought is if we still want to have a signal that the system database has been updated? While Qt doesn't cache the time zone data, the apps probably will cache the QTimeZone instances themselves and may need to be told that the database has changed so they can take action. Then again, it's not something that will happen very often, and what will the apps do in response? If they refresh their cache the shared copies in QDateTime won't update. I guess QTimeZone will need a reloadData() method added instead. I've looked at the Windows code and it mostly looks OK, all it does is monitor the registry for changes. What you do need to change is the DBus signal from configChanged to your new timeZoneChanged signal. With regards the signal name change, does it need to go in the porting guide or somewhere so people know it has changed? In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need the daemon for now. Martin Klapetek wrote: Wow, there sure is a lot of code in there catering for all the possible corner cases :-) QTimeZone has a lot less places it checks, so I'll need to do an in-depth comparison, but given Qt5 will only support modern distros I think most of it is redundant. Part of that is support for Solaris, but I see Solaris is not supported by Qt anymore [1][2], so I just removed it altogether. One thought is if we still want to have a signal that the system database has been updated? While Qt doesn't cache the time zone data, the apps probably will cache the QTimeZone instances themselves and may need to be told that the database has changed so they can take action. I think it might be worth having it...I'll add it back, can't hurt :) I've looked at the Windows code and it mostly looks OK, all it does is monitor the registry for changes. What you do need to change is the DBus signal from configChanged to your new timeZoneChanged signal. Ah yes, I forgot to add that to the patch, sorry. With regards the signal name change, does it need to go in the porting guide or somewhere so people know it has changed? I wanted to add it, but that's in kdelibs. Question is, should there be a guide for runtime/workspace too? In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need the daemon for now. Ok, keep us posted. (It would be cool to have cross-desktop solution for this too...or system-wide spec at least, so we could use non-qt/-kde apps still supporting timezone changes, but oh well). [1] - http://qt-project.org/doc/qt-5.1/qtdoc/supported-platforms.html [2] - http://qt.digia.com/Product/Supported-Platforms/ There are still people around with a Solaris system. Not supported doesn't mean we should actively remove existing support, IMHO. About the porting guide: the distinction between kdelibs and kde-runtime will disappear, given the framework-ification. So treat it as a porting guide from kde 4 to kde-frameworks, i.e. it's fine to include runtime stuff in there. About a solution in Qt --- that means each and every Qt app will have to monitor the same timezone file(s), isn't that a bit too expensive? (not sure, just wondering) - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review41816 --- On Oct. 18, 2013, 1 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/ --- (Updated Oct. 18, 2013, 1 p.m.) Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. Repository: kde-runtime Description --- Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out that all the stuff KTZD was doing was added in QTimeZone, that includes reading correct system files/env variables to obtain the timezone and returning the proper system zone (KTZD did all this by itself). It also doesn't need to parse the timezone files itself or watch for their changes as QTimeZone objects are not stored. So now it's just a thin module watching /etc/timezone (used by Debian-based distros)
Re: CMake, KF5_INCLUDE_DIRS empty?
Mark wrote:
On Sun, Oct 20, 2013 at 11:42 AM, David Faure fa...@kde.org wrote:
On Sunday 13 October 2013 17:18:28 Mark wrote:
Hi,
I used to rely on KF5_INCLUDE_DIRS but since a few days that variable
seems to be empty. Did i do something wrong?
My CMake file for the relevant parts:
find_package(ECM REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
find_package(KF5 MODULE REQUIRED COMPONENTS CMake Compiler InstallDirs
KBookmarks XmlGui Solid KIO)
include_directories(${KF5_INCLUDE_DIRS})
KF5_INCLUDE_DIRS used to contain a bunch of paths a few days ago.
When I saw this mail, I almost posted a link to
http://www.macieira.org/blog/2012/05/doesnt-work-doesnt-work/
because your mail didn't specify what the problem was.
Then I realized that your mail didn't actually say that there was a problem
at all, so I didn't.
Your test case above is not complete. See
http://sscce.org/
I don't know much about this variable, but it shouldn't be needed anyway.
Just linking to the appropriate targets (e.g. KF5::KBookmarks) should
bring in the corresponding include dirs.
After hours of CMake debugging i finally found the reason for the
variable to be empty [1].
I'm glad you found the cause and more info. Looking at gitk would have saved
you some hours I guess, as would looking at the output
of 'git log -S INCLUDE_DIRS'.
However, when i add in KIO (or KIOCore) or any known KIO thing i still
am welcomed by by an error that KIO/Job could not be found...
Before the commit [1] i used to just add ${KF5_INCLUDE_DIRS} to my
include dirs which would pick everything up. Right now when i compile
with KIO added like this:
find_package(KF5 MODULE REQUIRED ... KIO ...)
target_link_libraries(project
... other libs ...
kio
kiocore
KF5::KIOCore
KF5::KIOWidgets
)
When compiling it includes some paths, but certainly not the one where
KIO is hidden. I only see:
-I/home/kde-devel/kf5/include
KIO is hidden at:
-I/home/kde-devel/kf5/include/KDE
using kio/job.h as includes works just fine. Using KIO/Job does not.
Do you happen to know a solution here?
add
target_include_directories(foo
PUBLIC
$INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/KDE
)
to whatever foo needs a KDE/ include.
There is a more-generic solution, but currently there are several
inconsistencies in 'where do we put includes' and 'what include directories
should the user use'.
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Can someone verify this? Massive folders only show about 1000 entries in KF/Qt 5.2.
Mark wrote: Step 2: Create a Qt 5.2 project. CMake or QMake, doesn't matter. it needs kdelibs, kio and qt widgets and whatever the extra dependencies are at this moment. You can use this cmake file for reference http://pastebin.kde.org/ptq5kgkqx. Change the absolute paths. The code for you main file: http://pastebin.kde.org/pyjpytxui Posting pastebin urls to a mailing list is always a bad idea because they expire. Already, the first link here no longer exists. Posting small code files as attachments is generally fine. Anyone looking for answers to questions (on any mailing list) in N years and finding pastebin links will not get the answer that was provided. Try replacing the model with a QStringListModel which contains 50,000 elements. If that shows them all, then the problem is more-likely in the KDirModel than in the Qt view. That narrows down the search for the bug. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Config files naming policy
Hi all, Since we are now sharing the locations of our configs with non-kde software, we can potentially get collisions with those. I'm proposing changing the names of the config files to org.kde.something (or some other alternative). Cheerio, Ivan -- Acting is merely the art of keeping a large group of people from coughing. -- Sir Ralph Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113148: Move and clean KBuildsycoca to KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/ --- (Updated Oct. 21, 2013, 10:22 a.m.) Review request for KDE Frameworks. Changes --- Rebased the patch, fixed all issues and restored KCrash. Repository: kdelibs Description --- Moved KBuildsyscoca to KService. I have done the moving and the cleaning in different commits, just unified them for reviewboard. Diffs (updated) - kded/CMakeLists.txt 3aba077 kded/applications.menu kded/kbuildmimetypefactory.h kded/kbuildmimetypefactory.cpp 2e81ce7 kded/kbuildservicefactory.h kded/kbuildservicefactory.cpp 971f327 kded/kbuildservicegroupfactory.h kded/kbuildservicegroupfactory.cpp 5485b1c kded/kbuildservicetypefactory.h kded/kbuildservicetypefactory.cpp f473cd6 kded/kbuildsycoca.h kded/kbuildsycoca.cpp 8ea2d2e kded/kbuildsycocainterface.h kded/kctimefactory.h kded/kctimefactory.cpp kded/kmimeassociations.h kded/kmimeassociations.cpp kded/ksycocaresourcelist.h kded/tests/CMakeLists.txt da51ed4 kded/tests/kmimeassociationstest.cpp kded/vfolder_menu.h kded/vfolder_menu.cpp staging/kservice/CMakeLists.txt 4e8dbd2 staging/kservice/kbuildsycoca/CMakeLists.txt PRE-CREATION staging/kservice/tests/CMakeLists.txt 23d4854 Diff: http://git.reviewboard.kde.org/r/113148/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 113302: Static KEncodingFileDialog in staging/kio
On Oct. 20, 2013, 9:32 a.m., David Faure wrote: OK, I'm just wondering if it still makes sense to make it static-methods-only. It can still very well work the other way, which can allow extra flexibility if needed (e.g. for kate to add another widget into it, or use it non-modal, etc.). What's the reason for making it less flexible? Just the fact that nobody uses the constructor right now? (I assume you checked that?). Kévin? Initially I think I proposed even a namespace. :-) But seeing the current solution I think you're right, we could indeed allow instances to be created. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42003 --- On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112032: Convert tier1/kwidgetaddons to the new Qt5 signal/slot syntax
On Sept. 23, 2013, 9:10 a.m., Kevin Ottens wrote: Any news about that patch? Hasn't seen activity in a while, it probably doesn't apply cleanly anymore. Still no news? If I don't see activity by next monday I'll close it as discarded. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112032/#review40503 --- On Aug. 12, 2013, 4:07 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112032/ --- (Updated Aug. 12, 2013, 4:07 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Convert tier1/kwidgetaddons to the new Qt5 signal/slot syntax Conversion was performed using a clang based tool I wrote (https://github.com/a-richardson/convert2qt5signalslot). Manual changes required were mostly reverting to the old syntax for Q_PRIVATE_SLOTS since not all of them use the _k_ function name prefix. Also one case where disconnect was used (kcursor.cpp). Command to perform this was: find tier1/kwidgetsaddons/ -iname *.cpp -print0 | xargs -0 convert2qt5signalslot -skip-prefix=_k_ -p ~/devel/build/kdelibsprint0 | xargs -0 convert2qt5signalslot -skip-prefix=_k_ -p ~/devel/build/kdelibs Diffs - tier1/kwidgetsaddons/src/kacceleratormanager.cpp f50057e8899b30ea2a5dfbe430e82a090299addb tier1/kwidgetsaddons/src/kactionmenu.cpp dd1dce144aa028af41fb073a5d3636f4c9e8901b tier1/kwidgetsaddons/src/kactionselector.cpp 879bb4918d85ee8360e72fab9b5750196c29ad6f tier1/kwidgetsaddons/src/kassistantdialog.cpp 81d3828e48df6e8e09f91ce8d2056cc8294411ea tier1/kwidgetsaddons/src/kcursor.cpp 9b0fe01358650a5a82cb9f9cd50edf9506034d4c tier1/kwidgetsaddons/src/keditlistwidget.cpp 23637a5b60f3582097fb136dfa9adedb44e157e9 tier1/kwidgetsaddons/src/kmessagebox.cpp 1fff72f1df4703b0893396c097b05ebefebbc362 tier1/kwidgetsaddons/src/kmessagewidget.cpp a4f9975297a0177dfd5bf50ee480b240d60c1d47 tier1/kwidgetsaddons/src/kpageview_p.cpp 4e236f11dea25e280f5b5bf0040424cdb5e934a6 tier1/kwidgetsaddons/src/kpagewidget.cpp 2931623c5a176f1013d5dc15e59df0c6a7a26fb7 tier1/kwidgetsaddons/src/kpassivepopup.cpp 663f63af413b7660c9c1b21af3e3ae4d7c424bbe tier1/kwidgetsaddons/src/kpassworddialog.cpp dfab3e9ead7d48b8941e4a44d17565c2ea7d4ddb tier1/kwidgetsaddons/src/kpixmapregionselectordialog.cpp 76a52b56190079510e99bd056f7602499f015399 tier1/kwidgetsaddons/src/kselectaction.cpp b388df94baa042e8230f2795f35dd378117c6ab6 tier1/kwidgetsaddons/src/ktoggleaction.cpp 79616dbb37a18b08e9f8a316489cbc8aed8242ba tier1/kwidgetsaddons/src/ktoolbarpopupaction.cpp af1fc2a9470444ba035d8babd9d6aad6a7c05e67 tier1/kwidgetsaddons/tests/kassistantdialogtest.cpp f6be3ef4376dff4f57ac62442e6c55e3a26e12ea tier1/kwidgetsaddons/tests/kcolorcombotest.cpp 825f3a8ab273cbb43c03001d9eb158ad9211e034 tier1/kwidgetsaddons/tests/keditlistwidgettest.cpp 0a0a46b3139eab6441e685e12bd86ec4c8ac5f54 tier1/kwidgetsaddons/tests/kledtest.cpp ee45ab3ab82129f03c8b4a3ce7bda69d0c060dc0 tier1/kwidgetsaddons/tests/kmessagewidgettest.cpp 2d8ab453ebaa736fa7dbf04b10d80ca89ca8bd1b tier1/kwidgetsaddons/tests/kpagewidgettest.cpp 3a10f73a8c481302863cbff52a17a56e167bc2f1 tier1/kwidgetsaddons/tests/kpassivepopuptest.cpp 4e7138523bdbe4166bf0e899d39d9ae1f8b8b447 tier1/kwidgetsaddons/tests/kselectactiontest.cpp f57f6c53098093d0056a1ba4ccfe9fb49338d186 tier1/kwidgetsaddons/tests/ktoolbarlabelactiontest.cpp 8e8cdf06cdaaa684f4659f63fec87d304837746a Diff: http://git.reviewboard.kde.org/r/112032/diff/ Testing --- Compiles and autotests work File Attachments Manual changes performed after tool run http://git.reviewboard.kde.org/media/uploaded/files/2013/08/12/manualChanges_1.diff Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 108845: add support for SSSE3 and SSE4.2 in cpufeatures and for msvc
On Sept. 23, 2013, 9:12 a.m., Kevin Ottens wrote: Any reason why this patch isn't committed yet? Please do so ASAP. Any news? I'll close it as discarded if I don't see any activity by next monday. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108845/#review40505 --- On May 22, 2013, 3:31 p.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108845/ --- (Updated May 22, 2013, 3:31 p.m.) Review request for KDE Frameworks, kdelibs and Patrick von Reth. Repository: kdelibs Description --- This change implements cpu feature checks for MSVC. While at it, I added support SSSE3 and SSE4.2 to the InstructionSets. I took the new values from http://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits . Diffs - tier1/solid/src/solid/processor.h ce4f0e1 tier1/solid/src/solid/backends/shared/cpufeatures.cpp baa1af2 Diff: http://git.reviewboard.kde.org/r/108845/diff/ Testing --- Windows Thanks, Patrick Spendrin ___ 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... Kevin Ottens wrote: Any news about that patch? Is it still an issue? Is it abandoned? FYI, I'll close it as discarded if I don't see any activity by next monday. - 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
kactivities master becomes Qt5/KF5-based
Hi all, Following kde-workspace (and stealing a few sentences from that announcement), we're planning to merge the frameworks-scratch branch of kactivities into master later today. That means if you're building 4.x branch of Plasma yourself from Git, you should switch to the KDE/4.11 branch. The build will fail otherwise, so you will notice. This was a public service announcement. (And you can ask questions here.) If somebody can help with the metadata and kdesrc-build, it would be appreciated - I don't want to screw up something. For the KF5 kdesrc-build, I'm confident I can manage, but for the 4.x branch not so much. Cheers, Ivan -- There are no such things as applied sciences, only applications of science. -- Louis Pasteur ___ 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. Kevin Ottens wrote: Any news about that patch? Should I close this one too next monday? - 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,
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. Kevin Ottens wrote: XCB is less of an issue if that's an optional dependency. Dropped some of the issues to reflect my previous comment. - 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 113155: Port all kde4_add_unit_test uses
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113155/#review42070 --- Any chance to see Alexander comments addressed? - Kevin Ottens On Oct. 10, 2013, 6:08 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113155/ --- (Updated Oct. 10, 2013, 6:08 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Stop using kde4_add_unit_test. One step less towards no kde4_* uses. Diffs - kded/tests/CMakeLists.txt ca392d2 kfile/tests/CMakeLists.txt d28d642 khtml/tests/CMakeLists.txt 59a0a56 kio/tests/CMakeLists.txt a60eac0 kioslave/http/kcookiejar/tests/CMakeLists.txt cb67f26 kioslave/http/tests/CMakeLists.txt 000c488 Diff: http://git.reviewboard.kde.org/r/113155/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 112985: Adjust API in KEmoticons framework: map and index methods
On Oct. 11, 2013, 4:28 p.m., Kevin Ottens wrote: Ship It! Any reason why this patch is not pushed yet? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112985/#review41567 --- 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 113302: Static KEncodingFileDialog in staging/kio
On Oct. 20, 2013, 9:32 a.m., David Faure wrote: OK, I'm just wondering if it still makes sense to make it static-methods-only. It can still very well work the other way, which can allow extra flexibility if needed (e.g. for kate to add another widget into it, or use it non-modal, etc.). What's the reason for making it less flexible? Just the fact that nobody uses the constructor right now? (I assume you checked that?). Kévin? Kevin Ottens wrote: Initially I think I proposed even a namespace. :-) But seeing the current solution I think you're right, we could indeed allow instances to be created. Ok, but that would add some more duplication over what KFileDialog already does. Afaict, the only non-static usage of KEncodingFileDialog was in KMail's messagecomposer. I had checked with kdepim people a while ago, and they have no problem with KEncodingFileDialog becoming static only in KF5. - Teo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42003 --- On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113266: introduce KMessageBoxNotifyInterface to support notifications
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113266/#review42074 --- Ship it! Ship It! - Kevin Ottens On Oct. 16, 2013, 1:35 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113266/ --- (Updated Oct. 16, 2013, 1:35 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- This is a 4-commit request which does the following: - moves plugin handling to kmessagebox_p.* - fixes loading of plugin (library name was wrong) - introduces KMessageBoxNotifyInterface - implements KMessageBoxNotifyInterface in the framework integration plugin. Individual patches are available here: http://agateau.com/tmp/kmessagebox-notification.patch.mbox (apply with `git am`) Diffs - staging/frameworkintegration/src/integrationplugin/CMakeLists.txt d8305bf staging/frameworkintegration/src/integrationplugin/frameworkintegrationplugin.h ccf44d6 staging/frameworkintegration/src/integrationplugin/frameworkintegrationplugin.cpp b8f5fa7 tier1/kwidgetsaddons/src/CMakeLists.txt 50c578a tier1/kwidgetsaddons/src/kmessagebox.h 9a76c23 tier1/kwidgetsaddons/src/kmessagebox.cpp b2345d0 tier1/kwidgetsaddons/src/kmessagebox_p.h PRE-CREATION tier1/kwidgetsaddons/src/kmessagebox_p.cpp PRE-CREATION tier1/kwidgetsaddons/src/kmessageboxnotifyinterface.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113266/diff/ Testing --- Ran kmessageboxtest, heard lots of beeps. 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 113297: Remove 'override' from ThreadWeaver::IdDecorator destructor.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113297/#review42076 --- Ship it! Ship It! - Kevin Ottens On Oct. 17, 2013, 12:08 a.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113297/ --- (Updated Oct. 17, 2013, 12:08 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove 'override' from ThreadWeaver::IdDecorator destructor. MSVC2010 apparently doesn't support 'override' on destructors, even though it's legal according to C++11. Diffs - tier1/threadweaver/src/Weaver/IdDecorator.h 648d4236cc22015a1d145892daf368084a199053 Diff: http://git.reviewboard.kde.org/r/113297/diff/ Testing --- Still builds on Linux, now builds on Windows too. Thanks, Nicolás Alvarez ___ 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/ --- (Updated Oct. 21, 2013, 11:30 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html acb408c 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/#review42075 --- This review has been submitted with commit 858f8cc8702663811ef69b876719b03ff4615409 by Martin Klapetek to branch frameworks. - Commit Hook On Oct. 16, 2013, 7:45 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113181/ --- (Updated Oct. 16, 2013, 7:45 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds part about KDebug Diffs - KDE5PORTING.html acb408c 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 113299: KDirWatch code style: braces for one-liner conditionals
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113299/#review42077 --- I would leave them alone for now. I think we'll revisit the topic of the coding style shortly before the split. It might makes sense now to stick purely to the Qt style for KF5. - Kevin Ottens On Oct. 17, 2013, 4:19 a.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113299/ --- (Updated Oct. 17, 2013, 4:19 a.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- KDirWatch code style: braces for one-liner conditionals Added braces around single-line bodies of conditionals and loops, as specified in the kdelibs coding style. --end of commit message-- As in my previous review about whitespace, I appreciate any feedback; if I added braces where the code looked better without or viceversa, or if I should push this to master too, or if I should leave the damn braces alone and discard the review :) In some simple cases like if (stuff) return; I wasn't sure if it was better to leave it without braces... Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.cpp e4f45441d5ed68e3e34ae2bd68e16fd3dc46656a tier1/kcoreaddons/src/lib/io/kdirwatch_p.h 442d6497b704c179adc13dbb25e450554d31554d Diff: http://git.reviewboard.kde.org/r/113299/diff/ Testing --- It compiles, tests pass. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113298: KDirWatch code style: cleanup whitespace.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113298/#review42078 --- Ship it! Ship It! - Kevin Ottens On Oct. 17, 2013, 7:53 p.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113298/ --- (Updated Oct. 17, 2013, 7:53 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- KDirWatch code style: cleanup whitespace. The KDirWatch code had *lots* of ( foo ) and inconsistent indentation and alignment, including a few tabs(!). This is a full cleanup of it. I appreciate any feedback; if I fixed something that didn't need fixing, or if you see more whitespace errors that I didn't fix, or if I should push this to master too, or if I should leave the damn thing alone and discard the review :) This file is also lacking braces for single-line conditionals and loops; I'll fix that in a separate commit for easier reviewing. It's also mixing 2-space and 4-space indentations, but changing everything to 4 spaces (as the kdelibs coding style says) seemed too intrusive. Perhaps I should change the few 4-space indentations into 2-space for consistency? Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.h 7f6ca8ce83426c81a6336514c247aa9d115ec59e tier1/kcoreaddons/src/lib/io/kdirwatch.cpp e4f45441d5ed68e3e34ae2bd68e16fd3dc46656a tier1/kcoreaddons/src/lib/io/kdirwatch_p.h 442d6497b704c179adc13dbb25e450554d31554d Diff: http://git.reviewboard.kde.org/r/113298/diff/ Testing --- Still compiles :) Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113329: Adapt KSystemTimeZones to new KTimeZoned signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113329/#review42079 --- Ship it! Preemptively giving this one a ship it. Can go in once 113260 is in. - Kevin Ottens On Oct. 18, 2013, 1:04 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113329/ --- (Updated Oct. 18, 2013, 1:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Simple one-liner adapting for change in https://git.reviewboard.kde.org/r/113260/ (waiting to be reviewed) Diffs - staging/kde4attic/src/date/ksystemtimezone.cpp e846247 Diff: http://git.reviewboard.kde.org/r/113329/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 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/#review42081 --- Ship it! Ship It! - Kevin Ottens On Oct. 15, 2013, 6:43 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 15, 2013, 6:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113328: Fix standalone build of kdoctools
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113328/#review42080 --- tier2/kdoctools/CMakeLists.txt http://git.reviewboard.kde.org/r/113328/#comment30677 FOOBAR really? :-) In fact ecm_setup_version might not even be needed for that one, it has no lib, just a runtime tool IIRC. - Kevin Ottens On Oct. 18, 2013, 3:42 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113328/ --- (Updated Oct. 18, 2013, 3:42 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix standalone build of kdoctools: it was not looking for KArchive. This patch also aligns the top-level CMakeLists.txt with template/CMakeLists.txt. Diffs - superbuild/CMakeLists.txt 5cdec94 tier2/kdoctools/CMakeLists.txt 53fd0e9 tier2/kdoctools/src/CMakeLists.txt 8b726a8 Diff: http://git.reviewboard.kde.org/r/113328/diff/ Testing --- Builds within kdelibs and using superbuild. 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 113302: Static KEncodingFileDialog in staging/kio
On Oct. 20, 2013, 9:32 a.m., David Faure wrote: OK, I'm just wondering if it still makes sense to make it static-methods-only. It can still very well work the other way, which can allow extra flexibility if needed (e.g. for kate to add another widget into it, or use it non-modal, etc.). What's the reason for making it less flexible? Just the fact that nobody uses the constructor right now? (I assume you checked that?). Kévin? Kevin Ottens wrote: Initially I think I proposed even a namespace. :-) But seeing the current solution I think you're right, we could indeed allow instances to be created. Teo Mrnjavac wrote: Ok, but that would add some more duplication over what KFileDialog already does. Afaict, the only non-static usage of KEncodingFileDialog was in KMail's messagecomposer. I had checked with kdepim people a while ago, and they have no problem with KEncodingFileDialog becoming static only in KF5. I'm not sure which kind of duplication you have in mind, but surely just making the ctor/dtor pair public and adding a result() public method would be enough (said method you could use in your static methods BTW reducing some of the code duplication between them). - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42003 --- On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113148: Move and clean KBuildsycoca to KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/#review42083 --- Ship it! Ship It! - Kevin Ottens On Oct. 21, 2013, 10:22 a.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/ --- (Updated Oct. 21, 2013, 10:22 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moved KBuildsyscoca to KService. I have done the moving and the cleaning in different commits, just unified them for reviewboard. Diffs - kded/CMakeLists.txt 3aba077 kded/applications.menu kded/kbuildmimetypefactory.h kded/kbuildmimetypefactory.cpp 2e81ce7 kded/kbuildservicefactory.h kded/kbuildservicefactory.cpp 971f327 kded/kbuildservicegroupfactory.h kded/kbuildservicegroupfactory.cpp 5485b1c kded/kbuildservicetypefactory.h kded/kbuildservicetypefactory.cpp f473cd6 kded/kbuildsycoca.h kded/kbuildsycoca.cpp 8ea2d2e kded/kbuildsycocainterface.h kded/kctimefactory.h kded/kctimefactory.cpp kded/kmimeassociations.h kded/kmimeassociations.cpp kded/ksycocaresourcelist.h kded/tests/CMakeLists.txt da51ed4 kded/tests/kmimeassociationstest.cpp kded/vfolder_menu.h kded/vfolder_menu.cpp staging/kservice/CMakeLists.txt 4e8dbd2 staging/kservice/kbuildsycoca/CMakeLists.txt PRE-CREATION staging/kservice/tests/CMakeLists.txt 23d4854 Diff: http://git.reviewboard.kde.org/r/113148/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: kactivities master becomes Qt5/KF5-based
Please no. We have a 4.12 release to make in 2 weeks and back when we did the 4.12 planning the only agreed repo to be freezed for 4.11 was kde-workspace. What about doing an early KDE/4.12 branch from master so that the release can continue as planned, while not slowing us down for further development? Cheers, Ivan -- Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113302: Static KEncodingFileDialog in staging/kio
On Oct. 20, 2013, 9:32 a.m., David Faure wrote: OK, I'm just wondering if it still makes sense to make it static-methods-only. It can still very well work the other way, which can allow extra flexibility if needed (e.g. for kate to add another widget into it, or use it non-modal, etc.). What's the reason for making it less flexible? Just the fact that nobody uses the constructor right now? (I assume you checked that?). Kévin? Kevin Ottens wrote: Initially I think I proposed even a namespace. :-) But seeing the current solution I think you're right, we could indeed allow instances to be created. Teo Mrnjavac wrote: Ok, but that would add some more duplication over what KFileDialog already does. Afaict, the only non-static usage of KEncodingFileDialog was in KMail's messagecomposer. I had checked with kdepim people a while ago, and they have no problem with KEncodingFileDialog becoming static only in KF5. Kevin Ottens wrote: I'm not sure which kind of duplication you have in mind, but surely just making the ctor/dtor pair public and adding a result() public method would be enough (said method you could use in your static methods BTW reducing some of the code duplication between them). OK, discussing with Teo on IRC I think he's right. We could make it instanciable with what I propose... but then if you want a proper API you need accessors for a few properties, and signals when the user interact with the dialog etc. We'd basically duplicate quite some KFileDialog code... which was API not used in the case of KEncodingFileDialog. So he's right, let's keep it based on static alone. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42003 --- On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113302: Static KEncodingFileDialog in staging/kio
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42085 --- Ship it! I think it's OK to keep it based only on statics. As such we can go for it. staging/kio/src/filewidgets/kencodingfiledialog.cpp http://git.reviewboard.kde.org/r/113302/#comment30678 I still think this clock duplication could be removed by adding an internal result() method which does just that. I'll leave it to your judgment to add it or not. :-) - Kevin Ottens On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113302: Static KEncodingFileDialog in staging/kio
On Oct. 21, 2013, 12:05 p.m., Kevin Ottens wrote: I think it's OK to keep it based only on statics. As such we can go for it. OK, let's go for static methods only then. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/#review42085 --- On Oct. 19, 2013, 11:30 a.m., Teo Mrnjavac wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 19, 2013, 11:30 a.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
On Oct. 16, 2013, 12:15 p.m., John Layt wrote: Wow, there sure is a lot of code in there catering for all the possible corner cases :-) QTimeZone has a lot less places it checks, so I'll need to do an in-depth comparison, but given Qt5 will only support modern distros I think most of it is redundant. One thought is if we still want to have a signal that the system database has been updated? While Qt doesn't cache the time zone data, the apps probably will cache the QTimeZone instances themselves and may need to be told that the database has changed so they can take action. Then again, it's not something that will happen very often, and what will the apps do in response? If they refresh their cache the shared copies in QDateTime won't update. I guess QTimeZone will need a reloadData() method added instead. I've looked at the Windows code and it mostly looks OK, all it does is monitor the registry for changes. What you do need to change is the DBus signal from configChanged to your new timeZoneChanged signal. With regards the signal name change, does it need to go in the porting guide or somewhere so people know it has changed? In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need the daemon for now. Martin Klapetek wrote: Wow, there sure is a lot of code in there catering for all the possible corner cases :-) QTimeZone has a lot less places it checks, so I'll need to do an in-depth comparison, but given Qt5 will only support modern distros I think most of it is redundant. Part of that is support for Solaris, but I see Solaris is not supported by Qt anymore [1][2], so I just removed it altogether. One thought is if we still want to have a signal that the system database has been updated? While Qt doesn't cache the time zone data, the apps probably will cache the QTimeZone instances themselves and may need to be told that the database has changed so they can take action. I think it might be worth having it...I'll add it back, can't hurt :) I've looked at the Windows code and it mostly looks OK, all it does is monitor the registry for changes. What you do need to change is the DBus signal from configChanged to your new timeZoneChanged signal. Ah yes, I forgot to add that to the patch, sorry. With regards the signal name change, does it need to go in the porting guide or somewhere so people know it has changed? I wanted to add it, but that's in kdelibs. Question is, should there be a guide for runtime/workspace too? In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need the daemon for now. Ok, keep us posted. (It would be cool to have cross-desktop solution for this too...or system-wide spec at least, so we could use non-qt/-kde apps still supporting timezone changes, but oh well). [1] - http://qt-project.org/doc/qt-5.1/qtdoc/supported-platforms.html [2] - http://qt.digia.com/Product/Supported-Platforms/ David Faure wrote: There are still people around with a Solaris system. Not supported doesn't mean we should actively remove existing support, IMHO. About the porting guide: the distinction between kdelibs and kde-runtime will disappear, given the framework-ification. So treat it as a porting guide from kde 4 to kde-frameworks, i.e. it's fine to include runtime stuff in there. About a solution in Qt --- that means each and every Qt app will have to monitor the same timezone file(s), isn't that a bit too expensive? (not sure, just wondering) Martin Klapetek wrote: There are still people around with a Solaris system. Not supported doesn't mean we should actively remove existing support, IMHO. Is there any attempt to make sure KF5/PW2 is working with Solaris? Because if the underlying components won't work on Solaris, there's no point in keeping Solaris code in one tiny module sitting on top of the bigger blocks. it's fine to include runtime stuff in there. Cool, will add it then :) I'm not sure Qt5 even compiles on Solaris, and it might be hard to convince Thiago to accept code for it, but I can ask what the status there is. The alternative is to have timeZone() and listTimeZones() calls in ktimezoned that wrap the Qt or Solaris calls. As for Qt monitoring the time zones: yes that would probably be the end result which is not ideal, but AFAIK we can't use a daemon inside Qt, or call dbus inside QtCore which rules out using ktimezoned if it's running, or systemd if it ever adds this feature. I have to post to the development list the design proposal for it and see if it gets shot down or not. - John
Review Request 113365: Fix #include kdesu_export.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113365/ --- Review request for KDE Frameworks and Martin Klapetek. Repository: kdelibs Description --- kdesu headers are installed to kdesu/ so the #include kdesu_export.h cannot be found if one tries to use kdesu includes in a project. Diffs - tier3/kdesu/src/client.h 8f29b93 tier3/kdesu/src/process.h c527e83 tier3/kdesu/src/ssh.h 8ab6472 tier3/kdesu/src/stub.h 68d7440 tier3/kdesu/src/su.h e83781d Diff: http://git.reviewboard.kde.org/r/113365/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113302: Static KEncodingFileDialog in staging/kio
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113302/ --- (Updated Oct. 21, 2013, 12:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- This makes KEncodingFileDialog static, moves it to staging/kio and moves some stuff from KFileDialog to KFileWidget to reduce duplication. Diffs - kio/CMakeLists.txt ac80e393c877280dd8033ec13e8e772afea6d2f9 kio/kfile/kencodingfiledialog.h abb939abeb000126005f1a1a9c6fd50b8bd322bd kio/kfile/kencodingfiledialog.cpp d55d908473aae2859838d88fd776cc65cecf3317 kio/kfile/kfiledialog.cpp 32eb98a4490a31c5ed51150ca3cb7af5375dc67e staging/kio/src/filewidgets/CMakeLists.txt e8d8c2edf11ad6352e13eb6e7436f828a4a55e3a staging/kio/src/filewidgets/kencodingfiledialog.cpp PRE-CREATION staging/kio/src/filewidgets/kfilewidget.h f7b162ab39b997274b21f9eff0c6374545e0a9ad staging/kio/src/filewidgets/kfilewidget.cpp 824ac563f3f8c463426f0a45e792f107ac402a40 Diff: http://git.reviewboard.kde.org/r/113302/diff/ Testing --- Seems to work fine in a test app. Thanks, Teo Mrnjavac ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[kdelibs/frameworks] staging/kio/src/core: Add include/KDE to users of KIOCore.
Git commit 5e9404239fb974973e8a253444131884954ede77 by Stephen Kelly.
Committed on 21/10/2013 at 12:49.
Pushed by skelly into branch 'frameworks'.
Add include/KDE to users of KIOCore.
Note that this really only hides the problem. There are several problems
with the KF5 includes, and several patches in review which also don't
fully solve the problem.
What is needed is to figure out
* Where are headers installed to?
* How are users supposed to use them?
* What include paths do users need to use?
For example, if kfoo installs
include/kfoo/job.h
include/kfoo/kfoo_export.h
and users are supposed to use:
.#include kfoo/job.h
but job.h #includes kfoo_export.h
then users need both
include/
include/kfoo/
when compiling. That seems to be the case at some points in KDE
frameworks, and it is more-likely accidental than intentional.
That should be reviewed.
CCMAIL: kde-frameworks-devel@kde.org
M +1-0staging/kio/src/core/CMakeLists.txt
http://commits.kde.org/kdelibs/5e9404239fb974973e8a253444131884954ede77
diff --git a/staging/kio/src/core/CMakeLists.txt
b/staging/kio/src/core/CMakeLists.txt
index 273086f..03a892b 100644
--- a/staging/kio/src/core/CMakeLists.txt
+++ b/staging/kio/src/core/CMakeLists.txt
@@ -108,6 +108,7 @@ target_include_directories(KIOCore PUBLIC
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/.. # kio_version.h
$BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/kssl
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/../include # kio/global.h
+ $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/KDE # KIO/Job
)
target_link_libraries(KIOCore
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113328: Fix standalone build of kdoctools
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113328/ --- (Updated Oct. 21, 2013, 3:32 p.m.) Review request for KDE Frameworks. Changes --- No need to call ecm_setup_version() in kdoctools, it's not a library. Repository: kdelibs Description --- Fix standalone build of kdoctools: it was not looking for KArchive. This patch also aligns the top-level CMakeLists.txt with template/CMakeLists.txt. Diffs (updated) - superbuild/CMakeLists.txt 5cdec94 tier2/kdoctools/CMakeLists.txt 53fd0e9 tier2/kdoctools/src/CMakeLists.txt 8b726a8 Diff: http://git.reviewboard.kde.org/r/113328/diff/ Testing --- Builds within kdelibs and using superbuild. 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 113328: Fix standalone build of kdoctools
On Oct. 21, 2013, 1:43 p.m., Kevin Ottens wrote: tier2/kdoctools/CMakeLists.txt, line 18 http://git.reviewboard.kde.org/r/113328/diff/2/?file=203416#file203416line18 FOOBAR really? :-) In fact ecm_setup_version might not even be needed for that one, it has no lib, just a runtime tool IIRC. Oups, copy'n'paste from template is dangerous :) Anyway you are right, ecm_setup_version() is not needed here, just updated the request. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113328/#review42080 --- On Oct. 21, 2013, 3:32 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113328/ --- (Updated Oct. 21, 2013, 3:32 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix standalone build of kdoctools: it was not looking for KArchive. This patch also aligns the top-level CMakeLists.txt with template/CMakeLists.txt. Diffs - superbuild/CMakeLists.txt 5cdec94 tier2/kdoctools/CMakeLists.txt 53fd0e9 tier2/kdoctools/src/CMakeLists.txt 8b726a8 Diff: http://git.reviewboard.kde.org/r/113328/diff/ Testing --- Builds within kdelibs and using superbuild. 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 113148: Move and clean KBuildsycoca to KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/ --- (Updated Oct. 21, 2013, 2:09 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Moved KBuildsyscoca to KService. I have done the moving and the cleaning in different commits, just unified them for reviewboard. Diffs - kded/CMakeLists.txt 3aba077 kded/applications.menu kded/kbuildmimetypefactory.h kded/kbuildmimetypefactory.cpp 2e81ce7 kded/kbuildservicefactory.h kded/kbuildservicefactory.cpp 971f327 kded/kbuildservicegroupfactory.h kded/kbuildservicegroupfactory.cpp 5485b1c kded/kbuildservicetypefactory.h kded/kbuildservicetypefactory.cpp f473cd6 kded/kbuildsycoca.h kded/kbuildsycoca.cpp 8ea2d2e kded/kbuildsycocainterface.h kded/kctimefactory.h kded/kctimefactory.cpp kded/kmimeassociations.h kded/kmimeassociations.cpp kded/ksycocaresourcelist.h kded/tests/CMakeLists.txt da51ed4 kded/tests/kmimeassociationstest.cpp kded/vfolder_menu.h kded/vfolder_menu.cpp staging/kservice/CMakeLists.txt 4e8dbd2 staging/kservice/kbuildsycoca/CMakeLists.txt PRE-CREATION staging/kservice/tests/CMakeLists.txt 23d4854 Diff: http://git.reviewboard.kde.org/r/113148/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 113148: Move and clean KBuildsycoca to KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/#review42095 --- This review has been submitted with commit 4c47af4414c11a8fb0d5dc0a5750eda024e88feb by Àlex Fiestas to branch frameworks. - Commit Hook On Oct. 21, 2013, 10:22 a.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/ --- (Updated Oct. 21, 2013, 10:22 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moved KBuildsyscoca to KService. I have done the moving and the cleaning in different commits, just unified them for reviewboard. Diffs - kded/CMakeLists.txt 3aba077 kded/applications.menu kded/kbuildmimetypefactory.h kded/kbuildmimetypefactory.cpp 2e81ce7 kded/kbuildservicefactory.h kded/kbuildservicefactory.cpp 971f327 kded/kbuildservicegroupfactory.h kded/kbuildservicegroupfactory.cpp 5485b1c kded/kbuildservicetypefactory.h kded/kbuildservicetypefactory.cpp f473cd6 kded/kbuildsycoca.h kded/kbuildsycoca.cpp 8ea2d2e kded/kbuildsycocainterface.h kded/kctimefactory.h kded/kctimefactory.cpp kded/kmimeassociations.h kded/kmimeassociations.cpp kded/ksycocaresourcelist.h kded/tests/CMakeLists.txt da51ed4 kded/tests/kmimeassociationstest.cpp kded/vfolder_menu.h kded/vfolder_menu.cpp staging/kservice/CMakeLists.txt 4e8dbd2 staging/kservice/kbuildsycoca/CMakeLists.txt PRE-CREATION staging/kservice/tests/CMakeLists.txt 23d4854 Diff: http://git.reviewboard.kde.org/r/113148/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
On Oct. 9, 2013, 6:39 p.m., Kevin Ottens wrote: Any news about that patch? It hasn't seen activity lately. Kevin Ottens wrote: Anybody home? FYI I'll close it as discarded if it doesn't have any activity by next monday. hey, I'm going to pick it up again! Just had been busy on kde-workspace. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112755/#review41439 --- On Sept. 17, 2013, 7: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, 7: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: Fwd: Failing Tests in Kross
Hey everyone I managed to contact Sebastian through his kdab email account. I've attached the response below. On Fri, Oct 18, 2013 at 3:13 AM, Sebastian Sauer sebastian.sa...@kdab.com wrote: On 10/16/2013 03:15 PM, Vishesh Handa wrote: Hey Sebastian Aloha Vishesh :) If you get some free time could you please have a look at the tests? Unfortunately I don't have a working kf5 setup, there are no packages for my distribution and keeping up with kf5 development is near impossible for me having a fulltime-job and family. The following tests FAILED: 1 - kross-guiform-py (Failed) 2 - kross-guiform-rb (Failed) 3 - kross-guiqt-py (Failed) 4 - kross-guiqt-rb (Failed) 5 - kross-guitk-py (Failed) 7 - kross-test-py (Failed) hmmm... 8 - kross-unittest-es (SEGFAULT) *.es is QtScript. There may have been some incompatible changes in Qt5. 9 - kross-unittest-js (SEGFAULT) *.js is KJS and KjsEmbed. Just delete them. They never got into a quality state. 10 - kross-unittest-py (Failed) 11 - kross-unittest-rb (Failed) Ruby and Python. I saw some weeks ago that Red Hat did some patches to port the ruby backend to latest ruby. Not sure who took over Python but there where a few patches last years from others. The test in the qts plugin also segfaults. That's Qt5 QtScript? hmpf :( The python and ruby tests fail because of the missing kross plugin. Those are the only two important backends. However the js/es ones seem to segault. Delete it (the test and kjs-backend in kross) and also delete kjsembed from kdelibs. iirc I was official(?) maintainer of all of that :) Rich Moore, who pushed it to kdelibs back then, suggested deletion at the kjsembed mailinglist some years ago, then Matt Bratstone and me took over and I think I am the only one left. Do you think you could have a look at them? I'm not comfortable moving it to tier3 with failing tests. Unfortunately I have no time and while I hack a lot on Qt its 99% Qt4 related. So, even my Qt5 setup is outdated already (for kf5 which iirc requires latest/greatest Qt 5.2) and so is my cmake, cmakeextras, all dependencies, etc. kf5 moves to fast if you only have 1h/week so I decided to better spend my time on Calligra. There also seems to be a .ui file in the tests directory, which I'm not sure how to run. Those are not for run as in auto-tests but are manual tests used in the kross-gui* scripts (which are not auto-tests as in unittests too but manual-tests as in start a GUI for clicking and testing manually). When Kross moves to its own git repo we should probably move the ruby and python plugin in it as well. Makes sense. Also, can I add a MAINTAINERS file with your name in it? I don't think I will have enough time anytime soon. Probably once there are kf5 packages or once kross can be build standalone without kf5 dependencies (it used to be that way, means tear1, when I hacked last on it). -- Best regards Sebastian Sauer | sebastian.sa...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Failing Tests in Kross
Aloha Sebastian :D On Fri, Oct 18, 2013 at 3:13 AM, Sebastian Sauer sebastian.sa...@kdab.com wrote: Aloha Vishesh :) Unfortunately I don't have a working kf5 setup, there are no packages for my distribution and keeping up with kf5 development is near impossible for me having a fulltime-job and family. That's alright. The following tests FAILED: 1 - kross-guiform-py (Failed) 2 - kross-guiform-rb (Failed) 3 - kross-guiqt-py (Failed) 4 - kross-guiqt-rb (Failed) 5 - kross-guitk-py (Failed) 7 - kross-test-py (Failed) hmmm... 8 - kross-unittest-es (SEGFAULT) *.es is QtScript. There may have been some incompatible changes in Qt5. 9 - kross-unittest-js (SEGFAULT) *.js is KJS and KjsEmbed. Just delete them. They never got into a quality state. Alright. I'll remove them. 10 - kross-unittest-py (Failed) 11 - kross-unittest-rb (Failed) Ruby and Python. I saw some weeks ago that Red Hat did some patches to port the ruby backend to latest ruby. Not sure who took over Python but there where a few patches last years from others. However the js/es ones seem to segault. Delete it (the test and kjs-backend in kross) and also delete kjsembed from kdelibs. iirc I was official(?) maintainer of all of that :) Rich Moore, who pushed it to kdelibs back then, suggested deletion at the kjsembed mailinglist some years ago, then Matt Bratstone and me took over and I think I am the only one left. KJsEmbed has been currently moved to tier3. Considering that it also doesn't have a maintainer, maybe we should just let it die instead of removing it? Opinions? Unfortunately I have no time and while I hack a lot on Qt its 99% Qt4 related. So, even my Qt5 setup is outdated already (for kf5 which iirc requires latest/greatest Qt 5.2) and so is my cmake, cmakeextras, all dependencies, etc. kf5 moves to fast if you only have 1h/week so I decided to better spend my time on Calligra. Of course. A large part of that one hour would also be spent in getting everything to compile. Also, can I add a MAINTAINERS file with your name in it? I don't think I will have enough time anytime soon. Probably once there are kf5 packages or once kross can be build standalone without kf5 dependencies (it used to be that way, means tear1, when I hacked last on it). We'll need to find another maintainer then :/ -- Best regards Sebastian Sauer | sebastian.sa...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
cyclic dependency kinit - kservice
kinit needs kservice and installs KInitMacros.cmake which defines kf5_add_kdeinit_executable which is needed by kservice/kbuildsycoca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 108845: add support for SSSE3 and SSE4.2 in cpufeatures and for msvc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108845/ --- (Updated Oct. 21, 2013, 3:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kdelibs and Patrick von Reth. Repository: kdelibs Description --- This change implements cpu feature checks for MSVC. While at it, I added support SSSE3 and SSE4.2 to the InstructionSets. I took the new values from http://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits . Diffs - tier1/solid/src/solid/processor.h ce4f0e1 tier1/solid/src/solid/backends/shared/cpufeatures.cpp baa1af2 Diff: http://git.reviewboard.kde.org/r/108845/diff/ Testing --- Windows Thanks, Patrick Spendrin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 108845: add support for SSSE3 and SSE4.2 in cpufeatures and for msvc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108845/#review42107 --- This review has been submitted with commit 88bf26e1bc2bb3ac8a3744ba5806eb5f8edcbfb9 by Michael Pyne on behalf of Patrick Spendrin to branch frameworks. - Commit Hook On May 22, 2013, 3:31 p.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108845/ --- (Updated May 22, 2013, 3:31 p.m.) Review request for KDE Frameworks, kdelibs and Patrick von Reth. Repository: kdelibs Description --- This change implements cpu feature checks for MSVC. While at it, I added support SSSE3 and SSE4.2 to the InstructionSets. I took the new values from http://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_Bits . Diffs - tier1/solid/src/solid/processor.h ce4f0e1 tier1/solid/src/solid/backends/shared/cpufeatures.cpp baa1af2 Diff: http://git.reviewboard.kde.org/r/108845/diff/ Testing --- Windows Thanks, Patrick Spendrin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: cyclic dependency kinit - kservice
On Monday 21 October 2013 17:01:44 Treeve Jelbert wrote: kinit needs kservice and installs KInitMacros.cmake which defines kf5_add_kdeinit_executable which is needed by kservice/kbuildsycoca Well, spotted, missed that one in the review. Alex could you look into solving this cycle? Thanks in advance. 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
Re: kactivities master becomes Qt5/KF5-based
Hi all, Following kde-workspace (and stealing a few sentences from that announcement), we're planning to merge the frameworks-scratch branch of kactivities into master later today. That means if you're building 4.x branch of Plasma yourself from Git, you should switch to the KDE/4.11 branch. The build will fail otherwise, so you will notice. This was a public service announcement. (And you can ask questions here.) Please no. We have a 4.12 release to make in 2 weeks and back when we did the 4.12 planning the only agreed repo to be freezed for 4.11 was kde-workspace. Cheers, Albert If somebody can help with the metadata and kdesrc-build, it would be appreciated - I don't want to screw up something. For the KF5 kdesrc-build, I'm confident I can manage, but for the 4.x branch not so much. Cheers, Ivan -- There are no such things as applied sciences, only applications of science. -- Louis Pasteur ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
El Dilluns, 21 d'octubre de 2013, a les 14:02:42, Ivan Čukić va escriure: Please no. We have a 4.12 release to make in 2 weeks and back when we did the 4.12 planning the only agreed repo to be freezed for 4.11 was kde-workspace. What about doing an early KDE/4.12 branch from master so that the release can continue as planned, while not slowing us down for further development? I was planning to branch master into KDE/4.12 after October 30 and before November 6. Would that work for you? Also it means that you don't want a 4.13.x for kactivities, right? Cheers, Albert Cheers, Ivan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
I was planning to branch master into KDE/4.12 after October 30 and before November 6. Forget about it. Decided not to create problems - I'll use the same name for the branch as kdelibs do for the time being - frameworks :) Also it means that you don't want a 4.13.x for kactivities, right? Yes. The development of 4.x branch is frozen for some time now. -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
El Dilluns, 21 d'octubre de 2013, a les 18:43:20, Ivan Čukić va escriure: I was planning to branch master into KDE/4.12 after October 30 and before November 6. Forget about it. Decided not to create problems - I'll use the same name for the branch as kdelibs do for the time being - frameworks :) Also it means that you don't want a 4.13.x for kactivities, right? Yes. The development of 4.x branch is frozen for some time now. Well, to be honest, if you don't want a 4.13 release i'd prefer you actually use master for KF5. Otherwise people might random-commit fixes to master and then wonder why they never got into a release, so the two situations i think make sense are: A) wait until we branch KDE/4.12 and then use master for KF5, not release kactivities 4.13 and maybe release more 4.12.x of kactivities than the rest of the SC if there are fixes for it or B) use frameworks for KF5, keep master open for 4.13 and just release it like the rest of the SC for 4.13 even if there were no changes. I do think A) makes sense if you don't have a focus on 4.x anymore. Am I making any sense? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
Well, to be honest, if you don't want a 4.13 release i'd prefer you actually use master for KF5. Otherwise people might random-commit fixes to master and then wonder why they never got into a release, so the two situations i think make sense are: People don't really contribute to kactivities, but I agree. A) wait until we branch KDE/4.12 and then use master for KF5, not release kactivities 4.13 and maybe release more 4.12.x of kactivities than the rest of the SC if there are fixes for it This is what I was thinking of - until we branch, the branch is called frameworks, and after that it will be moved to master. Am I making any sense? Perfect sense, as usual mate :) Cheers, Ivan -- So much complexity in software comes from trying to make one thing do two things. -- Ryan Singer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113365: Fix #include kdesu_export.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113365/#review42119 --- Ship it! Looks sane, and builds fine even when I remove the installed kdesu/kdesu_export.h file. - Alex Merry On Oct. 21, 2013, 12:27 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113365/ --- (Updated Oct. 21, 2013, 12:27 p.m.) Review request for KDE Frameworks and Martin Klapetek. Repository: kdelibs Description --- kdesu headers are installed to kdesu/ so the #include kdesu_export.h cannot be found if one tries to use kdesu includes in a project. Diffs - tier3/kdesu/src/client.h 8f29b93 tier3/kdesu/src/process.h c527e83 tier3/kdesu/src/ssh.h 8ab6472 tier3/kdesu/src/stub.h 68d7440 tier3/kdesu/src/su.h e83781d Diff: http://git.reviewboard.kde.org/r/113365/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Config files naming policy
On Monday 21 October 2013, Ivan Čukić wrote: Hi all, Since we are now sharing the locations of our configs with non-kde software, we can potentially get collisions with those. I'm proposing changing the names of the config files to org.kde.something (or some other alternative). do you mean the Config.cmake files or application configuration files ? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 21, 2013, 6:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/#review42122 --- This review has been submitted with commit a959675fb3ca4d936cd6f8aeff437a1a444b7c38 by Volker Krause to branch frameworks. - Commit Hook On Oct. 15, 2013, 6:43 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 15, 2013, 6:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdelibs/frameworks] staging/kio/src/core: Add include/KDE to users of KIOCore.
On Mon, Oct 21, 2013 at 2:54 PM, Stephen Kelly steve...@gmail.com wrote:
Git commit 5e9404239fb974973e8a253444131884954ede77 by Stephen Kelly.
Committed on 21/10/2013 at 12:49.
Pushed by skelly into branch 'frameworks'.
Add include/KDE to users of KIOCore.
Note that this really only hides the problem. There are several problems
with the KF5 includes, and several patches in review which also don't
fully solve the problem.
What is needed is to figure out
* Where are headers installed to?
* How are users supposed to use them?
* What include paths do users need to use?
For example, if kfoo installs
include/kfoo/job.h
include/kfoo/kfoo_export.h
and users are supposed to use:
.#include kfoo/job.h
but job.h #includes kfoo_export.h
then users need both
include/
include/kfoo/
when compiling. That seems to be the case at some points in KDE
frameworks, and it is more-likely accidental than intentional.
That should be reviewed.
CCMAIL: kde-frameworks-devel@kde.org
M +1-0staging/kio/src/core/CMakeLists.txt
http://commits.kde.org/kdelibs/5e9404239fb974973e8a253444131884954ede77
diff --git a/staging/kio/src/core/CMakeLists.txt
b/staging/kio/src/core/CMakeLists.txt
index 273086f..03a892b 100644
--- a/staging/kio/src/core/CMakeLists.txt
+++ b/staging/kio/src/core/CMakeLists.txt
@@ -108,6 +108,7 @@ target_include_directories(KIOCore PUBLIC
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/.. # kio_version.h
$BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/kssl
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/../include #
kio/global.h
+ $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/KDE # KIO/Job
)
target_link_libraries(KIOCore
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
FWIW, KDE/ should be added to most modules then...
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Config files naming policy
do you mean the Config.cmake files or application configuration files ? The application configuration files. Ivan -- When the pupil is ready to learn, a teacher will appear. -- Basho ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42126 --- As the next CMake release will have a better solution which works for all compilers: set(CMAKE_CXX_STANDARD 11) I'm not in favor of adding and having to support this flag. I don't consider it my decision though. - Stephen Kelly On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 7:18 p.m., Stephen Kelly wrote: As the next CMake release will have a better solution which works for all compilers: set(CMAKE_CXX_STANDARD 11) I'm not in favor of adding and having to support this flag. I don't consider it my decision though. Are we going to be able to depend on that version of cmake for the initial kf5 release? - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42126 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. - Stephen Kelly On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: plasma-framework_master_qt5 #825
See http://build.kde.org/job/plasma-framework_master_qt5/825/changes Changes: [notmart] get rid of WidgetExplorerView -- [...truncated 326 lines...] Generating moc_storagetest.cpp Generating mouseeventlistener.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/mouseeventlistener.cpp:0: Note: No relevant classes found. No output generated. [ 7%] Built target storagetest_automoc Scanning dependencies of target platformcomponentsplugin_automoc [ 7%] Automoc for target platformcomponentsplugin Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Generating moc_DeclarativeDragArea.cpp Generating moc_DeclarativeDragDropEvent.cpp Generating moc_DeclarativeDropArea.cpp Generating moc_DeclarativeMimeData.cpp Generating moc_draganddropplugin.cpp [ 7%] Built target draganddropplugin_automoc Generating moc_modeltest.cpp Generating moc_columnproxymodel.cpp Generating moc_columnproxymodeltest.cpp [ 7%] Scanning dependencies of target localebindingsplugin_automoc Built target fullmodelaccesstest_automoc [ 8%] Automoc for target localebindingsplugin Scanning dependencies of target calendarplugin_automoc Generating plasmaextracomponentsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmaextracomponents/plasmaextracomponentsplugin.cpp:0: Note: No relevant classes found. No output generated. Generating moc_enums.cpp Generating moc_plasmacomponentsplugin.cpp Generating qmenu.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qmenu.cpp:0: Note: No relevant classes found. No output generated. [ 8%] Automoc for target calendarplugin Generating qiconitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qiconitem.cpp:0: Note: No relevant classes found. No output generated. Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating qmenuitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qmenuitem.cpp:0: Note: No relevant classes found. No output generated. Generating moc_fallbackcomponent.cpp Generating moc_plasmaextracomponentsplugin.cpp [ 8%] Built target plasmaextracomponentsplugin_automoc Generating qimageitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qimageitem.cpp:0: Note: No relevant classes found. No output generated. Scanning dependencies of target plasmapkg_automoc [ 8%] Automoc for target plasmapkg Generating platformextensionplugin.moc Generating moc_application.cpp Generating moc_application_p.cpp [ 8%] Built target platformcomponentsplugin_automoc Scanning dependencies of target kded_platformstatus_automoc [ 8%] Automoc for target kded_platformstatus Generating sortfiltermodeltest.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/tests/sortfiltermodeltest.cpp:0: Note: No relevant classes found. No output generated. Generating qrangemodel.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qrangemodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_plasmapkg.cpp [ 8%] Built target plasmapkg_automoc Generating localebindingsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/locale/localebindingsplugin.cpp:0: Note: No relevant classes found. No output generated. Generating qpixmapitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qpixmapitem.cpp:0: Note: No relevant classes found. No output generated. Scanning dependencies of target plasma_appletscript_declarative_automoc Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. [ 9%] Automoc for target plasma_appletscript_declarative Generating platformstatus.moc QIODevice::read: device not open Generating moc_calendarplugin.cpp Generating moc_calendar.cpp Generating moc_calendardata.cpp Generating moc_daysmodel.cpp [ 9%] Built target calendarplugin_automoc Scanning dependencies of target PlasmaQuick_automoc [ 10%] Automoc for target PlasmaQuick Generating units.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/units.cpp:0: Note: No relevant classes found. No output generated. Generating moc_platformstatus.cpp [ 10%] Built target kded_platformstatus_automoc Scanning dependencies of target packageurlinterceptortest_automoc [ 11%] Generating qtextracomponentsplugin.moc
Build failed in Jenkins: plasma-framework_master_qt5 #826
See http://build.kde.org/job/plasma-framework_master_qt5/826/changes Changes: [notmart] use the ctivity class and Kactivities [notmart] make activity switching work [notmart] link to KF5::KActivities [notmart] activity switching animation [notmart] a toggleActivityManager action -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 3 in workspace http://build.kde.org/job/plasma-framework_master_qt5/ws/ Running Prebuild steps [plasma-framework_master_qt5] $ /bin/sh -xe /tmp/hudson3843683886796918208.sh + /home/jenkins/scripts/setup-env.sh From git://anongit.kde.org/plasma-framework 876ade8..9284733 master - origin/master The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch jenkins set up to track remote branch master from origin. Success build forhudson.tasks.Shell@434d4f2b Checkout:plasma-framework_master_qt5 / http://build.kde.org/job/plasma-framework_master_qt5/ws/ - hudson.remoting.Channel@699d7f6d:LinuxSlave - 3 Using strategy: Default Last Built Revision: Revision 876ade83a0adbd87d22e8f9685bc2e976767655a (refs/heads/jenkins) Fetching changes from 1 remote Git repository Fetching upstream changes from origin Commencing build of Revision 92847333a03969fe7224360f45f28625cefe9a0d (refs/heads/jenkins) Checking out Revision 92847333a03969fe7224360f45f28625cefe9a0d (refs/heads/jenkins) [plasma-framework_master_qt5] $ /bin/sh -xe /tmp/hudson9090509545224693268.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: extra-cmake-modules - Branch master attica - Branch master kdelibs - Branch frameworks phonon - Branch master qt5 - Branch stable strigidaemon - Branch master strigiclient - Branch master strigiutils - Branch master libstreams - Branch master libstreamanalyzer - Branch master == Cleaning Source Tree HEAD is now at 9284733 Merge branch 'mart/useActivities' Removing build/ == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- KF5[InstallDirs]: Loaded settings from /srv/jenkins/install/linux/x86_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDEInstallDirs.cmake -- KF5[CMake]: Loaded settings from /srv/jenkins/install/linux/x86_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDECMakeSettings.cmake -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success -- KF5[Compiler]: Loaded settings from /srv/jenkins/install/linux/x86_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDECompilerSettings.cmake -- KF5[KIdleTime]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KIdleTime/KIdleTimeConfig.cmake -- KF5[ItemModels]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/ItemModels/ItemModelsConfig.cmake -- KF5[KWidgetsAddons]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KWidgetsAddons/KWidgetsAddonsConfig.cmake -- KF5[KWindowSystem]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KWindowSystem/KWindowSystemConfig.cmake -- KF5[KCodecs]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KCodecs/KCodecsConfig.cmake -- KF5[KArchive]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KArchive/KArchiveConfig.cmake -- KF5[KCoreAddons]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/KCoreAddons/KCoreAddonsConfig.cmake -- KF5[Solid]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/Solid/SolidConfig.cmake -- KF5[ThreadWeaver]: Loaded /srv/jenkins/install/linux/x86_64/g++/qt5/kde/kdelibs/frameworks/lib64/cmake/ThreadWeaver/ThreadWeaverConfig.cmake -- KF5[KConfig]: Loaded
Build failed in Jenkins: plasma-framework_master_qt5 #827
See http://build.kde.org/job/plasma-framework_master_qt5/827/changes Changes: [aleixpol] Stop using Qt5Transitional in Plasma Frameworks -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 3 in workspace http://build.kde.org/job/plasma-framework_master_qt5/ws/ Running Prebuild steps [plasma-framework_master_qt5] $ /bin/sh -xe /tmp/hudson5159716049165235365.sh + /home/jenkins/scripts/setup-env.sh From git://anongit.kde.org/plasma-framework 9284733..af8a7ba master - origin/master The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch jenkins set up to track remote branch master from origin. Success build forhudson.tasks.Shell@434d4f2b Checkout:plasma-framework_master_qt5 / http://build.kde.org/job/plasma-framework_master_qt5/ws/ - hudson.remoting.Channel@699d7f6d:LinuxSlave - 3 Using strategy: Default Last Built Revision: Revision 92847333a03969fe7224360f45f28625cefe9a0d (refs/heads/jenkins) Fetching changes from 1 remote Git repository Fetching upstream changes from origin Commencing build of Revision af8a7bad7d7504caaa94f55a59fcb72db86ab45b (refs/heads/jenkins) Checking out Revision af8a7bad7d7504caaa94f55a59fcb72db86ab45b (refs/heads/jenkins) [plasma-framework_master_qt5] $ /bin/sh -xe /tmp/hudson9192625075828753865.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: extra-cmake-modules - Branch master attica - Branch master kdelibs - Branch frameworks phonon - Branch master qt5 - Branch stable strigidaemon - Branch master strigiclient - Branch master strigiutils - Branch master libstreams - Branch master libstreamanalyzer - Branch master == Cleaning Source Tree HEAD is now at af8a7ba Stop using Qt5Transitional in Plasma Frameworks Removing build/ == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at /srv/jenkins/install/linux/x86_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/find-modules/FindKF5.cmake:135 (message): KF5: requested unknown components KDeclarative Call Stack (most recent call first): CMakeLists.txt:42 (find_package) -- Configuring incomplete, errors occurred! See also http://build.kde.org/job/plasma-framework_master_qt5/ws/build/CMakeFiles/CMakeOutput.log;. Configure step exited with non-zero code, assuming failure to configure for project plasma-framework. Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE Skipping Cobertura coverage report as build was not UNSTABLE or better ... Recording test results ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113298: KDirWatch code style: cleanup whitespace.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113298/ --- (Updated Oct. 21, 2013, 10:30 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- KDirWatch code style: cleanup whitespace. The KDirWatch code had *lots* of ( foo ) and inconsistent indentation and alignment, including a few tabs(!). This is a full cleanup of it. I appreciate any feedback; if I fixed something that didn't need fixing, or if you see more whitespace errors that I didn't fix, or if I should push this to master too, or if I should leave the damn thing alone and discard the review :) This file is also lacking braces for single-line conditionals and loops; I'll fix that in a separate commit for easier reviewing. It's also mixing 2-space and 4-space indentations, but changing everything to 4 spaces (as the kdelibs coding style says) seemed too intrusive. Perhaps I should change the few 4-space indentations into 2-space for consistency? Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.h 7f6ca8ce83426c81a6336514c247aa9d115ec59e tier1/kcoreaddons/src/lib/io/kdirwatch.cpp e4f45441d5ed68e3e34ae2bd68e16fd3dc46656a tier1/kcoreaddons/src/lib/io/kdirwatch_p.h 442d6497b704c179adc13dbb25e450554d31554d Diff: http://git.reviewboard.kde.org/r/113298/diff/ Testing --- Still compiles :) Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113299: KDirWatch code style: braces for one-liner conditionals
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113299/ --- (Updated Oct. 21, 2013, 7:31 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- KDirWatch code style: braces for one-liner conditionals Added braces around single-line bodies of conditionals and loops, as specified in the kdelibs coding style. --end of commit message-- As in my previous review about whitespace, I appreciate any feedback; if I added braces where the code looked better without or viceversa, or if I should push this to master too, or if I should leave the damn braces alone and discard the review :) In some simple cases like if (stuff) return; I wasn't sure if it was better to leave it without braces... Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.cpp e4f45441d5ed68e3e34ae2bd68e16fd3dc46656a tier1/kcoreaddons/src/lib/io/kdirwatch_p.h 442d6497b704c179adc13dbb25e450554d31554d Diff: http://git.reviewboard.kde.org/r/113299/diff/ Testing --- It compiles, tests pass. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113297: Remove 'override' from ThreadWeaver::IdDecorator destructor.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113297/#review42139 --- This review has been submitted with commit f86c5a9f96b571c15f1b529f9e497022da59c567 by Nicolás Alvarez to branch frameworks. - Commit Hook On Oct. 17, 2013, 12:08 a.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113297/ --- (Updated Oct. 17, 2013, 12:08 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove 'override' from ThreadWeaver::IdDecorator destructor. MSVC2010 apparently doesn't support 'override' on destructors, even though it's legal according to C++11. Diffs - tier1/threadweaver/src/Weaver/IdDecorator.h 648d4236cc22015a1d145892daf368084a199053 Diff: http://git.reviewboard.kde.org/r/113297/diff/ Testing --- Still builds on Linux, now builds on Windows too. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113297: Remove 'override' from ThreadWeaver::IdDecorator destructor.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113297/ --- (Updated Oct. 21, 2013, 11:02 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Remove 'override' from ThreadWeaver::IdDecorator destructor. MSVC2010 apparently doesn't support 'override' on destructors, even though it's legal according to C++11. Diffs - tier1/threadweaver/src/Weaver/IdDecorator.h 648d4236cc22015a1d145892daf368084a199053 Diff: http://git.reviewboard.kde.org/r/113297/diff/ Testing --- Still builds on Linux, now builds on Windows too. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113377: Add KDeclarative to known KF5 tier3 modules
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113377/ --- Review request for KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Subject says it all. Diffs - find-modules/FindKF5.cmake 8f95469 Diff: http://git.reviewboard.kde.org/r/113377/diff/ Testing --- find_package(KF5 ... KDeclarative) works with this patch, it doesn't work without. 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 113377: Add KDeclarative to known KF5 tier3 modules
2013/10/21 Sebastian Kügler se...@kde.org This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113377/ Review request for KDE Frameworks and Stephen Kelly. By Sebastian Kügler. Repository: extra-cmake-modules Description Add KDeclarative to known KF5 tier3 modules Testing find_package(KF5 ... KDeclarative) works with this patch, it doesn't work without. I'm currently getting an error about missing KCrash when building kdelibs, could it be this same problem? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113378: Trivial warning fixes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113378/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Trivial warning fixes Fixes for warnings (almost entirely unused variables or parameters) where the correct fix was obvious. Diffs - interfaces/kimproxy/library/kimproxy.cpp e48545f0a7229d66d16901c492095ce70b755c7e khtml/src/css/css_ruleimpl.cpp e2b3a8ae82ec0f6f85c5949a08f1773b08510479 khtml/src/css/css_webfont.cpp 9c5bedd13a24a3d32f670d718e1ff761ec4a6724 khtml/src/css/cssstyleselector.cpp fa8f5f4049aec3c2738257215a74b2536981d89b khtml/src/ecma/kjs_clientrect.cpp 6d7138e7f15293d18406a90eacf214847d884c45 khtml/src/ecma/kjs_events.cpp d0c481f06ab0efab9457f699571fdd052a99a348 khtml/src/ecma/kjs_proxy.cpp afd661bd149eaaa2a8ad4940f2a7d61d1f892116 khtml/src/editing/htmlediting_impl.cpp 2ec91188e47748a19ce414cf5d740518b8cf5225 khtml/src/imload/decoders/pngloader.cpp 6d0f023e25cdd112173873bf26b13c2d86172cb8 khtml/src/rendering/RenderSVGRoot.cpp c1e96d23e12732294301d675b3603f3e86656e56 khtml/src/rendering/render_canvasimage.cpp 73eb2c6b95c1e1089204b062ef1dd0a6f3c40f6c khtml/src/svg/SVGLinearGradientElement.cpp 46059f78527b313e90111cfcc048fc64727fb265 khtml/src/svg/graphics/qt/SVGResourceClipperQt.cpp 11c768fc1f496a1cb365bd5fc2ed2e3cada66720 kioslave/file/file.cpp 692a77fe02c33d64ff38afccfd48e8dc3127e75d kioslave/file/file_unix.cpp c8781fef39cf3e842f9c9794d757154d8ae284ac kioslave/http/http.cpp b4fd4126dfb86a251d2b98cf587311b715be9979 knewstuff/src/ui/itemsgridviewdelegate.cpp a0abb7f0b359b06268e4c640be08bfd3ddae79b1 staging/frameworkintegration/src/platformtheme/main.cpp 45b487c739266e4108df8de38ae5e139ca603e5a staging/kde4support/autotests/kglobalstatictest.cpp db6473a572d47086e8db400d94c3bf62424f493f staging/kde4support/src/kdecore/kdebug.cpp 98baed423e2af32d5a6726d21d4d140854b94375 staging/kde4support/src/kdeui/kaction.cpp f5d2e201b84feea2e0ccba9b17298d3c5877e04d staging/kde4support/src/kdeui/kapplication.cpp dc2e120bc28fca5708c699e68ddea22915c46233 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df231227cd058842b8f1b90b5901cbebadbb683 staging/kde4support/tests/kcmdlineargstest.cpp a72aa4d120baf2904addd238276e0b400e0d8850 staging/kio/src/core/klocalsocket.h 93b04d69f52ccc16a3dba817d0585835e7134821 staging/kio/src/core/tcpslavebase.cpp 5180ed952d29e995c78cae498f323e0f1a3e08d7 staging/kio/src/filewidgets/kdirsortfilterproxymodel.cpp 59c4b37709acd37e9a6d1b77ff233f9e83cdecc8 staging/kio/src/widgets/kdirmodel.cpp ea290d0369aea303657afb74000780610c135ddf staging/kio/src/widgets/kurlrequester.cpp 70c760589d460f705c8bb884a5c76e2f9d5dece8 staging/kservice/src/plugin/kpluginfactory.cpp 405d41ed63f8bf4d54334d437f443160c569a82b staging/kservice/src/plugin/kplugintrader.h 823b8d5dd363642a4c11be971ee64bc3cac6a65f staging/kservice/tests/pluginlocator/plugintest.cpp 4cfc74ace9c10cccbd2651291e752b8275af036e tier1/itemmodels/src/kdescendantsproxymodel.cpp 3bdfd9ffed351b5bab24e7959730c29773cc0952 tier1/itemmodels/src/kselectionproxymodel.cpp ca97070b70996ab1320d252623a503172c9be041 tier1/itemviews/src/kwidgetitemdelegate.cpp 8d4d5cec85ee460fe2604c83fd49bf7536db990a tier1/itemviews/src/kwidgetitemdelegatepool.cpp ed94c8936e4db44dc180c5820619a0ca3fdeffa2 tier1/itemviews/tests/kwidgetitemdelegatetest.cpp 07c8bca052a3340322884ba84e8ecdf5386e10a6 tier1/karchive/src/karchive.cpp 375d717bd5030ff694e1586855f1e3f401ef tier1/kconfig/autotests/test_kconf_update.cpp 78b783042b03dd0a15f8ce91f85ec1415acfc12f tier1/kcoreaddons/autotests/kdirwatch_unittest.cpp 2b5570938f189d4891fa7baa9f9b74791c97f4ad tier1/kwidgetsaddons/src/kdatetable.cpp e5c6f5cbdafaa8ac2abd4f4eea1bb0ef9191b386 tier1/kwidgetsaddons/src/kdragwidgetdecorator.cpp 74fb8bbcf3c9836cfd88da1d017b61c4da4deb29 tier1/threadweaver/src/Weaver/DestructedState.cpp bcd613201234ca6db19d285d571c4b6fca350789 tier1/threadweaver/src/Weaver/JobCollection.cpp 51aab5725b5cd36036c9bf406185ec8e18bb06ed tier1/threadweaver/src/Weaver/ShuttingDownState.cpp ff692a59a7f94c123fc225eea9d165ba28bf5d0b tier2/kwallet/src/kwallet.cpp 49098bf5832ff83b270c1934aaf0abf6c4c780a9 tier3/kdeclarative/src/bindings/icon.cpp 0d956c500d4a0492025310abad67254fd1a7776e tier3/kinit/src/klauncher/klauncher.cpp 83f98357bd692b13b2a4b812e536acc69372c541 tier3/xmlgui/autotests/kactioncategorytest.cpp 2e30b0c53374a2d5677f507550d24588c862af1e tier3/xmlgui/src/khelpmenu.cpp 2b88f406385e8ae8084f6f11ddf824243acfca5e Diff: http://git.reviewboard.kde.org/r/113378/diff/ Testing --- Builds and tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Review Request 113376: KDirWatch: don't check for symlinks on Windows.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113376/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- KDirWatch: don't check for symlinks on Windows. Windows doesn't have symbolic links, at least not in the same way as Unix, so it doesn't have functions like lstat. Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.cpp 3468529605526c0f02e6350a90d65105b19c4708 Diff: http://git.reviewboard.kde.org/r/113376/diff/ Testing --- KDirWatch tests still pass on Linux. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112984: Adjust API in KEmoticons framework: KEmoticonsProvider::save()
On Oct. 11, 2013, 4:28 p.m., Kevin Ottens wrote: Ship It! Kevin Ottens wrote: Any reason why this patch isn't pushed yet? Yes. There are some personal reasons and, besides, I've been trying for days to compile Qt5.2 with no luck till today. I think I'll have both patches pushed this week. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112984/#review41566 --- On Oct. 7, 2013, 10:08 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112984/ --- (Updated Oct. 7, 2013, 10:08 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjust API in KEmoticons framework: KEmoticonsProvider::save() -To make KEmoticons API more consistent, deprecate KEmoticonsProvider::save() and prefer saveTheme() instead. -Adjust plugins. -Before the cleanup, KEmoticonsTheme was calling KEmoticonsProvider::save(), which was empty. Now it's a pure virtual function. Therefore, I deprecate it and advice subclassing KEmoticonsProvider. Diffs - staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 0dc92ed092d87a559fe7fa1a40e804843ab73d59 staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 0873a635a300e0ed8e38b1d59a535d6ec15b99cb staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp e9f89eecce3d6e6407113a84cb5200ff66564c19 staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h 70bafa3fe4ba25c9d6a69634024b2c157235e674 staging/kemoticons/src/providers/kde/kde_emoticons.cpp 5b5114a14dd94a6ebcba8a6f7dd163f73048189a staging/kemoticons/src/providers/kde/kde_emoticons.h 8cba6b194eee1543bf13f1177a0e4092f1a10943 staging/kemoticons/src/providers/adium/adium_emoticons.cpp a3aaa0fdc0b3dcc862f98865d2e6419e716f4f17 staging/kemoticons/src/providers/adium/adium_emoticons.h 039a267679919c968bbe4d12c35abb90cf1bcc9b staging/kemoticons/src/core/kemoticonstheme.cpp ed3407cdd45c84d91f2d0057e108b760ff696ff2 staging/kemoticons/src/core/kemoticonstheme.h b8b25f7607d3741dda78d6302c1ed81fbc9211a0 staging/kemoticons/src/core/kemoticonsprovider.cpp d04c76e87b118f5d45717b3b2ccd9dea47dc2526 staging/kemoticons/src/core/kemoticonsprovider.h 85fc7efb8923d76476f0a16f70f8ebb15e451081 KDE5PORTING.html 57ecf2e007e270b634cc8d16462b73e96553c92d Diff: http://git.reviewboard.kde.org/r/112984/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
Projects adding dependencies without clear indication of requirements
Hi all, It seems that plasma-framework (a dependency of kde-workspace master) has now added a dependency on kactivities. However kactivities itself depends on nepomuk-core and soprano - and there is no frameworks / Qt 5 branch for either of those. How do we proceed here? I'd appreciate it if more notice was given of these changes - and time was given for the CI system to be prepared in advance of the changes going in. Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
