Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. - Patrick von Reth On Jan. 22, 2014, 1:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 1:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115198: Fix KDE4Support compilation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115198/#review47984 --- Indeed - thanks for the notification of breakage. I committed a more complete fix, though. - David Faure On Jan. 21, 2014, 10:23 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115198/ --- (Updated Jan. 21, 2014, 10:23 p.m.) Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- KCrash::setApplicationName and KCrash::setApplicationPath disappeared from the KCrash module 179de6d16fb9be580dbb7b15e0a56fcb990c7516, so I guess that a good fix is just stop using it. I'm unsure what's the best way though. Diffs - src/kdeui/kapplication.cpp 5a7f4c8 Diff: https://git.reviewboard.kde.org/r/115198/diff/ Testing --- Builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kde4support_master_qt5 #31
See http://build.kde.org/job/kde4support_master_qt5/31/changes Changes: [faure] Oops, kapp still exists indeed. Fix it after KCrash changes. -- [...truncated 616 lines...] Generating moc_k4style.cpp Generating moc_k4timezonewidget.cpp Generating moc_karrowbutton.cpp Generating moc_kcolorvalueselector.cpp Generating moc_kdatetimewidget.cpp Generating moc_kdatewidget.cpp Generating moc_kdeuiwidgetsproxystyle_p.cpp Generating moc_kdialogbuttonbox.cpp Generating moc_keditlistbox.cpp Generating moc_kfontdialog.cpp Generating moc_khbox.cpp Generating moc_khuesaturationselect.cpp Generating moc_kmenubar.cpp Generating moc_kmessageboxmessagehandler.cpp Generating moc_knumvalidator.cpp Generating moc_kpassivepopupmessagehandler.cpp Generating moc_krestrictedline.cpp Generating moc_ksplashscreen.cpp Generating moc_kstatusbar.cpp Generating moc_kstringvalidator.cpp Generating moc_ktabbar.cpp Generating moc_ktextbrowser.cpp Generating moc_kundostack.cpp Generating moc_kvbox.cpp Generating moc_kdatatool.cpp Generating moc_kfileitemactionplugin.cpp Generating moc_kfilewriteplugin.cpp Generating moc_kscan.cpp Generating moc_metainfojob.cpp Generating moc_netaccess.cpp Generating moc_passworddialog.cpp Generating moc_factory.cpp [ 24%] Built target KF5KDE4Support_automoc Scanning dependencies of target KF5KDE4Support [ 24%] [ 24%] [ 24%] [ 25%] [ 25%] [ 25%] [ 25%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kcomponentdata.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kkernel_mac.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k4aboutdata.cpp.o [ 26%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kkernel_win.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kdeversion.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kdebug.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kdebugdbusiface.cpp.o [ 26%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/klibloader.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/ktemporaryfile.cpp.o http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k4aboutdata.cpp: In member function ‘void K4AboutData::translateInternalProgramName() const’: http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k4aboutdata.cpp:723:92: note: #pragma message: KDE5 FIXME: This code must be replaced by something with KLocalizedString http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k4aboutdata.cpp: In member function ‘QListK4AboutPerson K4AboutData::translators() const’: http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k4aboutdata.cpp:832:52: note: #pragma message: KDE5 TODO: What about this code ? [ 26%] [ 26%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/ktempdir.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kmd5.cpp.o [ 27%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kmimetype.cpp.o [ 27%] [ 27%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/kmimetyperepository.cpp.o Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/ksavefile.cpp.o http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/klibloader.cpp: In member function ‘KPluginFactory* KLibLoader::factory(const QString, QLibrary::LoadHints)’: http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/klibloader.cpp:136:40: warning: ‘KPluginFactory* KLibrary::factory(const char*)’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kservice/inst/include/KF5/KService/klibrary.h:58) [-Wdeprecated-declarations] [ 27%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/ksocketfactory.cpp.o [ 28%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3socks.cpp.o [ 28%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3sockssocketdevice.cpp.o [ 28%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3socketdevice.cpp.o [ 28%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3bufferedsocket.cpp.o [ 29%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3clientsocketbase.cpp.o [ 29%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3resolver.cpp.o [ 29%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3resolvermanager.cpp.o [ 29%] Building CXX object src/CMakeFiles/KF5KDE4Support.dir/kdecore/k3resolverworkerbase.cpp.o In file included from http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k3socketdevice.h:29:0, from http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k3sockssocketdevice.h:23, from http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k3sockssocketdevice.cpp:20: http://build.kde.org/job/kde4support_master_qt5/ws/src/kdecore/k3socketbase.h:700:20: warning: ‘virtual qint64
Re: Review Request 115141: Add a . at the end of command line option descriptions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115141/#review47986 --- Ship it! Ship It! - David Faure On Jan. 20, 2014, 10:39 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115141/ --- (Updated Jan. 20, 2014, 10:39 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Add a . at the end of command line option descriptions According to the QCommandLineOptions docs, this is customary, so this should make the help for these arguments match the ones Qt provides (like --help and --version), as well as application-provided ones. Diffs - src/lib/kaboutdata.cpp f24006b41524e501dc5e402e784425e99aff9ad2 Diff: https://git.reviewboard.kde.org/r/115141/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115099: Add function ecm_generate_pri_file() to provide qmake support. Make ECMSetupVersion set PROJECT_VERSION_*
On Jan. 21, 2014, 11:02 p.m., Alex Merry wrote:
modules/ECMGeneratePriFile.cmake, lines 6-7
https://git.reviewboard.kde.org/r/115099/diff/1/?file=234571#file234571line6
It also wants PROJECT_VERSION_(MAJOR|MINOR|PATCH) (unless those are
option in the pri file)
No, these are extracted from PROJECT_VERSION_STRING, in lines 55-57.
On Jan. 21, 2014, 11:02 p.m., Alex Merry wrote:
modules/ECMGeneratePriFile.cmake, line 13
https://git.reviewboard.kde.org/r/115099/diff/1/?file=234571#file234571line13
I feel DEPS should really be a list, but CMake apparently doesn't have
a join function, for some bizarre reason (although you probably could do a
string(REPLACE) of semicolons by spaces).
I don't really mind either way, and this way works. Not sure what to do, then :)
- David
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/#review47948
---
On Jan. 18, 2014, 11:02 a.m., David Faure wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/
---
(Updated Jan. 18, 2014, 11:02 a.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
Two commits:
1) Make ECMSetupVersion set PROJECT_VERSION_*
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
2) This file provides the function ecm_generate_pri_file().
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri
file to.
Diffs
-
modules/ECMGeneratePriFile.cmake PRE-CREATION
modules/ECMSetupVersion.cmake 6c3a9959be31ee186cf173bb28585dfc52860a55
Diff: https://git.reviewboard.kde.org/r/115099/diff/
Testing
---
Adding these lines to kwidgetaddons/src/CMakeLists.txt:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KWidgetsAddons LIB_NAME KF5WidgetsAddons DEPS
widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And these to kjobwidgets:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KJobWidgets LIB_NAME KF5JobWidgets DEPS
KCoreAddons widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And I added a qmake_test subdir in kf5umbrella with qmake_test.pro saying:
QT += KArchive KJobWidgets KWidgetsAddons
SOURCES += main.cpp
- links to all the mentionned libs, including KCoreAddons (via KJobWidgets).
This requires $QMAKEPATH set to the kf5 install prefix.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Question regarding build of item models framework on Window
Hi all, you are probably not subscribed to kde-devel so you might have missed that one: http://lists.kde.org/?l=kde-develm=139021750622083w=2 Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115190: Add unit test for KWindowInfo on X11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115190/ --- (Updated Jan. 22, 2014, 10:20 a.m.) Review request for KDE Frameworks and Ben Cooksley. Changes --- reworked the unit test to show the test window in init and hide it in cleanup and each time waiting for it. This has significantly improved the execution stability without the need to wait. It's now working with KWin and Openbox on build.kde.org (though there is cheating as we skip one test) Repository: kwindowsystem Description --- Add unit test for KWindowInfo on X11 Unit test for most methods provided by KWindowInfo. The general pattern is to create a window, show it, test the property, change it and verify that the change worked. This is a little bit tricky as the test needs to interact with large parts of the window manager. In case a property is updated by the window manager we need to send the client message, wait till the window manager has reacted on it and updated the property and then wait for the property update. This is mostly done by waiting for the signal KWindowSystem::windowChanged. Unfortunately that reports globally and not just for the window we are interested in. So we have to filter out till we got the correct one. If there is at the same time further interaction with the windowing system tests can fail, but a re-run normally fixes it. The unit test is so far written against KWin. It's possible that it needs adjustments for succeeding on build.kde.org. Given that KWindowInfo::actionSupported is not tested as that is clearly to specific to the used window manager. --- @Ben: is it possible that you try the patch on build.kde.org while it's under review, so that I can fix any possible failures. Diffs (updated) - autotests/CMakeLists.txt 58803aec9c807f68ff2bac227d0d9cf0305fa1f6 autotests/kwindowinfox11test.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115190/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 115099: This file provides the function ecm_generate_pri_file(). Make ECMSetupVersion set PROJECT_VERSION_*
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/
---
(Updated Jan. 22, 2014, 9:21 a.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Changes
---
Updated diff
Summary (updated)
-
This file provides the function ecm_generate_pri_file(). Make ECMSetupVersion
set PROJECT_VERSION_*
Repository: extra-cmake-modules
Description (updated)
---
This file provides the function ecm_generate_pri_file().
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri file
to.
REVIEW: 115099
Make ECMSetupVersion set PROJECT_VERSION_*
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
Diffs (updated)
-
modules/ECMGeneratePriFile.cmake PRE-CREATION
modules/ECMSetupVersion.cmake 6c3a9959be31ee186cf173bb28585dfc52860a55
Diff: https://git.reviewboard.kde.org/r/115099/diff/
Testing
---
Adding these lines to kwidgetaddons/src/CMakeLists.txt:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KWidgetsAddons LIB_NAME KF5WidgetsAddons DEPS
widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And these to kjobwidgets:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KJobWidgets LIB_NAME KF5JobWidgets DEPS
KCoreAddons widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And I added a qmake_test subdir in kf5umbrella with qmake_test.pro saying:
QT += KArchive KJobWidgets KWidgetsAddons
SOURCES += main.cpp
- links to all the mentionned libs, including KCoreAddons (via KJobWidgets).
This requires $QMAKEPATH set to the kf5 install prefix.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115206: Correct spelling, grammar and style of kcompletion.h docs
On Jan. 21, 2014, 11:43 p.m., Alex Merry wrote: src/kcompletion.h, line 103 https://git.reviewboard.kde.org/r/115206/diff/1/?file=235092#file235092line103 You remove the hyphen from auto-completion ealier, but not here. David Gil Oliva wrote: Yes, I drop the hyphen from auto-completion when it works as a noun. But here (and in many other places) is working as a compound adjective. Some sources about compound adjectives and hyphens: http://writersrelief.com/blog/2008/03/hyphen-rules-dont-let-misused-hyphens-muddle-your-adjectives-or-your-writing/ http://www.grammarbook.com/punctuation/hyphens.asp Nevertheless, I may be wrong. If so, please tell me. OK, fair enough. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115206/#review47958 --- On Jan. 21, 2014, 11:12 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115206/ --- (Updated Jan. 21, 2014, 11:12 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Correct spelling, grammar and style of kcompletion.h docs Diffs - src/kcompletion.h 46b63a4 Diff: https://git.reviewboard.kde.org/r/115206/diff/ Testing --- 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 115141: Add a . at the end of command line option descriptions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115141/#review47990 --- This review has been submitted with commit 295193cf8f6cc0d005d5498d6fc236eac2ef4487 by Alex Merry to branch master. - Commit Hook On Jan. 20, 2014, 10:39 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115141/ --- (Updated Jan. 20, 2014, 10:39 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Add a . at the end of command line option descriptions According to the QCommandLineOptions docs, this is customary, so this should make the help for these arguments match the ones Qt provides (like --help and --version), as well as application-provided ones. Diffs - src/lib/kaboutdata.cpp f24006b41524e501dc5e402e784425e99aff9ad2 Diff: https://git.reviewboard.kde.org/r/115141/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115141: Add a . at the end of command line option descriptions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115141/ --- (Updated Jan. 22, 2014, 10:23 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Add a . at the end of command line option descriptions According to the QCommandLineOptions docs, this is customary, so this should make the help for these arguments match the ones Qt provides (like --help and --version), as well as application-provided ones. Diffs - src/lib/kaboutdata.cpp f24006b41524e501dc5e402e784425e99aff9ad2 Diff: https://git.reviewboard.kde.org/r/115141/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: ktexteditor_master_qt5 #107
See http://build.kde.org/job/ktexteditor_master_qt5/107/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115218: rename dbus interface file on install for kwallet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115218/ --- Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Rename kwallet dbus interface file on install so it does not clash with equivalent file from kdelibs4. The dbus interface remains the same to keep compatibility with kdelibs4 kwallet. However you seem to have renamed the interface in places in the code in runtime/, will it be incompatible with the version from kdelibs4? Diffs - src/api/KWallet/CMakeLists.txt d0d5a3d Diff: https://git.reviewboard.kde.org/r/115218/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review47995 --- Well, but frameworks are not only for frameworks. They're all ported because I ported them. OTOH, there will be non-ported applications, that's why we provide this warning. - Aleix Pol Gonzalez On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review47996 --- Ship it! Ship It! - Aleix Pol Gonzalez On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115209: Fix KDoctools build on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115209/#review47997 --- Would it be possible to unify the two add_custom_command by redefining only docbookl10nhelper_EXE into the WIN32 block? Could you please add the kdewin group as reviewers so that they can check if it works with gcc too? - Luigi Toscano On Jan. 22, 2014, 1:26 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115209/ --- (Updated Jan. 22, 2014, 1:26 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Two separate commits: --- Print a message when a file is not found This way meinproc no longer fails silently -- Allow compiling on Windows with MSVC Diffs - CMakeLists.txt 56877a3f39b39a6d919c6b18a9c4ab1c0b5a9106 src/CMakeLists.txt 752604190a4b527d757d4b819dc6d85085a96e4b src/meinproc.cpp f34084581205ad4f63a84823cd1a582b2f37ed69 src/meinproc_common.cpp 16234f70e45a703859fce42dcdb2ac1c2fdadade src/xslt.cpp 79578ed8fb6cc3faccf63b8d86e29db9948b33e7 Diff: https://git.reviewboard.kde.org/r/115209/diff/ Testing --- Works on windows once https://git.reviewboard.kde.org/r/115210/ is also applied 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 115198: Fix KDE4Support compilation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115198/ --- (Updated Jan. 22, 2014, 11:40 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- KCrash::setApplicationName and KCrash::setApplicationPath disappeared from the KCrash module 179de6d16fb9be580dbb7b15e0a56fcb990c7516, so I guess that a good fix is just stop using it. I'm unsure what's the best way though. Diffs - src/kdeui/kapplication.cpp 5a7f4c8 Diff: https://git.reviewboard.kde.org/r/115198/diff/ Testing --- Builds. 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 115213: Remove KDE4_CREATE_HTML_HANDBOOK
On Jan. 22, 2014, 11:32 a.m., Aleix Pol Gonzalez wrote: Well, but frameworks are not only for frameworks. They're all ported because I ported them. OTOH, there will be non-ported applications, that's why we provide this warning. Luigi Toscano wrote: You ported KDE4_CREATE_HANDBOOK, which is widely used in kdelibs4-based code: http://lxr.kde.org/search?filestring=string=KDE4_CREATE_HANDBOOK On the other side, KDE4_CREATE_HTML_HANDBOOK has never been used in a stable version (not in 4 at least), please check the dates: http://mail.kde.org/pipermail/kde-buildsystem/2007-January/003643.html http://quickgit.kde.org/?p=kdelibs.gita=commith=61dd00ab3211bb7b76a94344ed8d577a6d194cf1 http://quickgit.kde.org/?p=kdelibs.gita=commith=82f7b6ba0f8be7d314ac780b9a873e98b6be39b2 Also: http://lxr.kde.org/search?filestring=string=KDE4_CREATE_HTML_HANDBOOK - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review47995 --- On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
On Jan. 22, 2014, 11:32 a.m., Aleix Pol Gonzalez wrote: Well, but frameworks are not only for frameworks. They're all ported because I ported them. OTOH, there will be non-ported applications, that's why we provide this warning. You ported KDE4_CREATE_HANDBOOK, which is widely used in kdelibs4-based code: http://lxr.kde.org/search?filestring=string=KDE4_CREATE_HANDBOOK On the other side, KDE4_CREATE_HTML_HANDBOOK has never been used in a stable version (not in 4 at least), please check the dates: http://mail.kde.org/pipermail/kde-buildsystem/2007-January/003643.html http://quickgit.kde.org/?p=kdelibs.gita=commith=61dd00ab3211bb7b76a94344ed8d577a6d194cf1 http://quickgit.kde.org/?p=kdelibs.gita=commith=82f7b6ba0f8be7d314ac780b9a873e98b6be39b2 - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review47995 --- On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115185: Integrate kf5dot
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/ --- (Updated Jan. 22, 2014, 12:42 p.m.) Review request for KDE Frameworks and Aurélien Gâteau. Changes --- Add license headers, remove .gitignore. Repository: kapidox Description --- This big patch includes all of the kf5dot repository inside kapidox. Python code is in src/kapidox/kf5dot, scripts are in src/. I replayed all the commits from the kf5dot repository within the kapidox repository using `git am` to avoid loosing history. As such, I plan to do the merge using --no-ff. Diffs (updated) - README.md 660e9c3 setup.py 025afdb src/kapidox/kf5dot/block.py PRE-CREATION src/kapidox/kf5dot/framework.py PRE-CREATION src/kapidox/kf5dot/frameworkdb.py PRE-CREATION src/kf5dot-generate PRE-CREATION src/kf5dot-generate-all PRE-CREATION src/kf5dot-prepare PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115185/diff/ Testing --- Generated all diagrams. Works as expected. 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 115213: Remove KDE4_CREATE_HTML_HANDBOOK
On Jan. 22, 2014, 11:32 a.m., Aleix Pol Gonzalez wrote: Well, but frameworks are not only for frameworks. They're all ported because I ported them. OTOH, there will be non-ported applications, that's why we provide this warning. Luigi Toscano wrote: You ported KDE4_CREATE_HANDBOOK, which is widely used in kdelibs4-based code: http://lxr.kde.org/search?filestring=string=KDE4_CREATE_HANDBOOK On the other side, KDE4_CREATE_HTML_HANDBOOK has never been used in a stable version (not in 4 at least), please check the dates: http://mail.kde.org/pipermail/kde-buildsystem/2007-January/003643.html http://quickgit.kde.org/?p=kdelibs.gita=commith=61dd00ab3211bb7b76a94344ed8d577a6d194cf1 http://quickgit.kde.org/?p=kdelibs.gita=commith=82f7b6ba0f8be7d314ac780b9a873e98b6be39b2 Luigi Toscano wrote: Also: http://lxr.kde.org/search?filestring=string=KDE4_CREATE_HTML_HANDBOOK Oh ok, sorry about the noise then. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review47995 --- On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review48003 --- Ship it! Ship It! - Aleix Pol Gonzalez On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review48004 --- Ship it! Ship It! - Luigi Toscano On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115185: Integrate kf5dot
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/#review48005 --- Ship it! Providing that you then rename it something sensible :-) - Alex Merry On Jan. 22, 2014, 11:42 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/ --- (Updated Jan. 22, 2014, 11:42 a.m.) Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- This big patch includes all of the kf5dot repository inside kapidox. Python code is in src/kapidox/kf5dot, scripts are in src/. I replayed all the commits from the kf5dot repository within the kapidox repository using `git am` to avoid loosing history. As such, I plan to do the merge using --no-ff. Diffs - README.md 660e9c3 setup.py 025afdb src/kapidox/kf5dot/block.py PRE-CREATION src/kapidox/kf5dot/framework.py PRE-CREATION src/kapidox/kf5dot/frameworkdb.py PRE-CREATION src/kf5dot-generate PRE-CREATION src/kf5dot-generate-all PRE-CREATION src/kf5dot-prepare PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115185/diff/ Testing --- Generated all diagrams. Works as expected. 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 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review48006 --- Well, I wouldn't expect many users in frameworks, but I can't even find any in my (somewhat out-of-date) checkout of KDE4 software; unsurprising, given it was deprecated for most/all of the KDE 4 era. So I'm in favour of this. - Alex Merry On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115099: This file provides the function ecm_generate_pri_file(). Make ECMSetupVersion set PROJECT_VERSION_*
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/#review48008
---
Ship it!
Ship It!
- Alex Merry
On Jan. 22, 2014, 9:21 a.m., David Faure wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/
---
(Updated Jan. 22, 2014, 9:21 a.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
This file provides the function ecm_generate_pri_file().
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri
file to.
REVIEW: 115099
Make ECMSetupVersion set PROJECT_VERSION_*
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
Diffs
-
modules/ECMGeneratePriFile.cmake PRE-CREATION
modules/ECMSetupVersion.cmake 6c3a9959be31ee186cf173bb28585dfc52860a55
Diff: https://git.reviewboard.kde.org/r/115099/diff/
Testing
---
Adding these lines to kwidgetaddons/src/CMakeLists.txt:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KWidgetsAddons LIB_NAME KF5WidgetsAddons DEPS
widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And these to kjobwidgets:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KJobWidgets LIB_NAME KF5JobWidgets DEPS
KCoreAddons widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And I added a qmake_test subdir in kf5umbrella with qmake_test.pro saying:
QT += KArchive KJobWidgets KWidgetsAddons
SOURCES += main.cpp
- links to all the mentionned libs, including KCoreAddons (via KJobWidgets).
This requires $QMAKEPATH set to the kf5 install prefix.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115099: This file provides the function ecm_generate_pri_file(). Make ECMSetupVersion set PROJECT_VERSION_*
On Jan. 21, 2014, 11:02 p.m., Alex Merry wrote:
modules/ECMGeneratePriFile.cmake, line 13
https://git.reviewboard.kde.org/r/115099/diff/1/?file=234571#file234571line13
I feel DEPS should really be a list, but CMake apparently doesn't have
a join function, for some bizarre reason (although you probably could do a
string(REPLACE) of semicolons by spaces).
David Faure wrote:
I don't really mind either way, and this way works. Not sure what to do,
then :)
Eh, leave it as it is. It's not *that* unreasonable to have the input tied to
the output format.
On Jan. 21, 2014, 11:02 p.m., Alex Merry wrote:
modules/ECMGeneratePriFile.cmake, lines 6-7
https://git.reviewboard.kde.org/r/115099/diff/1/?file=234571#file234571line6
It also wants PROJECT_VERSION_(MAJOR|MINOR|PATCH) (unless those are
option in the pri file)
David Faure wrote:
No, these are extracted from PROJECT_VERSION_STRING, in lines 55-57.
Ah, sorry, didn't spot that.
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/#review47948
---
On Jan. 22, 2014, 9:21 a.m., David Faure wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115099/
---
(Updated Jan. 22, 2014, 9:21 a.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
This file provides the function ecm_generate_pri_file().
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri
file to.
REVIEW: 115099
Make ECMSetupVersion set PROJECT_VERSION_*
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
Diffs
-
modules/ECMGeneratePriFile.cmake PRE-CREATION
modules/ECMSetupVersion.cmake 6c3a9959be31ee186cf173bb28585dfc52860a55
Diff: https://git.reviewboard.kde.org/r/115099/diff/
Testing
---
Adding these lines to kwidgetaddons/src/CMakeLists.txt:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KWidgetsAddons LIB_NAME KF5WidgetsAddons DEPS
widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And these to kjobwidgets:
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KJobWidgets LIB_NAME KF5JobWidgets DEPS
KCoreAddons widgets FILENAME_VAR PRI_FILENAME)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
And I added a qmake_test subdir in kf5umbrella with qmake_test.pro saying:
QT += KArchive KJobWidgets KWidgetsAddons
SOURCES += main.cpp
- links to all the mentionned libs, including KCoreAddons (via KJobWidgets).
This requires $QMAKEPATH set to the kf5 install prefix.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48009 --- Ship it! This seems sensible to me; however, I do wonder if ECM should also provide an ecm_mark_gui_executable function as well (I'm thinking of the case where most of the tests should be non-gui, but a handful want to display widgets). - Alex Merry On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115211: Mark target created by ecm_add_test as non GUI by default
On Jan. 22, 2014, 12:08 p.m., Alex Merry wrote: This seems sensible to me; however, I do wonder if ECM should also provide an ecm_mark_gui_executable function as well (I'm thinking of the case where most of the tests should be non-gui, but a handful want to display widgets). Well, we can't change the default, can we? - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48009 --- On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Authors, maintainers and licenses in apidox
On 22/01/14 06:33, Kevin Ottens wrote: On Tuesday 21 January 2014 17:18:36 Alex Merry wrote: Traditionally, the front pages of our apidox has included a list of authors, the maintainer(s) and the license. This is obviously duplicating/summarising information stored elsewhere, and is easy to let get out of date. Yes... definitely easy to get wrong. We should have only one place for that. Do we still want this information? It would probably mean adding it to the README.md files. Are we ditching the LICENSE and AUTHORS files which used to contain this type of information? I'm not sure we want everything in README.md. Well, this is kind of what I mean about duplicating the information. Although the canonical authorship info is the copyright headers and/or git log. My personal view is that authors generally shouldn't be in the apidox main page anyway, as it's not massively useful to users of the dox. Authors on individual classes is more useful and more likely to be accurate. Having the maintain there is a possibility, or we could just add a link to the frameworks list with the canonical info to the Links section. License is potentially useful. Currently the docs do @licenses @lgpl which gives something approximating the markdown ### License(s): [LGPLv2](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1) This is somewhat more succinct than the content of LICENSE tends to be (where that file is even given; we currently don't bother with it if the code is GPL or LGPL; in that case, we have COPYING or COPYING.LIB, containing the full text of the license, instead). I would be tempted to ditch the current LICENSE files (all three of them), and add (summary) license info to README.md, as ## License This framework is licensed under the [LGPLv2](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1) or ## License This framework is licensed under the @lgpl (the latter depends on a doxygen command defined by kapidox). We would (have to) keep COPYING and COPYING.LIB regardless. We might want to add in a second sentence saying that the CMake code is licensed as BSD. Currently there are a bunch of COPYING-CMAKE-SCRIPTS files around where frameworks ship Find*.cmake modules, which I'm not so keen on (especially as the BSD license text makes little sense unless it has a copyright notice above it). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
On Jan. 22, 2014, 12:08 p.m., Alex Merry wrote: This seems sensible to me; however, I do wonder if ECM should also provide an ecm_mark_gui_executable function as well (I'm thinking of the case where most of the tests should be non-gui, but a handful want to display widgets). Aleix Pol Gonzalez wrote: Well, we can't change the default, can we? I don't understand what you mean. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48009 --- On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115221: Allow to co-install kjs devel files along with kde4 devel files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115221/ --- (Updated Jan. 22, 2014, 12:32 p.m.) Review request for Build System, KDE Frameworks and David Faure. Repository: kjs Description --- Allow to co-install kjs devel files along with kde4 devel files Diffs - CMakeLists.txt 99b0c4e src/kjs/CMakeLists.txt 8b88cca src/kjs/api/CMakeLists.txt 207d158 src/wtf/CMakeLists.txt dd80388 Diff: https://git.reviewboard.kde.org/r/115221/diff/ Testing --- install done with both files. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
On Jan. 22, 2014, 12:08 p.m., Alex Merry wrote: This seems sensible to me; however, I do wonder if ECM should also provide an ecm_mark_gui_executable function as well (I'm thinking of the case where most of the tests should be non-gui, but a handful want to display widgets). Aleix Pol Gonzalez wrote: Well, we can't change the default, can we? Alex Merry wrote: I don't understand what you mean. If we have a /mark as non gui/ function is because executables are /gui executables/ by default. Having an ecm_mark_gui_executable() would make this weird I'd say. (TBH, it seems to me cmake shouldn't know about that at all, but I take it as just a limitation on Windows (and Android)) - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48009 --- On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115222: use renamed kjscmd5 in examples
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/ --- Review request for KDE Frameworks and Hrvoje Senjan. Repository: kjsembed Description --- use renamed kjscmd5 in examples Diffs - examples/calc/calc.js 1cf93dd examples/docviewer/docviewer.js 668c6fd examples/fancy/fancy.js bd5a644 examples/grammar/grammar.js 7f3ee1e examples/scribble/scribble.js 80fc97d examples/tests/statictest.js 923cfb5 examples/tests/uitest.js 9f55ecb examples/tests/uitest2.js c92d959 Diff: https://git.reviewboard.kde.org/r/115222/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115185: Integrate kf5dot
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/ --- (Updated Jan. 22, 2014, 12:51 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- This big patch includes all of the kf5dot repository inside kapidox. Python code is in src/kapidox/kf5dot, scripts are in src/. I replayed all the commits from the kf5dot repository within the kapidox repository using `git am` to avoid loosing history. As such, I plan to do the merge using --no-ff. Diffs - README.md 660e9c3 setup.py 025afdb src/kapidox/kf5dot/block.py PRE-CREATION src/kapidox/kf5dot/framework.py PRE-CREATION src/kapidox/kf5dot/frameworkdb.py PRE-CREATION src/kf5dot-generate PRE-CREATION src/kf5dot-generate-all PRE-CREATION src/kf5dot-prepare PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115185/diff/ Testing --- Generated all diagrams. Works as expected. 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 115185: Integrate kf5dot
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/#review48014 --- This review has been submitted with commit a651b7df17e42b896a8fc9620bd8b1568036fb77 by Aurélien Gâteau to branch master. - Commit Hook On Jan. 22, 2014, 11:42 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115185/ --- (Updated Jan. 22, 2014, 11:42 a.m.) Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- This big patch includes all of the kf5dot repository inside kapidox. Python code is in src/kapidox/kf5dot, scripts are in src/. I replayed all the commits from the kf5dot repository within the kapidox repository using `git am` to avoid loosing history. As such, I plan to do the merge using --no-ff. Diffs - README.md 660e9c3 setup.py 025afdb src/kapidox/kf5dot/block.py PRE-CREATION src/kapidox/kf5dot/framework.py PRE-CREATION src/kapidox/kf5dot/frameworkdb.py PRE-CREATION src/kf5dot-generate PRE-CREATION src/kf5dot-generate-all PRE-CREATION src/kf5dot-prepare PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115185/diff/ Testing --- Generated all diagrams. Works as expected. 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 115211: Mark target created by ecm_add_test as non GUI by default
On Jan. 22, 2014, 12:08 p.m., Alex Merry wrote: This seems sensible to me; however, I do wonder if ECM should also provide an ecm_mark_gui_executable function as well (I'm thinking of the case where most of the tests should be non-gui, but a handful want to display widgets). Aleix Pol Gonzalez wrote: Well, we can't change the default, can we? Alex Merry wrote: I don't understand what you mean. Aleix Pol Gonzalez wrote: If we have a /mark as non gui/ function is because executables are /gui executables/ by default. Having an ecm_mark_gui_executable() would make this weird I'd say. (TBH, it seems to me cmake shouldn't know about that at all, but I take it as just a limitation on Windows (and Android)) We have it because we call set(CMAKE_WIN32_EXECUTABLE ON) in KDECMakeSettings.cmake. CMake documentation is unforthcoming about the default in the absence of that setting, but I think it is off. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48009 --- On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115222: use renamed kjscmd5 in examples
On Jan. 22, 2014, 1:18 p.m., Hrvoje Senjan wrote: Ship It! Thanks, i somehow missed those :/ - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/#review48018 --- On Jan. 22, 2014, 12:42 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/ --- (Updated Jan. 22, 2014, 12:42 p.m.) Review request for KDE Frameworks and Hrvoje Senjan. Repository: kjsembed Description --- use renamed kjscmd5 in examples Diffs - examples/calc/calc.js 1cf93dd examples/docviewer/docviewer.js 668c6fd examples/fancy/fancy.js bd5a644 examples/grammar/grammar.js 7f3ee1e examples/scribble/scribble.js 80fc97d examples/tests/statictest.js 923cfb5 examples/tests/uitest.js 9f55ecb examples/tests/uitest2.js c92d959 Diff: https://git.reviewboard.kde.org/r/115222/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115222: use renamed kjscmd5 in examples
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/#review48018 --- Ship it! Ship It! - Hrvoje Senjan On Jan. 22, 2014, 12:42 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/ --- (Updated Jan. 22, 2014, 12:42 p.m.) Review request for KDE Frameworks and Hrvoje Senjan. Repository: kjsembed Description --- use renamed kjscmd5 in examples Diffs - examples/calc/calc.js 1cf93dd examples/docviewer/docviewer.js 668c6fd examples/fancy/fancy.js bd5a644 examples/grammar/grammar.js 7f3ee1e examples/scribble/scribble.js 80fc97d examples/tests/statictest.js 923cfb5 examples/tests/uitest.js 9f55ecb examples/tests/uitest2.js c92d959 Diff: https://git.reviewboard.kde.org/r/115222/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : ktexteditor_master_qt5 #114
See http://build.kde.org/job/ktexteditor_master_qt5/114/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115222: use renamed kjscmd5 in examples
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/ --- (Updated Jan. 22, 2014, 1:33 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Hrvoje Senjan. Repository: kjsembed Description --- use renamed kjscmd5 in examples Diffs - examples/calc/calc.js 1cf93dd examples/docviewer/docviewer.js 668c6fd examples/fancy/fancy.js bd5a644 examples/grammar/grammar.js 7f3ee1e examples/scribble/scribble.js 80fc97d examples/tests/statictest.js 923cfb5 examples/tests/uitest.js 9f55ecb examples/tests/uitest2.js c92d959 Diff: https://git.reviewboard.kde.org/r/115222/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115222: use renamed kjscmd5 in examples
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/#review48021 --- This review has been submitted with commit b7673c40ffd361daee875ea41ada85400a3e585e by Jonathan Riddell to branch master. - Commit Hook On Jan. 22, 2014, 12:42 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115222/ --- (Updated Jan. 22, 2014, 12:42 p.m.) Review request for KDE Frameworks and Hrvoje Senjan. Repository: kjsembed Description --- use renamed kjscmd5 in examples Diffs - examples/calc/calc.js 1cf93dd examples/docviewer/docviewer.js 668c6fd examples/fancy/fancy.js bd5a644 examples/grammar/grammar.js 7f3ee1e examples/scribble/scribble.js 80fc97d examples/tests/statictest.js 923cfb5 examples/tests/uitest.js 9f55ecb examples/tests/uitest2.js c92d959 Diff: https://git.reviewboard.kde.org/r/115222/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115189: rename dbus interface files for kstatusnotifier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115189/ --- (Updated Jan. 22, 2014, 1:35 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Klapetek. Repository: knotifications Description --- Rename dbus interface files on install, but keep the same dbus interface. This prevents files clashing with kdelibs4 equivalents but maintains the specified interface. Diffs - src/CMakeLists.txt 5d731eb Diff: https://git.reviewboard.kde.org/r/115189/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115189: rename dbus interface files for kstatusnotifier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115189/#review48023 --- This review has been submitted with commit 2ff1ae73f5fab73071ad0454f1b8fbf575cca782 by Jonathan Riddell to branch master. - Commit Hook On Jan. 21, 2014, 5:40 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115189/ --- (Updated Jan. 21, 2014, 5:40 p.m.) Review request for KDE Frameworks and Martin Klapetek. Repository: knotifications Description --- Rename dbus interface files on install, but keep the same dbus interface. This prevents files clashing with kdelibs4 equivalents but maintains the specified interface. Diffs - src/CMakeLists.txt 5d731eb Diff: https://git.reviewboard.kde.org/r/115189/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115225: Add runtime platform support to KWindowInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/#review48024 --- src/kwindowinfo_p.h https://git.reviewboard.kde.org/r/115225/#comment34006 Why are we ref counting ourselves instead of just using QExplicitlySharedDataPointer? - David Edmundson On Jan. 22, 2014, 1:09 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 22, 2014, 1:09 p.m.) Review request for KDE Frameworks and kdewin. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs - src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) 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 115225: Add runtime platform support to KWindowInfo
On Jan. 22, 2014, 2:39 p.m., David Edmundson wrote: src/kwindowinfo_p.h, line 80 https://git.reviewboard.kde.org/r/115225/diff/1/?file=235187#file235187line80 Why are we ref counting ourselves instead of just using QExplicitlySharedDataPointer? because it was that way in the old code. I didn't spend much thought on it and just kept the pattern. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/#review48024 --- On Jan. 22, 2014, 2:09 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 22, 2014, 2:09 p.m.) Review request for KDE Frameworks and kdewin. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs - src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) 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 115225: Add runtime platform support to KWindowInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 22, 2014, 3:03 p.m.) Review request for KDE Frameworks and kdewin. Changes --- changed to QExplicitlySharedDataPointer. d_ed please confirm that the usage is correct, I think I have never used this class before. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs (updated) - src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 9:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. - Patrick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 1:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 1:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115212: Fix windows build + 1 compiler warning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/ --- (Updated Jan. 22, 2014, 3:49 p.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- 4 separate commits: 1. Fix windows build with QT_NO_CAST_FROM_ASCII 2. m_collator already returs bool, remove check for 0 3. Don't use foreach for this loop, it somehow breaks MSVC 4. Don't use uname() and getpwuid() directly Added new functions that also do the right thing on Windows Diffs (updated) - src/CMakeLists.txt 4516a9ee3da774788c76f30f15181fa0049a9d86 src/kbugreport.cpp 56f088106becbccca5e9731abc04118a19e36ba9 src/kgesture.cpp 49c927803b2e16806985d758103d3e359aa58dd4 src/kkeysequencewidget.cpp cc9016b776c16984b83a36a2742526ede624bf5e src/ksendbugmail/CMakeLists.txt 12b4926ecddeb023315f6074ab57cfe6cdee65ff src/ksendbugmail/main.cpp 8f85f315f0746bb774175114b1e284e899957fd3 src/ksendbugmail/smtp.cpp 90b6b98467b0c220cfef18bc35cf3c07df9a8cf3 src/kshortcutseditoritem.cpp 086f833fc505f69a3b0dbe6fceffdb94ecd60330 src/systeminformation_p.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115212/diff/ Testing --- now it compiles on windows and Linux is still fine 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 3:53 p.m.) Status -- This change has been discarded. Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 2:54 p.m.) Status -- This change has been marked as submitted. Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 9:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Sure no problem. I'll drop this request - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 3:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 3:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115211: Mark target created by ecm_add_test as non GUI by default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/#review48036 --- This review has been submitted with commit 7cf3afc38e03d52d76848a6f0aa6d880d5ba97fd by Alex Richardson to branch master. - Commit Hook On Jan. 22, 2014, 1:28 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115211/ --- (Updated Jan. 22, 2014, 1:28 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Mark target created by ecm_add_test as non GUI by default This behaviour can be overriden by passing the GUI flag to the command Diffs - modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e Diff: https://git.reviewboard.kde.org/r/115211/diff/ Testing --- Oketeta unit tests wouldn't build on windows before this commit, now they do 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115230: Add platform check to KSelectionOwner and KSelectionWatcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115230/ --- Review request for KDE Frameworks. Repository: kwindowsystem Description --- Add platform check to KSelectionOwner and KSelectionWatcher These are highly X11 specific classes and don't make any sense on a platform other than xcb and were potentially crashy by using QX11Info without verifying that the platform is used. The implementation will now only create the d-ptr in case that the code is running on the xcb platform and ensures that no call to xcb is done unconditionally. All methods perform an early return in case the d-ptr is null. Non-void methods return a sensible default value in this case. Diffs - src/kselectionowner.h 512bd5ebc6336c3a07d78dd964599d3f48d8eb33 src/kselectionowner.cpp 3715267e280822ba541196d9c63fd28f58cdc7ee src/kselectionwatcher.h 798fe70bfc8175764f3fc3d09de97d971d5e57ad src/kselectionwatcher.cpp 87e0a9612f2bc6ced3de7c31797411b1eb183d41 Diff: https://git.reviewboard.kde.org/r/115230/diff/ Testing --- unit test is not failing. No test on non-X11, though. 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? - Patrick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115203: Allow compiling with MSVC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115203/ --- (Updated Jan. 22, 2014, 4:13 p.m.) Review request for KDE Frameworks and kdewin. Repository: kcrash Description --- Allow compiling with MSVC Diffs - src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 src/kcrash.cpp 13b64adff7bce5782b054bf43ef9e357e9aa1622 Diff: https://git.reviewboard.kde.org/r/115203/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115225: Add runtime platform support to KWindowInfo
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/#review48044
---
Looks quite nice, other than the missing win/mac support which you can do
little about at this point.
Use of the explicitly shared pointer approach is a simple and nice performance
booster when passing these objects around (as these tend to). +1 for that.
I took a moment to ponder if there is enough duplication of window info objects
for the same window ID to make it worthwhile to have a global hash of winid to
dptrs for re-use between separately created instances (and not just copies of
the same instance). In the desktop shell there is at least one per window for
the taskbar and the pager (assuming the pager is active, anyways); the window
runner usually isn't loaded in the shell directly but were it to be that'd be a
third instance. So the highest duplication likely to be seen is probably 3 and
so it isn't worth it.
It's a bit of a shame that the runtime detection requires a dptr full of
virtuals; this is probably only required on Linux/UNIX where there are multiple
window info protocols (xcb, wayland, ..) so sucks for the other platforms, but
I also suspect that this will never actually be used in practice even on Linux
as one is either going to be in a Wayland or X11 (or whatever) session and
switching between them requires logging in/out. It's private API so it can be
changed later if this were ever to actually show up on in runtime performance
which I seriously doubt it will. (I can imagine sth horrible like a
struct/union which has a pointer to an xcb and a wayland implementation, both
of which have the same literal API for consistency but no base class and then a
macro that calls whichever one is actually instantiated: #define
callimpl(method) if (d-xcb) { d-xcb-method(); } else { d-wayland-method();
} win/mac/etc would have a rather simpler callimpl macro. yes, ugly as #($*
but it would get rid of the virtuals and allow win/mac/android/etc to be
simple compile-time classes without unnecessary runtime detection features ..
but probably not worth the uglification w/out good justification, which
currently doesn't exist.
I haven't done anything more than add it to the compile, so I can't mark it as
ShipIt with a clean conscience (as I haven't tested it at runtime), but the
code looks good and the design is reasonable imho.
- Aaron J. Seigo
On Jan. 22, 2014, 2:03 p.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/
---
(Updated Jan. 22, 2014, 2:03 p.m.)
Review request for KDE Frameworks and kdewin.
Repository: kwindowsystem
Description
---
Add runtime platform support to KWindowInfo
Main idea of this change is to only pick the X11 implementation in case
that the application is running on the X11 platform. So far it was a
compile time switch which meant that if compiled with X11 support but
not running on the X11 platform it would have caused runtime errors.
To make this possible a KWindowInfoPrivate class with a dummy
implementation is provided. This is used as d-ptr for KWindowInfo.
Thus there is one generic implementation and the implementation of
KWindowInfo is no longer ifdefed for the supported platforms.
The platform specific code can inherit from KWindowInfoPrivate and
overwrite the dummy method implementation. KWindowInfoPrivate provides
a factory method where the platform specific implementation can be
hooked into. There we can have both compile time and runtime checking.
If there is no platfom specific implementation available the dummy
implementation is used.
NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND!
Windows and Mac is excluded from build. At the moment they get the
dummy implementation. Unfortunately I don't have the possibility to
compile the changes and thus don't dare to touch the code. Fixes from
the teams are highly appreciated.
Diffs
-
src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507
src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a
src/kwindowinfo.cpp PRE-CREATION
src/kwindowinfo_p.h PRE-CREATION
src/kwindowinfo_p_x11.h PRE-CREATION
src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f
Diff: https://git.reviewboard.kde.org/r/115225/diff/
Testing
---
Unit test from https://git.reviewboard.kde.org/r/115190/ is still working.
Now you can guess why I wrote that test ;-)
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 115225: Add runtime platform support to KWindowInfo
On Jan. 22, 2014, 3:22 p.m., Aaron J. Seigo wrote:
Looks quite nice, other than the missing win/mac support which you can do
little about at this point.
Use of the explicitly shared pointer approach is a simple and nice
performance booster when passing these objects around (as these tend to).
+1 for that.
I took a moment to ponder if there is enough duplication of window info
objects for the same window ID to make it worthwhile to have a global hash
of winid to dptrs for re-use between separately created instances (and not
just copies of the same instance). In the desktop shell there is at least
one per window for the taskbar and the pager (assuming the pager is active,
anyways); the window runner usually isn't loaded in the shell directly but
were it to be that'd be a third instance. So the highest duplication likely
to be seen is probably 3 and so it isn't worth it.
It's a bit of a shame that the runtime detection requires a dptr full of
virtuals; this is probably only required on Linux/UNIX where there are
multiple window info protocols (xcb, wayland, ..) so sucks for the other
platforms, but I also suspect that this will never actually be used in
practice even on Linux as one is either going to be in a Wayland or X11 (or
whatever) session and switching between them requires logging in/out. It's
private API so it can be changed later if this were ever to actually show
up on in runtime performance which I seriously doubt it will. (I can
imagine sth horrible like a struct/union which has a pointer to an xcb and
a wayland implementation, both of which have the same literal API for
consistency but no base class and then a macro that calls whichever one is
actually instantiated: #define callimpl(method) if (d-xcb) {
d-xcb-method(); } else { d-wayland-method(); } win/mac/etc would have
a rather simpler callimpl macro. yes, ugly as
#($* but it would get rid of the virtuals and allow win/mac/android/etc to be
simple compile-time classes without unnecessary runtime detection features ..
but probably not worth the uglification w/out good justification, which
currently doesn't exist.
I haven't done anything more than add it to the compile, so I can't mark it
as ShipIt with a clean conscience (as I haven't tested it at runtime), but
the code looks good and the design is reasonable imho.
... or a template class instead of the #define, though that adds a layer of
function call indirection I bet it could be 100% inlined functions and be both
fast and non-#define-hackery.
- Aaron J.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/#review48044
---
On Jan. 22, 2014, 2:03 p.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/
---
(Updated Jan. 22, 2014, 2:03 p.m.)
Review request for KDE Frameworks and kdewin.
Repository: kwindowsystem
Description
---
Add runtime platform support to KWindowInfo
Main idea of this change is to only pick the X11 implementation in case
that the application is running on the X11 platform. So far it was a
compile time switch which meant that if compiled with X11 support but
not running on the X11 platform it would have caused runtime errors.
To make this possible a KWindowInfoPrivate class with a dummy
implementation is provided. This is used as d-ptr for KWindowInfo.
Thus there is one generic implementation and the implementation of
KWindowInfo is no longer ifdefed for the supported platforms.
The platform specific code can inherit from KWindowInfoPrivate and
overwrite the dummy method implementation. KWindowInfoPrivate provides
a factory method where the platform specific implementation can be
hooked into. There we can have both compile time and runtime checking.
If there is no platfom specific implementation available the dummy
implementation is used.
NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND!
Windows and Mac is excluded from build. At the moment they get the
dummy implementation. Unfortunately I don't have the possibility to
compile the changes and thus don't dare to touch the code. Fixes from
the teams are highly appreciated.
Diffs
-
src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507
src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a
src/kwindowinfo.cpp PRE-CREATION
src/kwindowinfo_p.h PRE-CREATION
src/kwindowinfo_p_x11.h PRE-CREATION
src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f
Diff: https://git.reviewboard.kde.org/r/115225/diff/
Testing
---
Unit test from
Re: Review Request 115209: Fix KDoctools build on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115209/ --- (Updated Jan. 22, 2014, 4:12 p.m.) Review request for Documentation, KDE Frameworks, kdewin, and Luigi Toscano. Repository: kdoctools Description --- Two separate commits: --- Print a message when a file is not found This way meinproc no longer fails silently -- Allow compiling on Windows with MSVC Diffs (updated) - CMakeLists.txt 56877a3f39b39a6d919c6b18a9c4ab1c0b5a9106 src/CMakeLists.txt 752604190a4b527d757d4b819dc6d85085a96e4b src/meinproc.cpp f34084581205ad4f63a84823cd1a582b2f37ed69 src/meinproc_common.cpp 16234f70e45a703859fce42dcdb2ac1c2fdadade src/xslt.cpp 79578ed8fb6cc3faccf63b8d86e29db9948b33e7 Diff: https://git.reviewboard.kde.org/r/115209/diff/ Testing --- Works on windows once https://git.reviewboard.kde.org/r/115210/ is also applied 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 115225: Add runtime platform support to KWindowInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/#review48048 --- QSharedData code looks right to me. Thanks. src/kwindowinfo.cpp https://git.reviewboard.kde.org/r/115225/#comment34009 This seems wrong. KWindowInfo cheese; cheese.state(); //CRASH - David Edmundson On Jan. 22, 2014, 2:03 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 22, 2014, 2:03 p.m.) Review request for KDE Frameworks and kdewin. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs - src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) 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 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115164: Keep tests together
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115164/ --- (Updated Jan. 22, 2014, 3:57 p.m.) Review request for KDE Frameworks and Valentin Rusu. Changes --- Add vrusu as reviewer. Repository: kio Description --- There are two sets of sets in the middle of the source tree, away from the usual autotests/. This moves them so that they are all together. (I don't know why git didn't recognise certain files as just being moved in the diff) Diffs - src/ioslaves/http/kcookiejar/tests/cookie_rfc.test src/ioslaves/http/kcookiejar/tests/cookie_saving.test src/ioslaves/http/kcookiejar/tests/cookie_session.test src/ioslaves/http/kcookiejar/tests/cookie_settings.test src/ioslaves/http/kcookiejar/tests/kcookiejartest.cpp src/ioslaves/http/tests/CMakeLists.txt src/ioslaves/http/tests/httpauthenticationtest.h src/ioslaves/http/tests/httpauthenticationtest.cpp src/ioslaves/http/tests/httpfiltertest.cpp src/ioslaves/http/tests/httpheaderdispositiontest.h src/ioslaves/http/tests/httpheaderdispositiontest.cpp src/ioslaves/http/tests/httpheadertokenizetest.h src/ioslaves/http/tests/httpheadertokenizetest.cpp src/ioslaves/http/tests/httpobjecttest.h src/ioslaves/http/tests/httpobjecttest.cpp autotests/CMakeLists.txt 5655d45efcfd9455e1745a2ec93e2da30a9b83b2 autotests/http/CMakeLists.txt PRE-CREATION autotests/http/httpfiltertest.cpp PRE-CREATION autotests/http/tests/httpauthenticationtest.h PRE-CREATION autotests/http/tests/httpauthenticationtest.cpp PRE-CREATION autotests/http/tests/httpheaderdispositiontest.h PRE-CREATION autotests/http/tests/httpheaderdispositiontest.cpp PRE-CREATION autotests/http/tests/httpheadertokenizetest.h PRE-CREATION autotests/http/tests/httpheadertokenizetest.cpp PRE-CREATION autotests/http/tests/httpobjecttest.h PRE-CREATION autotests/http/tests/httpobjecttest.cpp PRE-CREATION autotests/kcookiejar/kcookiejartest.cpp PRE-CREATION autotests/kcookiejar/tests/CMakeLists.txt PRE-CREATION autotests/kcookiejar/tests/cookie.test PRE-CREATION autotests/kcookiejar/tests/cookie_rfc.test PRE-CREATION autotests/kcookiejar/tests/cookie_saving.test PRE-CREATION autotests/kcookiejar/tests/cookie_session.test PRE-CREATION autotests/kcookiejar/tests/cookie_settings.test PRE-CREATION src/ioslaves/http/CMakeLists.txt 39fd42f62bd583f92f655739a97a02b09c61 src/ioslaves/http/kcookiejar/CMakeLists.txt 54b1fe0b818f63cd76ac79d5233a3c00da866950 src/ioslaves/http/kcookiejar/tests/CMakeLists.txt src/ioslaves/http/kcookiejar/tests/cookie.test Diff: https://git.reviewboard.kde.org/r/115164/diff/ Testing --- Builds, affected tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115212: Fix windows build + 1 compiler warning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/#review48056 --- Ship it! Just one more thing, then feel free to commit. src/kgesture.cpp https://git.reviewboard.kde.org/r/115212/#comment34019 This should probably have a comment, or some helpful person will come along and change it back :-) I leave the header vs split files thing up to you. - Alex Merry On Jan. 22, 2014, 2:49 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/ --- (Updated Jan. 22, 2014, 2:49 p.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- 4 separate commits: 1. Fix windows build with QT_NO_CAST_FROM_ASCII 2. m_collator already returs bool, remove check for 0 3. Don't use foreach for this loop, it somehow breaks MSVC 4. Don't use uname() and getpwuid() directly Added new functions that also do the right thing on Windows Diffs - src/CMakeLists.txt 4516a9ee3da774788c76f30f15181fa0049a9d86 src/kbugreport.cpp 56f088106becbccca5e9731abc04118a19e36ba9 src/kgesture.cpp 49c927803b2e16806985d758103d3e359aa58dd4 src/kkeysequencewidget.cpp cc9016b776c16984b83a36a2742526ede624bf5e src/ksendbugmail/CMakeLists.txt 12b4926ecddeb023315f6074ab57cfe6cdee65ff src/ksendbugmail/main.cpp 8f85f315f0746bb774175114b1e284e899957fd3 src/ksendbugmail/smtp.cpp 90b6b98467b0c220cfef18bc35cf3c07df9a8cf3 src/kshortcutseditoritem.cpp 086f833fc505f69a3b0dbe6fceffdb94ecd60330 src/systeminformation_p.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115212/diff/ Testing --- now it compiles on windows and Linux is still fine 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 115221: Allow to co-install kjs devel files along with kde4 devel files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115221/ --- (Updated Jan. 22, 2014, 4:23 p.m.) Status -- This change has been discarded. Review request for Build System, KDE Frameworks and David Faure. Repository: kjs Description --- Allow to co-install kjs devel files along with kde4 devel files Diffs - CMakeLists.txt 99b0c4e src/kjs/CMakeLists.txt 8b88cca src/kjs/api/CMakeLists.txt 207d158 src/wtf/CMakeLists.txt dd80388 Diff: https://git.reviewboard.kde.org/r/115221/diff/ Testing --- install done with both files. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/#review48059 --- This review has been submitted with commit fa347de2f5c5954393f6117909b472b4ccf0eb5c by David E. Narvaez to branch master. - Commit Hook On Jan. 22, 2014, 7:01 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 7:01 a.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115212: Fix windows build + 1 compiler warning
On Jan. 22, 2014, 4:28 p.m., Alex Merry wrote: src/kgesture.cpp, lines 382-385 https://git.reviewboard.kde.org/r/115212/diff/2/?file=235218#file235218line382 This should probably have a comment, or some helpful person will come along and change it back :-) Actually, I withdraw my ship it. I have been (quite rightly) berated for letting you get away with the description it breaks MSVC somehow. Feel free to commit the rest of the stuff in this review, but this needs more information at the very least (what problem does it cause? error messages?). - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/#review48056 --- On Jan. 22, 2014, 2:49 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/ --- (Updated Jan. 22, 2014, 2:49 p.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- 4 separate commits: 1. Fix windows build with QT_NO_CAST_FROM_ASCII 2. m_collator already returs bool, remove check for 0 3. Don't use foreach for this loop, it somehow breaks MSVC 4. Don't use uname() and getpwuid() directly Added new functions that also do the right thing on Windows Diffs - src/CMakeLists.txt 4516a9ee3da774788c76f30f15181fa0049a9d86 src/kbugreport.cpp 56f088106becbccca5e9731abc04118a19e36ba9 src/kgesture.cpp 49c927803b2e16806985d758103d3e359aa58dd4 src/kkeysequencewidget.cpp cc9016b776c16984b83a36a2742526ede624bf5e src/ksendbugmail/CMakeLists.txt 12b4926ecddeb023315f6074ab57cfe6cdee65ff src/ksendbugmail/main.cpp 8f85f315f0746bb774175114b1e284e899957fd3 src/ksendbugmail/smtp.cpp 90b6b98467b0c220cfef18bc35cf3c07df9a8cf3 src/kshortcutseditoritem.cpp 086f833fc505f69a3b0dbe6fceffdb94ecd60330 src/systeminformation_p.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115212/diff/ Testing --- now it compiles on windows and Linux is still fine Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kjs framework build failure
Hello, In trying to build frameworks on arch here I'm getting a build error in kjs/src/kjs/operations.cpp I'm not sure what I may be missing here, others report it builds fine on other distros. The offending _isnan seems to be in the original commit also, but I haven't tried to build since the frameworks got split into individual repos. If you know what I may be missing/doing wrong please let me know. I'm using kdesrc-build to build and have cleaned out my build folder and install folders. Attaching my build log. BR, Jeremy # kdesrc-build running: 'make' '-j8' # from directory: /home/jeremy/devel/kde/frameworksbuild/frameworks/kjs Scanning dependencies of target kjs_bin_automoc Scanning dependencies of target KF5JS_automoc Scanning dependencies of target KF5JSApi_automoc Scanning dependencies of target icemaker_automoc Scanning dependencies of target testkjs_static_automoc Scanning dependencies of target testkjs_automoc [ 1%] Scanning dependencies of target kjsapitest_automoc Scanning dependencies of target ecmatest_automoc [ 2%] [ 3%] [ 4%] [ 5%] [ 6%] Automatic moc for target kjs_bin [ 7%] [ 8%] Automatic moc for target KF5JSApi Automatic moc for target testkjs_static Automatic moc for target testkjs Automatic moc for target ecmatest Automatic moc for target KF5JS Automatic moc for target kjsapitest Automatic moc for target icemaker [ 8%] Built target kjs_bin_automoc [ 8%] [ 8%] [ 8%] Built target testkjs_automoc Built target testkjs_static_automoc Built target icemaker_automoc [ 8%] Built target KF5JSApi_automoc Scanning dependencies of target icemaker [ 12%] [ 12%] [ 12%] [ 13%] [ 14%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/codeprinter.cpp.o Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/tablebuilder.cpp.o Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/types.cpp.o Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/lexer.cpp.o Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/driver.cpp.o [ 14%] Built target KF5JS_automoc [ 15%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/parser.cpp.o Generating moc_ecmatest.cpp [ 15%] Built target ecmatest_automoc [ 16%] Building CXX object src/kjs/CMakeFiles/icemaker.dir/icemaker_automoc.cpp.o Generating kjsapitest.moc [ 16%] Built target kjsapitest_automoc Linking CXX executable icemaker [ 16%] Built target icemaker [ 17%] [ 18%] [ 20%] [ 20%] [ 21%] [ 23%] [ 24%] [ 25%] Generating opcodes.h, opcodes.cpp, machine.cpp Generating number_object.lut.h Generating regexp_object.lut.h Generating date_object.lut.h Generating math_object.lut.h Generating string_object.lut.h Generating json_object.lut.h Generating array_object.lut.h icemaker -41.9 for KJS/FrostByte Generating bytecode instruction selection tables and VM dispatcher... [ 26%] Generating lexer.lut.h Scanning dependencies of target KF5JS [ 27%] [ 28%] [ 29%] [ 30%] [ 31%] [ 32%] [ 34%] [ 35%] Building CXX object src/kjs/CMakeFiles/KF5JS.dir/collector.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/grammar.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/ustring.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/nodes.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/date_object.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/lexer.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/lookup.cpp.o Building CXX object src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o /home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp: In function âbool KJS::isNaN(double)â: /home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp:55:20: error: â_isnanâ was not declared in this scope return _isnan(d) != 0; ^ /home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/operations.cpp:59:1: error: control reaches end of non-void function [-Werror=return-type] } ^ cc1plus: some warnings being treated as errors src/kjs/CMakeFiles/KF5JS.dir/build.make:268: recipe for target 'src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o' failed make[2]: *** [src/kjs/CMakeFiles/KF5JS.dir/operations.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs /home/jeremy/devel/kde/frameworks/frameworks/kjs/src/kjs/date_object.cpp:87:12: warning: unused parameter âtâ [-Wunused-parameter] inline int gmtoffset(const tm t) ^ CMakeFiles/Makefile2:103: recipe for target 'src/kjs/CMakeFiles/KF5JS.dir/all' failed make[1]: *** [src/kjs/CMakeFiles/KF5JS.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2 # kdesrc-build running: 'cmake' '/home/jeremy/devel/kde/frameworks/frameworks/kjs' '-DKDE4_BUILD_TESTS=TRUE' '-DLIB_SUFFIX=64' '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE:STRING=debug' '-G' 'CodeBlocks - Unix Makefiles' '-DCMAKE_CXX_FLAGS:STRING=-pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security
Re: Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115213/ --- (Updated Jan. 22, 2014, 4:43 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- As discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 191a2c5 Diff: https://git.reviewboard.kde.org/r/115213/diff/ Testing --- Searched all CMakeLists.txt files of frameworks for that macro, found nothing. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115202: Allow building KConfigWidgets on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115202/ --- (Updated Jan. 22, 2014, 6:20 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Fix compilation on MSVC Diffs - src/kcolorschememanager.cpp 2e44f88d4b613a263047899b102da53541139171 Diff: https://git.reviewboard.kde.org/r/115202/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Splitting kde-workspace and kde-runtime proposal
On Tuesday 21 January 2014 12:05:26 Antonis Tsiapaliokas wrote: 1) Create two different groups named plasma-workspace and plasma-desktop like frameworks 2) Split out every component into individual repos 3) Assign repos to the related group. Advantages: 1) Easy to assign maintainer to individual component. 2) If we split only some repos, we can not mark it as part of workspace but this way we can do it. 3) More, may be? That's my humble suggestion. :) Again, this is a proposal so please! send any feedback you might have. Thanks! I think that splitting each individual component to its own repo might be a bit confusing. Because if we don't have two groups (plasma-desktop and plasma- workspace), then we will not be able to provide something as a standard solution. So each person will consider Plasma Desktop as something entirely different. Note however that it's not a proper argument for splitting repos or not since nowadays our infrastructure has the concept of grouping independently of the repos. So we could split in their own repo and still have a way to make a plasma-desktop and a plasma-workspace group. OTOH Sebas argument is much more compelling. Regards. -- Kévin Ottens, http://ervin.ipsquad.net 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
Tier status of attica kwallet
Hi, attica seems to have been absorbed as a framework, but does not appear to have been assigned a tier. Based on its dependencies, it looks like it would fit in tier 1? kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 it includes kwalletd which depends on higher tier frameworks - does it still belong in tier 2? Best regards, Michael ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Authors, maintainers and licenses in apidox
Hello, On Wednesday 22 January 2014 12:27:29 Alex Merry wrote: On 22/01/14 06:33, Kevin Ottens wrote: On Tuesday 21 January 2014 17:18:36 Alex Merry wrote: Traditionally, the front pages of our apidox has included a list of authors, the maintainer(s) and the license. This is obviously duplicating/summarising information stored elsewhere, and is easy to let get out of date. Yes... definitely easy to get wrong. We should have only one place for that. Do we still want this information? It would probably mean adding it to the README.md files. Are we ditching the LICENSE and AUTHORS files which used to contain this type of information? I'm not sure we want everything in README.md. Well, this is kind of what I mean about duplicating the information. Although the canonical authorship info is the copyright headers and/or git log. My personal view is that authors generally shouldn't be in the apidox main page anyway, as it's not massively useful to users of the dox. Agreed. Authors on individual classes is more useful and more likely to be accurate. Not sure I agree there... the amount of class level author info we had in kdelibs which was outdated look large to me. Having the maintain there is a possibility, or we could just add a link to the frameworks list with the canonical info to the Links section. We have indeed to choose which one will be canonical: the wiki page or some bit in the repository. I don't mind either way, depends what maintainers prefer to edit really. License is potentially useful. Currently the docs do @licenses @lgpl which gives something approximating the markdown ### License(s): [LGPLv2](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1) This is somewhat more succinct than the content of LICENSE tends to be (where that file is even given; we currently don't bother with it if the code is GPL or LGPL; in that case, we have COPYING or COPYING.LIB, containing the full text of the license, instead). I would be tempted to ditch the current LICENSE files (all three of them), and add (summary) license info to README.md, as ## License This framework is licensed under the [LGPLv2](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1) or ## License This framework is licensed under the @lgpl (the latter depends on a doxygen command defined by kapidox). We would (have to) keep COPYING and COPYING.LIB regardless. We might want to add in a second sentence saying that the CMake code is licensed as BSD. I like that. Currently there are a bunch of COPYING-CMAKE-SCRIPTS files around where frameworks ship Find*.cmake modules, which I'm not so keen on (especially as the BSD license text makes little sense unless it has a copyright notice above it). Agreed. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net 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: Tier status of attica kwallet
On Thu, Jan 23, 2014 at 04:24:37AM +1100, Michael Palimaka wrote: attica seems to have been absorbed as a framework, but does not appear to have been assigned a tier. Based on its dependencies, it looks like it would fit in tier 1? The library was renamed to KF5Attica in the expectation it could be a framework but I'd appreciate someone more knowledgeable giving it an eye over to work out if anything else needs to be done to make it a framework. kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 it includes kwalletd which depends on higher tier frameworks - does it still belong in tier 2? Another possibility would be to move kwalletd into a separate git repository but I guess nobody is likely to use the library without the daemon so tier 3 seems more sensible. What needs looked at there is to match up the renamed dbus interface in the daemon with the interface used by the library. I don't think the rename was necessary but it does need the dbus interface file renamed, I've submitted a patch for that to review on reviewboard. Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Tier status of attica kwallet
On Wednesday, 2014-01-22, 17:35:50, Jonathan Riddell wrote: On Thu, Jan 23, 2014 at 04:24:37AM +1100, Michael Palimaka wrote: attica seems to have been absorbed as a framework, but does not appear to have been assigned a tier. Based on its dependencies, it looks like it would fit in tier 1? The library was renamed to KF5Attica in the expectation it could be a framework but I'd appreciate someone more knowledgeable giving it an eye over to work out if anything else needs to be done to make it a framework. kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 it includes kwalletd which depends on higher tier frameworks - does it still belong in tier 2? Another possibility would be to move kwalletd into a separate git repository but I guess nobody is likely to use the library without the daemon so tier 3 seems more sensible. I guess it mostly depends on whether KF wallet is tied to kwalletd or is a client library for any spec conformant secret service. In the first case there is no point in stripping it out, in the second case it might be viable. I have to admit I totally lost the overview over the state of transition to secret service, so that might be another unrelated framework. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115234: Only set QT_STRICT_ITERATORS when not compiling with MSVC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115234/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Only set QT_STRICT_ITERATORS when not compiling with MSVC On MSVC linker errors will happen when this flag is set. Diffs - kde-modules/KDEFrameworkCompilerSettings.cmake d71c407f9c0b504ebb1c0cf662e69545f7a46371 Diff: https://git.reviewboard.kde.org/r/115234/diff/ Testing --- E.g. KConfigWidgets didn't compile before, compiles now Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kate (frameworks) build failure
Hello,
looks like building kate (frameworks branch) fails:
In file included from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/kwrite.h:25:0,
from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/main.cpp:21:
/opt/kf5/include/KF5/KTextEditor/ktexteditor/document.h:122:1: error: expected
class-name before ‘{’ token
{
^
The problem seems to be that KTextEditor::Document derives from
KParts::ReadWritePart, but readwritepart.h (where KParts::ReadWritePart is
defined) is not pulled in by any header file. I think readwritepart.h should
be included somewhere.
Sorry if this is my fault.
Thanks,
Stefano
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115212: Fix windows build + 1 compiler warning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115212/ --- (Updated Jan. 22, 2014, 7:01 p.m.) Review request for KDE Frameworks. Changes --- Dropped the foreach change, this is fixed by https://git.reviewboard.kde.org/r/115234/ Repository: kxmlgui Description (updated) --- 3 separate commits: 1. Fix windows build with QT_NO_CAST_FROM_ASCII 2. m_collator already returs bool, remove check for 0 3. Don't use uname() and getpwuid() directly Added new functions that also do the right thing on Windows Diffs (updated) - src/kbugreport.cpp 56f088106becbccca5e9731abc04118a19e36ba9 src/CMakeLists.txt 4516a9ee3da774788c76f30f15181fa0049a9d86 src/ksendbugmail/CMakeLists.txt 12b4926ecddeb023315f6074ab57cfe6cdee65ff src/ksendbugmail/main.cpp 8f85f315f0746bb774175114b1e284e899957fd3 src/ksendbugmail/smtp.cpp 90b6b98467b0c220cfef18bc35cf3c07df9a8cf3 src/kshortcutseditoritem.cpp 086f833fc505f69a3b0dbe6fceffdb94ecd60330 src/systeminformation_p.h PRE-CREATION src/kkeysequencewidget.cpp cc9016b776c16984b83a36a2742526ede624bf5e Diff: https://git.reviewboard.kde.org/r/115212/diff/ Testing --- now it compiles on windows and Linux is still fine Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kate (frameworks) build failure
Hi,
in ktexteditor/document.h is:
// our main baseclass of the KTextEditor::Document
#include KParts/ReadWritePart
perhaps you need to cleanup your local include dirs ;)
Greetings
Christoph
- Ursprüngliche Mail -
Hello,
looks like building kate (frameworks branch) fails:
In file included from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/kwrite.h:25:0,
from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/main.cpp:21:
/opt/kf5/include/KF5/KTextEditor/ktexteditor/document.h:122:1: error:
expected
class-name before ‘{’ token
{
^
The problem seems to be that KTextEditor::Document derives from
KParts::ReadWritePart, but readwritepart.h (where KParts::ReadWritePart is
defined) is not pulled in by any header file. I think readwritepart.h should
be included somewhere.
Sorry if this is my fault.
Thanks,
Stefano
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kate (frameworks) build failure
Hi,
On Wednesday 22 January 2014 19:12:17 Christoph Cullmann wrote:
Hi,
in ktexteditor/document.h is:
// our main baseclass of the KTextEditor::Document
#include KParts/ReadWritePart
perhaps you need to cleanup your local include dirs ;)
you're right, I knew it was my fault. Pardon me for not having cleaned up the
build dir first.
Thanks,
Stefano
Greetings
Christoph
- Ursprüngliche Mail -
Hello,
looks like building kate (frameworks branch) fails:
In file included from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/kwrite.h:25:0,
from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/main.cpp:21:
/opt/kf5/include/KF5/KTextEditor/ktexteditor/document.h:122:1: error:
expected
class-name before ‘{’ token
{
^
The problem seems to be that KTextEditor::Document derives from
KParts::ReadWritePart, but readwritepart.h (where KParts::ReadWritePart is
defined) is not pulled in by any header file. I think readwritepart.h
should be included somewhere.
Sorry if this is my fault.
Thanks,
Stefano
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115225: Add runtime platform support to KWindowInfo
On Jan. 22, 2014, 4:22 p.m., Aaron J. Seigo wrote:
Looks quite nice, other than the missing win/mac support which you can do
little about at this point.
Use of the explicitly shared pointer approach is a simple and nice
performance booster when passing these objects around (as these tend to).
+1 for that.
I took a moment to ponder if there is enough duplication of window info
objects for the same window ID to make it worthwhile to have a global hash
of winid to dptrs for re-use between separately created instances (and not
just copies of the same instance). In the desktop shell there is at least
one per window for the taskbar and the pager (assuming the pager is active,
anyways); the window runner usually isn't loaded in the shell directly but
were it to be that'd be a third instance. So the highest duplication likely
to be seen is probably 3 and so it isn't worth it.
It's a bit of a shame that the runtime detection requires a dptr full of
virtuals; this is probably only required on Linux/UNIX where there are
multiple window info protocols (xcb, wayland, ..) so sucks for the other
platforms, but I also suspect that this will never actually be used in
practice even on Linux as one is either going to be in a Wayland or X11 (or
whatever) session and switching between them requires logging in/out. It's
private API so it can be changed later if this were ever to actually show
up on in runtime performance which I seriously doubt it will. (I can
imagine sth horrible like a struct/union which has a pointer to an xcb and
a wayland implementation, both of which have the same literal API for
consistency but no base class and then a macro that calls whichever one is
actually instantiated: #define callimpl(method) if (d-xcb) {
d-xcb-method(); } else { d-wayland-method(); } win/mac/etc would have
a rather simpler callimpl macro. yes, ugly as
#($* but it would get rid of the virtuals and allow win/mac/android/etc to be
simple compile-time classes without unnecessary runtime detection features ..
but probably not worth the uglification w/out good justification, which
currently doesn't exist.
I haven't done anything more than add it to the compile, so I can't mark it
as ShipIt with a clean conscience (as I haven't tested it at runtime), but
the code looks good and the design is reasonable imho.
Aaron J. Seigo wrote:
... or a template class instead of the #define, though that adds a layer
of function call indirection I bet it could be 100% inlined functions and be
both fast and non-#define-hackery.
I took a moment to ponder if there is enough duplication of window info
objects for the same window ID to make it worthwhile to have a global hash of
winid to dptrs for re-use between separately created instances
Probably won't work as KWindowInfo doesn't update if the window is changed. One
of the next things I want to do is significantly improve the API documentation
of that class.
or a template class
that sounds like fun (yes I have a strange understanding of what is fun), I'll
think about it.
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/#review48044
---
On Jan. 22, 2014, 3:03 p.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115225/
---
(Updated Jan. 22, 2014, 3:03 p.m.)
Review request for KDE Frameworks and kdewin.
Repository: kwindowsystem
Description
---
Add runtime platform support to KWindowInfo
Main idea of this change is to only pick the X11 implementation in case
that the application is running on the X11 platform. So far it was a
compile time switch which meant that if compiled with X11 support but
not running on the X11 platform it would have caused runtime errors.
To make this possible a KWindowInfoPrivate class with a dummy
implementation is provided. This is used as d-ptr for KWindowInfo.
Thus there is one generic implementation and the implementation of
KWindowInfo is no longer ifdefed for the supported platforms.
The platform specific code can inherit from KWindowInfoPrivate and
overwrite the dummy method implementation. KWindowInfoPrivate provides
a factory method where the platform specific implementation can be
hooked into. There we can have both compile time and runtime checking.
If there is no platfom specific implementation available the dummy
implementation is used.
NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND!
Windows and Mac is excluded from build. At the moment they get the
dummy implementation. Unfortunately I don't have the possibility
Re: Review Request 115225: Add runtime platform support to KWindowInfo
On Jan. 22, 2014, 4:32 p.m., David Edmundson wrote: src/kwindowinfo.cpp, line 191 https://git.reviewboard.kde.org/r/115225/diff/2/?file=235203#file235203line191 This seems wrong. KWindowInfo cheese; cheese.state(); //CRASH I kept the ctor as it's documented as makes QList happy. I don't really get why it is there and it looks wrong to me and I think it's a stupid idea to put KWindowInfo into a QList at all. If other people agree that we can do an API break (hello Kevin or David F.) I'll happily remove the ctor and document the API break. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/#review48048 --- On Jan. 22, 2014, 3:03 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 22, 2014, 3:03 p.m.) Review request for KDE Frameworks and kdewin. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs - src/CMakeLists.txt e32a1150a2c190f23ad456ca8218b012c5d71507 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115236: Get closer to compiling KIO on windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115236/ --- Review request for KDE Frameworks. Repository: kio Description --- 3 Commits to get closer to compiling on windows: 1. Include qplatformdefs.h where possible unistd.h and others are not available on e.g. Windows, qplatformdefs.h includes the equivalent for each platform 2. add include(CheckLibraryExists) to CMakeLists.txt On Linux this is apparently pulled in by some other file whereas it is missing on Windows 3. Make KIO::MetaData completely inline to prevent linker errors on MSVC Diffs - src/ioslaves/ftp/ftp.h ad94979829a5d0e71ec57177b51f67e115c5445e src/ioslaves/ftp/ftp.cpp 9ea642587bd754f0b4295fcb7d4db1b427f4326e src/ioslaves/help/kio_help.h 0eab4ce1b393b48e552ca94d877f4c069450cee0 src/ioslaves/http/http.cpp 4f97b335c0e206f0a2ff8cfd515d0fae79614ad2 src/ioslaves/http/http_cache_cleaner.cpp ffa8ab9580acf554b27027617cdac06b3f7755bf src/widgets/kdirmodel.cpp ce6e4c9aaddada5715b5aeef36ad163c77d3c635 src/widgets/kpropertiesdialog.cpp 8ddd37f0326e37109ce239a46bfa67d2f4c35411 src/widgets/krun.cpp 92dcfd8da04b9f3d80b632a37758017c088093ab src/widgets/kurlcompletion.cpp ed77fd3213db0524b5a934c94eb7645d98bd27c7 tests/kioslavetest.cpp dc56240dc166dfa93ec099db5cdd262cc06249d4 tests/kruntest.cpp 68720ddf788e6b44468baf18dd04937094741274 CMakeLists.txt 9894ad5e1696fe31d8a3f065d29747cde0474d2c autotests/fileundomanagertest.cpp 4ddee49eed254be6379a1302af2dd17aae28c15c autotests/kurlcompletiontest.cpp 10048e2e15059596e446b03cedb0b302bf038cd5 src/core/chmodjob.cpp b60cb9bf3d3b1a71a795ee5db7c72253dbdf0ad2 src/core/kacl.h 3c9c88d0408c855d02eaacb34d14f45c55343eb2 src/core/kacl.cpp 201b30a02ef93a137b9a8507cabaece6926d8739 src/core/kfileitem.h 553dbf8ccf96983803d0224cf8dc9d72f0107b6a src/core/kfileitem.cpp fdc0fc0279713887dc18ce1da8d3b00d422f6a9b src/core/kprotocolmanager.cpp a8746a4f9a78e6a01eaed6a70e99146ff40129d2 src/core/krecentdocument.cpp ad0a97e7c1af85a94bb7483124b5035f0fca38a6 src/core/metadata.h cd62e3b009c21485537ddd5449a6c347748c3caf src/core/metadata.cpp ad05032dff58314a305256993fcc7fe7b94751bc src/core/slave.h 43b5cd8e8aa11da55d6f8a8d9fdf4eb3d0780d11 src/core/slave.cpp ef9b3c7a57b4f4384343c4d4296ec88add857eb6 src/core/slavebase.cpp a7ac4d5a6a87c256da9a3947b7223649927eba39 src/core/slaveinterface.h d75eb6b02374375a73e1aaa57d5c2979a3bc365f src/core/slaveinterface.cpp faa4bd7dc1b5a733f0060f60626e8a0313bfea8a src/core/slaveinterface_p.h 0ed4980a06f8aa8b3fc8c0717e4a88991483e98a src/filewidgets/kfileplaceeditdialog.cpp a7c433c8baecca8082f8d80077deab68e4b0cec2 src/filewidgets/knewfilemenu.cpp dfc086b6e98b965739c062d7291bbd9139633beb src/ioslaves/file/file.h 453298159791a78d877c4d81d2be73db073db3f2 src/ioslaves/file/file.cpp e3ede0daa8054fc33d12acb9966a707f9484cd98 src/ioslaves/file/file_win.cpp 53e0f8f133bd5c4cbbd07afa945854efffc7297c Diff: https://git.reviewboard.kde.org/r/115236/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115237: Relocate KDE4_CREATE_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115237/ --- Review request for KDE Frameworks and Luigi Toscano. Repository: kde4support Description --- Moving it from KDocTools. Defined as a forward to the new command KDOCTOOLS_CREATE_HANDBOOK. Notice that the description of the command changed to document the actual name of the target created. Diffs - cmake/modules/KDE4Macros.cmake a3894ae Diff: https://git.reviewboard.kde.org/r/115237/diff/ Testing --- Tried using this on a Kig build for frameworks. The warning message is displayed and the doc-handbook target is created for folder doc. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Tier status of attica kwallet
On Thursday, January 23, 2014 04:24:37 AM Michael Palimaka wrote: Hi, attica seems to have been absorbed as a framework, but does not appear to have been assigned a tier. Based on its dependencies, it looks like it would fit in tier 1? kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 it includes kwalletd which depends on higher tier frameworks - does it still belong in tier 2? kwallet-framework is still tier2, as there are no higher dependencies, AFAIK. -- Valentin Rusu irc: valir ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115218: rename dbus interface file on install for kwallet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115218/#review48079 --- src/api/KWallet/CMakeLists.txt https://git.reviewboard.kde.org/r/115218/#comment34033 The interface will be strictly the same. New features will be added to secret service. That's why I didn't consider changing it's name. And, btw, changing it's name will make users think that changes have been (or will be) done to this API. - Valentin Rusu On Jan. 22, 2014, 11:23 a.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115218/ --- (Updated Jan. 22, 2014, 11:23 a.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Rename kwallet dbus interface file on install so it does not clash with equivalent file from kdelibs4. The dbus interface remains the same to keep compatibility with kdelibs4 kwallet. However you seem to have renamed the interface in places in the code in runtime/, will it be incompatible with the version from kdelibs4? Diffs - src/api/KWallet/CMakeLists.txt d0d5a3d Diff: https://git.reviewboard.kde.org/r/115218/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115237: Relocate KDE4_CREATE_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115237/ --- (Updated Jan. 22, 2014, 9:28 p.m.) Review request for KDE Frameworks and Luigi Toscano. Changes --- Pointing to the original discussion in the description. Repository: kde4support Description (updated) --- Moving it from KDocTools, as discussed in Review Request 115077. Defined as a forward to the new command KDOCTOOLS_CREATE_HANDBOOK. Notice that the description of the command changed to document the actual name of the target created. Diffs - cmake/modules/KDE4Macros.cmake a3894ae Diff: https://git.reviewboard.kde.org/r/115237/diff/ Testing --- Tried using this on a Kig build for frameworks. The warning message is displayed and the doc-handbook target is created for folder doc. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115239: Relocate KDE4_CREATE_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115239/ --- Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Moved to KDE4Support as discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 5bb0f72 Diff: https://git.reviewboard.kde.org/r/115239/diff/ Testing --- Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: ktexteditor_master_qt5 #120
See http://build.kde.org/job/ktexteditor_master_qt5/120/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115218: rename dbus interface file on install for kwallet
On Jan. 22, 2014, 9:27 p.m., Valentin Rusu wrote: src/api/KWallet/CMakeLists.txt, line 100 https://git.reviewboard.kde.org/r/115218/diff/1/?file=235142#file235142line100 The interface will be strictly the same. New features will be added to secret service. That's why I didn't consider changing it's name. And, btw, changing it's name will make users think that changes have been (or will be) done to this API. @Valentin, interface name is now org.kde.kwalletd5, as per your last change in api/KWallet/kwallet.cpp runtime/kwalletd/kwalletd.cpp. - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115218/#review48079 --- On Jan. 22, 2014, 11:23 a.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115218/ --- (Updated Jan. 22, 2014, 11:23 a.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Rename kwallet dbus interface file on install so it does not clash with equivalent file from kdelibs4. The dbus interface remains the same to keep compatibility with kdelibs4 kwallet. However you seem to have renamed the interface in places in the code in runtime/, will it be incompatible with the version from kdelibs4? Diffs - src/api/KWallet/CMakeLists.txt d0d5a3d Diff: https://git.reviewboard.kde.org/r/115218/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Tier status of attica kwallet
On Wednesday 22 January 2014 22:21:47 Valentin Rusu wrote: On Thursday, January 23, 2014 04:24:37 AM Michael Palimaka wrote: Hi, attica seems to have been absorbed as a framework, but does not appear to have been assigned a tier. Based on its dependencies, it looks like it would fit in tier 1? kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 it includes kwalletd which depends on higher tier frameworks - does it still belong in tier 2? kwallet-framework is still tier2, as there are no higher dependencies, AFAIK. If it depends on anything else which is not in Qt or tier 1, it automatically becomes tier 3. It can't depend on anything which is tier 2. Regards. -- Kévin Ottens, http://ervin.ipsquad.net 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: Review Request 115237: Relocate KDE4_CREATE_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115237/#review48082 --- Ship it! As I wrote in the original review request, fine with me (other opinions are welcome of course!) - Luigi Toscano On Jan. 22, 2014, 9:28 p.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115237/ --- (Updated Jan. 22, 2014, 9:28 p.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kde4support Description --- Moving it from KDocTools, as discussed in Review Request 115077. Defined as a forward to the new command KDOCTOOLS_CREATE_HANDBOOK. Notice that the description of the command changed to document the actual name of the target created. Diffs - cmake/modules/KDE4Macros.cmake a3894ae Diff: https://git.reviewboard.kde.org/r/115237/diff/ Testing --- Tried using this on a Kig build for frameworks. The warning message is displayed and the doc-handbook target is created for folder doc. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115239: Relocate KDE4_CREATE_HANDBOOK
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115239/#review48084 --- Ship it! As I wrote in the original review request, fine with me (other opinions are welcome of course!) - Luigi Toscano On Jan. 22, 2014, 9:29 p.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115239/ --- (Updated Jan. 22, 2014, 9:29 p.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Moved to KDE4Support as discussed in Review Request 115077 Diffs - KF5DocToolsMacros.cmake 5bb0f72 Diff: https://git.reviewboard.kde.org/r/115239/diff/ Testing --- Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : ktexteditor_master_qt5 #121
See http://build.kde.org/job/ktexteditor_master_qt5/121/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115238: Bug in KDEPlatformFileDialogHelper(?) causes selectFile not to work in QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115238/ --- Review request for KDE Frameworks and David Faure. Repository: frameworkintegration Description --- Bug in KDEPlatformFileDialogHelper (or related code) as described below. The patch extends the qfiledialogtest so that the following command is possible: Run ./qfiledialogtest --acceptMode save --selectFile ~/moo.png Expected: - a Save File Dialog opens and the text field is filled with moo.png and the directory switches to the given path - The OK button is active so that the user can click it and the dialog closes Actual: - a Save File Dialog opens but the text field is NOT filled and the location does not change - The OK button is not active - Workaround: click on an existing file and the OK button becomes active Diffs - tests/qfiledialogtest.cpp 3ef79a2b6787bd42dfa32a6c641589755436 Diff: https://git.reviewboard.kde.org/r/115238/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115238: Bug in KDEPlatformFileDialogHelper(?) causes selectFile not to work in QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115238/ --- (Updated Jan. 22, 2014, 10:26 p.m.) Review request for KDE Frameworks and David Faure. Repository: frameworkintegration Description --- Bug in KDEPlatformFileDialogHelper (or related code) as described below. The patch extends the qfiledialogtest so that the following command is possible: Run ./qfiledialogtest --acceptMode save --selectFile ~/moo.png Expected: - a Save File Dialog opens and the text field is filled with moo.png and the directory switches to the given path - The OK button is active so that the user can click it and the dialog closes Actual: - a Save File Dialog opens but the text field is NOT filled and the location does not change - The OK button is not active - Workaround: click on an existing file and the OK button becomes active Diffs (updated) - tests/qfiledialogtest.cpp 3ef79a2b6787bd42dfa32a6c641589755436 Diff: https://git.reviewboard.kde.org/r/115238/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: ktexteditor_master_qt5 #122
See http://build.kde.org/job/ktexteditor_master_qt5/122/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115238: Bug in KDEPlatformFileDialogHelper(?) causes selectFile not to work in QFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115238/#review48086 --- Ship it! tests/qfiledialogtest.cpp https://git.reviewboard.kde.org/r/115238/#comment34038 no need for this debug. Thanks for improving the test, will have to look into the implementation. :) - Aleix Pol Gonzalez On Jan. 22, 2014, 10:26 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115238/ --- (Updated Jan. 22, 2014, 10:26 p.m.) Review request for KDE Frameworks and David Faure. Repository: frameworkintegration Description --- Bug in KDEPlatformFileDialogHelper (or related code) as described below. The patch extends the qfiledialogtest so that the following command is possible: Run ./qfiledialogtest --acceptMode save --selectFile ~/moo.png Expected: - a Save File Dialog opens and the text field is filled with moo.png and the directory switches to the given path - The OK button is active so that the user can click it and the dialog closes Actual: - a Save File Dialog opens but the text field is NOT filled and the location does not change - The OK button is not active - Workaround: click on an existing file and the OK button becomes active Diffs - tests/qfiledialogtest.cpp 3ef79a2b6787bd42dfa32a6c641589755436 Diff: https://git.reviewboard.kde.org/r/115238/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : ktexteditor_master_qt5 #123
See http://build.kde.org/job/ktexteditor_master_qt5/123/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
