Re: kdelibs/interfaces/khexedit
On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote: Input welcome. Once upon a time those interfaces were invented to enable KPilot (yes, those times) to be able to use the hexedit widget I did then, without having these rather specific widget in kdelibs or having kdepim depend on kdeutils (where the lib was then living hidden away in a khexedit subdir, while not used by khexedit itself). These days I know of no other user besides KDevelop as well (somewhere in the debugging area IIRC). But it has been proposed to use the Okteta libs directly there, as the Okteta libs are already used directly in another place in KDevelop (for the hex editing plugin). It just needs someone to do the coding. Ah, interesting. So from my point of view, especially given the idea of KF5, I see no more need for interfaces/khexedit. Rather do I see the Okteta libs themselves (the core ones for simple widget things) one day being added to KF5, now that things are modular :) Yep, makes sense. I'll just delete interfaces/khexedit then, thanks for the input. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/#review43321 --- tier4/kde4support/src/CMakeLists.txt http://git.reviewboard.kde.org/r/113670/#comment31193 Why was this line removed? Everything else looks fine to me, this remove seems unrelated though. - David Faure On Nov. 8, 2013, 9:04 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 8, 2013, 9:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest 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 113723: Fix KIO to build standalone, prepare for moving into its tier
On Nov. 9, 2013, 12:47 a.m., David Faure wrote: staging/kio/CMakeLists.txt, line 34 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line34 Why? KDED doesn't provide a library. Àlex Fiestas wrote: It provides a DBus interface (.xml) that is installed and later on used in kcookiejar to generate c++ code. Ah, I see, the command-line tool kcookiejar5 uses kded.loadModule and kded.unloadModule. We could get rid of the compile-time dependency by making dynamic dbus calls, but the runtime dependency would still exist anyway, so not much point. OK then -- please add a comment on that line like # for org.kde.kded5.xml - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/#review43285 --- On Nov. 8, 2013, 5:01 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/ --- (Updated Nov. 8, 2013, 5:01 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- As you will see, this splitting was a bit harder than others: - KIO was using a couple of private headers from kjobwidgets, which now they will be installed. - The xslt_kde target was being used from KDocTools without having it exported. Now it will be properly exported. - Also defines all dependencies so it can be compiled independently, modularization is done as well. Diffs - tier2/kdoctools/src/CMakeLists.txt 3940e98 tier2/kdoctools/KDocToolsConfig.cmake.in PRE-CREATION tier2/kdoctools/KDocToolsConfig.cmake d501dc8 tier2/kdoctools/CMakeLists.txt c2256ff superbuild/CMakeLists.txt 458fb4c tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c5 staging/kio/tests/CMakeLists.txt 6cee291 staging/kio/src/widgets/CMakeLists.txt d90386d staging/kio/src/ioslaves/http/tests/CMakeLists.txt 52c9f6c staging/kio/src/ioslaves/http/kcookiejar/CMakeLists.txt b0feff6 staging/kio/src/ioslaves/help/CMakeLists.txt 40637dc staging/kio/src/filewidgets/CMakeLists.txt 31fe8c6 staging/kio/CMakeLists.txt 6c7297e cmake/modules/FindGSSAPI.cmake cmake/modules/CMakeLists.txt 7910270 tier3/kded/KDEDConfig.cmake.in 32f8d56 tier3/kservice/src/CMakeLists.txt cc0c1a4 Diff: http://git.reviewboard.kde.org/r/113723/diff/ Testing --- Builds, Installs, tests still pass; both modularized and monolithic kdelibs. 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 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43323 --- Ship it! OK. I only meant don't remove existing code that might make sense for some users. But if the real solution for Solaris support is to do it in Qt rather than here, then this code doesn't make sense anymore, remove it. - David Faure On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/ --- (Updated Oct. 22, 2013, 4:49 p.m.) Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. Repository: kde-runtime Description --- Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out that all the stuff KTZD was doing was added in QTimeZone, that includes reading correct system files/env variables to obtain the timezone and returning the proper system zone (KTZD did all this by itself). It also doesn't need to parse the timezone files itself or watch for their changes as QTimeZone objects are not stored. So now it's just a thin module watching /etc/timezone (used by Debian-based distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian in conjunction with /etc/timezone) for changes and if it detects a change, it checks if the new timezone is really different and if it is, it sends out a DBus signal timeZoneChange. I changed it from configChanged as I think timeZoneChanged makes way more sense. I didn't touch the Windows part as I have no way to test, would be nice if someone could help with that. EDIT: I removed the other two DBus signals which were not used and I'm unsure KTZD is the correct place for that now anyway. The only usage in KSystemTimeZone can be replaced by own KDirWatch instance. Diffs - CMakeLists.txt a5ec93d ktimezoned/CMakeLists.txt bafc85e ktimezoned/ktimezoned.h ff21807 ktimezoned/ktimezoned.cpp f380c09 ktimezoned/ktimezoned_win.h 26e21cc ktimezoned/ktimezoned_win.cpp cadfe3a ktimezoned/ktimezonedbase.h ca00aca ktimezoned/org.kde.KTimeZoned.xml daaa0b7 Diff: http://git.reviewboard.kde.org/r/113260/diff/ Testing --- Tested by changing the timezone in different ways, change was detected and signalled out. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KModifierKeyInfo usage and API
Aaron? Anyone from the plasma team? I would appreciate input on this (see precise question at the end), it's preventing KF5 from moving forward with KModifierKeyInfo. Please CC kde-frameworks-devel, I'm not on plasma-devel. On Wednesday 16 October 2013 09:56:03 David Faure wrote: We are still a bit unsure what to do about KModifierKeyInfo in KF5: * It's currently only implemented on X11 (PovAddict says querying for modifiers on Windows is easy to add, but getting notified of changes seems quite problematic) * The API (latching vs locking) seems to be a bit too X11 specific, it's unsure that these concepts exist on other platforms (issue raised in http://git.reviewboard.kde.org/r/112443/#review41013) * gwenview was ported away from it (a simple keyPress handler takes care of notifying the app that Ctrl was pressed) * This leaves two users for KModifierKeyInfo as far as lxr.kde.org can see: 1) kile uses it to query the status of Caps Lock at the time when a key is pressed. It uses isKeyLatched()||isKeyLocked() so clearly it doesn't need the distinction. 2) Plasma's KeyService offers the KModifierKeyInfo API in the KeyStatesEngine. Not sure how to then find the users of that general search on keystate found this: http://lxr.kde.org/source/kde/kdeplasma-addons/applets/plasmaboard/widget.cpp but I can't find the actual use of the engine in there? Can a plasma developer tell me how to find the use of this stuff, to see how much we can change its API? Thanks. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdelibs/interfaces/khexedit
On Sunday 10 November 2013 09:47:41 David Faure wrote: On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote: Input welcome. Once upon a time those interfaces were invented to enable KPilot (yes, those times) to be able to use the hexedit widget I did then, without having these rather specific widget in kdelibs or having kdepim depend on kdeutils (where the lib was then living hidden away in a khexedit subdir, while not used by khexedit itself). These days I know of no other user besides KDevelop as well (somewhere in the debugging area IIRC). But it has been proposed to use the Okteta libs directly there, as the Okteta libs are already used directly in another place in KDevelop (for the hex editing plugin). It just needs someone to do the coding. Ah, interesting. So from my point of view, especially given the idea of KF5, I see no more need for interfaces/khexedit. Rather do I see the Okteta libs themselves (the core ones for simple widget things) one day being added to KF5, now that things are modular :) Yep, makes sense. I'll just delete interfaces/khexedit then, thanks for the input. Btw, this is basically the same solution as we take with KTextEditor: The KTextEditor interfaces are not part of some other module anymore. Instead they are directly shipped with Kate Part for KF5. This makes sense for the simple reason that there is no other KTextEditor implementation than Kate Part (for 10 years now). From this perspective. The same basically holds for Okteta imo: If you need a hex editor component, just state that as dependency at compile time and all is fine. So as I see it, removing interfaces/khexedit is the right way to go :-) Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43331 --- Ship it! Ship It! - John Layt On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/ --- (Updated Oct. 22, 2013, 4:49 p.m.) Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. Repository: kde-runtime Description --- Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out that all the stuff KTZD was doing was added in QTimeZone, that includes reading correct system files/env variables to obtain the timezone and returning the proper system zone (KTZD did all this by itself). It also doesn't need to parse the timezone files itself or watch for their changes as QTimeZone objects are not stored. So now it's just a thin module watching /etc/timezone (used by Debian-based distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian in conjunction with /etc/timezone) for changes and if it detects a change, it checks if the new timezone is really different and if it is, it sends out a DBus signal timeZoneChange. I changed it from configChanged as I think timeZoneChanged makes way more sense. I didn't touch the Windows part as I have no way to test, would be nice if someone could help with that. EDIT: I removed the other two DBus signals which were not used and I'm unsure KTZD is the correct place for that now anyway. The only usage in KSystemTimeZone can be replaced by own KDirWatch instance. Diffs - CMakeLists.txt a5ec93d ktimezoned/CMakeLists.txt bafc85e ktimezoned/ktimezoned.h ff21807 ktimezoned/ktimezoned.cpp f380c09 ktimezoned/ktimezoned_win.h 26e21cc ktimezoned/ktimezoned_win.cpp cadfe3a ktimezoned/ktimezonedbase.h ca00aca ktimezoned/org.kde.KTimeZoned.xml daaa0b7 Diff: http://git.reviewboard.kde.org/r/113260/diff/ Testing --- Tested by changing the timezone in different ways, change was detected and signalled out. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113696: Rename knewstuff private headers to _p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113696/#review43332 --- Ship it! No change was needed in CMakeLists.txt, therefore it's correct (provided that make install still works) :) - David Faure On Nov. 6, 2013, 7:17 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113696/ --- (Updated Nov. 6, 2013, 7:17 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Renamed knewstuff private headers to _p.h and adjusted #include's accordingly. Diffs - tier3/knewstuff/src/attica/atticaprovider.h 38aacfa377c91c54951eec9923f9b1712a0f4e32 tier3/knewstuff/src/attica/atticaprovider.cpp b077b23a3decb644b6ab5d15dc1283dfcd0e05b2 tier3/knewstuff/src/core/author.h tier3/knewstuff/src/core/author.cpp 12cde54d806fdf674fb413d59a586db831de082d tier3/knewstuff/src/core/cache.h 03373377cb91df9d5448e6231b008bd7949a8364 tier3/knewstuff/src/core/cache.cpp 66e3ed13c690437cbbb3a43a518e22b5d5240581 tier3/knewstuff/src/core/engine.h 7f0bc3021ef21b1621bff51fcb76e0579452f6e7 tier3/knewstuff/src/core/engine.cpp 941b1d0753320f57641c868f94959d9bf93148f7 tier3/knewstuff/src/core/entryinternal.h 08f6dcf02e0a765a80a0df24375381e1d6fdf909 tier3/knewstuff/src/core/entryinternal.cpp 2eb592d771dbc3f5ec1e38b7c7d0231b49736543 tier3/knewstuff/src/core/installation.h aec5e71d449a3e13108e636553a721b56a1af08f tier3/knewstuff/src/core/installation.cpp 7ec710ac80ae2011e9d975aa5d00763b04b084bd tier3/knewstuff/src/core/provider.h 0e3f7bc6efd3d205442c70d79035984848a1b7c8 tier3/knewstuff/src/core/provider.cpp 294d8665971e8547abfccd47785f655a85d8796b tier3/knewstuff/src/core/security.h tier3/knewstuff/src/core/security.cpp eec03c39d3f1b5296ddd81525f4868359b46497c tier3/knewstuff/src/core/upload.h tier3/knewstuff/src/core/upload.cpp ef62cf10ad1d580df8b894ac70044ad9a286b827 tier3/knewstuff/src/core/xmlloader.h tier3/knewstuff/src/core/xmlloader.cpp 65b6de95c4902adb1beb2761dec54d7526036b2b tier3/knewstuff/src/downloadmanager.cpp df06786b0cf136c2f7f52e85cbeb7a61835acad6 tier3/knewstuff/src/downloadwidget.cpp 1d56e1106fb3ce1aa3f4a7f3b07a68732101b3ce tier3/knewstuff/src/downloadwidget.ui 17f2944e81c0510eb7ae85128e79e815eab1bf54 tier3/knewstuff/src/downloadwidget_p.h 080e1779e0d2ed110da28cc087218262fad1f333 tier3/knewstuff/src/entry_p.h 73c1ee8619b171f90706ba3ed323abbd00add455 tier3/knewstuff/src/staticxml/staticxmlprovider.h 52caed08f53d125928d12f329c96800530d9fcaa tier3/knewstuff/src/staticxml/staticxmlprovider.cpp e7dd0686f122c938cf87959478acc97a0a25723b tier3/knewstuff/src/ui/entrydetailsdialog.h 0add71dfecd4f0cb8653e9a90568bad5d9d2e008 tier3/knewstuff/src/ui/entrydetailsdialog.cpp 5a451086531c53af720a2874f5c3b5ed51d07423 tier3/knewstuff/src/ui/imageloader.h 5e87a7b7890b6678c4b94aacc1b2f84d001b7dd0 tier3/knewstuff/src/ui/imageloader.cpp 8e6ed061e421e985535228599ff9da17303bae46 tier3/knewstuff/src/ui/imagepreviewwidget.h tier3/knewstuff/src/ui/imagepreviewwidget.cpp d9d20775a9686715176ead2f24f122d82b88987b tier3/knewstuff/src/ui/itemsgridviewdelegate.h a5d793d8c859c25639921cc9a05233cb9879377e tier3/knewstuff/src/ui/itemsgridviewdelegate.cpp 3970287927e8c17acc9347adbae4c342c78d389a tier3/knewstuff/src/ui/itemsmodel.h 7bc691483b3f0a27dc0d35a7fa6a4ad877294c1a tier3/knewstuff/src/ui/itemsmodel.cpp d972c53f2963dba4ed55bfb484005b77b056c323 tier3/knewstuff/src/ui/itemsview.h tier3/knewstuff/src/ui/itemsview.cpp b200b651bf1c57b37c7d8cb8163246488e6b17fb tier3/knewstuff/src/ui/itemsviewbasedelegate.h bbb08dbc1755b9d9c5bde20c27e7bf368c149c29 tier3/knewstuff/src/ui/itemsviewbasedelegate.cpp 89e91f9563f95985759388dcfca76d480a9dedba tier3/knewstuff/src/ui/itemsviewdelegate.h 1df97a36fc72d9eb3b2d07c5edff0170db459ea5 tier3/knewstuff/src/ui/itemsviewdelegate.cpp 5289ee0093e7e4d02e6250bad8807f7c7e0d04c7 tier3/knewstuff/src/ui/progressindicator.h tier3/knewstuff/src/ui/progressindicator.cpp ab06ff19c103c4d809d9ef4b14586bcd936e75c5 tier3/knewstuff/src/upload/atticahelper.h tier3/knewstuff/src/upload/atticahelper.cpp c17b743c29943fbd25020dc9c8b7a0862cdc2458 tier3/knewstuff/src/uploaddialog_p.h 084d626c095465b5176aa928fed1d6d6342e6e2d Diff: http://git.reviewboard.kde.org/r/113696/diff/ Testing --- It still builds. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Re: Review Request 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43334 --- tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31212 Prefer constructor-syntax over C casts. i.e. qint64(value) rather than (qint64)(value). C casts (in general, not in this particular instance) can lead to a lot of trouble, I like code to compile with -Wold-style-cast. tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31214 You can even make that a warning - I don't think it's every supposed to happen. tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31215 Thank you, this is much safer than popen indeed... tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31216 This could be improved to avoid loading the whole image in memory, given that QImageReader can read incrementally from a QIODevice. (but I won't block this commit for that, it was there before ;) tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31218 isn't there a better method to call than pid()? - David Faure On Nov. 7, 2013, 11:32 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 7, 2013, 11:32 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113705: Remove unused TIFF kimgio code
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/#review43335 --- Ship it! I trust that you compared them and they had the same features? - David Faure On Nov. 7, 2013, 11:41 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/ --- (Updated Nov. 7, 2013, 11:41 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove unused TIFF kimgio code Qt already has a TIFF imageformat plugin, so there is no need to resurrect this. Diffs - tier1/kguiaddons/src/plugins/imageformats/g3r.h 5d43d6fd90bcd54cba71c775e6c7536c6f42ac30 tier1/kguiaddons/src/plugins/imageformats/g3r.cpp 1e32e1607d750912119c7d76c6e3cfcbd72491de Diff: http://git.reviewboard.kde.org/r/113705/diff/ Testing --- Compiles. 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 113708: Make kcmutils build standalone
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113708/#review43336 --- Ship it! Ship It! - David Faure On Nov. 7, 2013, 3:36 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113708/ --- (Updated Nov. 7, 2013, 3:36 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kcmutils build standalone. I'll add it to superbuild when commiting. Diffs - tier4/kcmutils/CMakeLists.txt ef65009 tier4/kcmutils/src/CMakeLists.txt daeb662 Diff: http://git.reviewboard.kde.org/r/113708/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KModifierKeyInfo usage and API
Hello! It looks like keystate applet which was removed from KDE4 was(?) the user of keystate dataengine. If we bring back this applet in Plasma2 then this DataEngine will be used. And this applet is necessary for disabled people, See https://bugs.kde.org/show_bug.cgi?id=165402 Thanks! On Sun, Nov 10, 2013 at 2:46 PM, David Faure fa...@kde.org wrote: Aaron? Anyone from the plasma team? I would appreciate input on this (see precise question at the end), it's preventing KF5 from moving forward with KModifierKeyInfo. Please CC kde-frameworks-devel, I'm not on plasma-devel. On Wednesday 16 October 2013 09:56:03 David Faure wrote: We are still a bit unsure what to do about KModifierKeyInfo in KF5: * It's currently only implemented on X11 (PovAddict says querying for modifiers on Windows is easy to add, but getting notified of changes seems quite problematic) * The API (latching vs locking) seems to be a bit too X11 specific, it's unsure that these concepts exist on other platforms (issue raised in http://git.reviewboard.kde.org/r/112443/#review41013) * gwenview was ported away from it (a simple keyPress handler takes care of notifying the app that Ctrl was pressed) * This leaves two users for KModifierKeyInfo as far as lxr.kde.org can see: 1) kile uses it to query the status of Caps Lock at the time when a key is pressed. It uses isKeyLatched()||isKeyLocked() so clearly it doesn't need the distinction. 2) Plasma's KeyService offers the KModifierKeyInfo API in the KeyStatesEngine. Not sure how to then find the users of that general search on keystate found this: http://lxr.kde.org/source/kde/kdeplasma-addons/applets/plasmaboard/widget.cpp but I can't find the actual use of the engine in there? Can a plasma developer tell me how to find the use of this stuff, to see how much we can change its API? Thanks. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113730: Fix kpty standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113730/#review43337 --- Ship it! Ship It! - David Faure On Nov. 9, 2013, 10:54 a.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113730/ --- (Updated Nov. 9, 2013, 10:54 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kpty build standalone and with superbuild. I'm not sure if installing kprocess_p.h is the correct solution. Diffs - superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c56bea27fe26916bf5a7cbef612613578fd tier3/kpty/CMakeLists.txt f96ecabd729aea9f48e89ccc222517096487d780 tier3/kpty/src/ConfigureChecks.cmake a385e17276d8f9a3598f1434bd0da5e8b25f0218 tier3/kpty/tests/CMakeLists.txt f78e3fe105aae313dcb5eeb7524c12a8e8533bf0 Diff: http://git.reviewboard.kde.org/r/113730/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113705: Remove unused TIFF kimgio code
On Nov. 10, 2013, 11:33 a.m., David Faure wrote: I trust that you compared them and they had the same features? Qt's version is better in every way, as far as I can tell. - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/#review43335 --- On Nov. 7, 2013, 11:41 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/ --- (Updated Nov. 7, 2013, 11:41 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove unused TIFF kimgio code Qt already has a TIFF imageformat plugin, so there is no need to resurrect this. Diffs - tier1/kguiaddons/src/plugins/imageformats/g3r.h 5d43d6fd90bcd54cba71c775e6c7536c6f42ac30 tier1/kguiaddons/src/plugins/imageformats/g3r.cpp 1e32e1607d750912119c7d76c6e3cfcbd72491de Diff: http://git.reviewboard.kde.org/r/113705/diff/ Testing --- Compiles. 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 113705: Remove unused TIFF kimgio code
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/#review43342 --- This review has been submitted with commit 387c2a9f9d105a210082df45c3947c2ef6e55115 by Alex Merry to branch frameworks. - Commit Hook On Nov. 7, 2013, 11:41 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/ --- (Updated Nov. 7, 2013, 11:41 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove unused TIFF kimgio code Qt already has a TIFF imageformat plugin, so there is no need to resurrect this. Diffs - tier1/kguiaddons/src/plugins/imageformats/g3r.h 5d43d6fd90bcd54cba71c775e6c7536c6f42ac30 tier1/kguiaddons/src/plugins/imageformats/g3r.cpp 1e32e1607d750912119c7d76c6e3cfcbd72491de Diff: http://git.reviewboard.kde.org/r/113705/diff/ Testing --- Compiles. 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 113705: Remove unused TIFF kimgio code
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113705/ --- (Updated Nov. 10, 2013, 1:51 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Remove unused TIFF kimgio code Qt already has a TIFF imageformat plugin, so there is no need to resurrect this. Diffs - tier1/kguiaddons/src/plugins/imageformats/g3r.h 5d43d6fd90bcd54cba71c775e6c7536c6f42ac30 tier1/kguiaddons/src/plugins/imageformats/g3r.cpp 1e32e1607d750912119c7d76c6e3cfcbd72491de Diff: http://git.reviewboard.kde.org/r/113705/diff/ Testing --- Compiles. 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 113731: Fix kdesu standalone build.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113731/#review43344 --- Ship it! Ship It! - David Faure On Nov. 9, 2013, 11:18 a.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113731/ --- (Updated Nov. 9, 2013, 11:18 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kdesu build standalone. Diffs - tier3/kdesu/src/CMakeLists.txt 89b53e1e28c11f777b5433a97fbef14d6c5876a5 tier3/kdesu/CMakeLists.txt 9ac26ea1fc4ed83b62caa68f7d6ade3ae85ce3fe superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 Diff: http://git.reviewboard.kde.org/r/113731/diff/ Testing --- builds :) Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: the kspeech interface
On Saturday 09 November 2013 11:47:16 David Faure wrote: On Friday 08 November 2013 22:45:33 Jeremy Whiting wrote: Could we move the dbus interface into kdeaccessibility/jovie and install it only when jovie is installed, This would create a compile-time dependency on kdeaccessibility, in all the apps that use that dbus interface. I think this circles back to kdbusaddons, but I'll give time to e.g. Kévin to give his input. Not the scope of KDBusAddons IMO. I'd say it's about integrating with our workspace services, so I'd lean more toward a tier 4 framework. We don't have a place for this kind of things yet... We could open a section in framework integration for that. 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: kdesrc-build build failures
On Saturday 09 November 2013 15:18:36 Ivan Čukić wrote: On Friday 08 November 2013 18:04:08 Stefanie Dargel wrote: kde-workspace fails, because it requires QImageBlitz, which is not being compiled. I didn't manage to add the Subversion repo to kf5-qt5-build-include. Ho can I do it? You can install the regular qimageblitz development package. It should do the trick. It's a bad idea, as doing that will pull qt development package too which might not desirable for some setups. Definitely something I wouldn't want. Why do we still refer to this dependency in the first place? I'd expect that to be unused by now. 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: kdelibs/interfaces/khexedit
On Sunday 10 November 2013 11:15:58 Dominik Haumann wrote: On Sunday 10 November 2013 09:47:41 David Faure wrote: On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote: So from my point of view, especially given the idea of KF5, I see no more need for interfaces/khexedit. Rather do I see the Okteta libs themselves (the core ones for simple widget things) one day being added to KF5, now that things are modular :) Yep, makes sense. I'll just delete interfaces/khexedit then, thanks for the input. Btw, this is basically the same solution as we take with KTextEditor: The KTextEditor interfaces are not part of some other module anymore. Instead they are directly shipped with Kate Part for KF5. This makes sense for the simple reason that there is no other KTextEditor implementation than Kate Part (for 10 years now). From this perspective. The same basically holds for Okteta imo: If you need a hex editor component, just state that as dependency at compile time and all is fine. So as I see it, removing interfaces/khexedit is the right way to go :-) Actually that's probably the way to go for the other interfaces too... Like the kspeech one. 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: Review Request 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
On Nov. 10, 2013, 9:50 a.m., David Faure wrote: tier4/kde4support/src/CMakeLists.txt, line 293 http://git.reviewboard.kde.org/r/113670/diff/3/?file=212165#file212165line293 Why was this line removed? Everything else looks fine to me, this remove seems unrelated though. I moved it into the if(X11_FOUND) block. Probably doesn't make any difference since it will be empty if X11 is not found. But I think it is nicer that way. - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/#review43321 --- On Nov. 8, 2013, 10:04 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 8, 2013, 10:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Sunday 10 November 2013, David Faure wrote: On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote: To build karchive itself, they would need cmake + tier0-kf5 + ECM Which is exactly what I want to avoid. You wrote To build software using karchive with cmake, they still need only cmake. but this requires karchive to be installed first. On a linux distro, no problem. But on Windows, they will have to build karchive themselves (unless we make binary packages, which I heavily doubt we will do). So the problem is real. I do NOT want to have to tell people install 3 build- system components before you can even build this very simple library. I guess the 3 buildsystem components would be cmake, ecm and tier0 ? I understand that this sounds like a lot when starting from scratch. As I said in some other thread, I was hoping that ecm would become so common, especially since I wanted it to be not bound to KDE, that it would anyway already be on the machine of a developer who uses cmake. This would leave only the tier0 package to be installed for the average developer using cmake. There are two things I find a bit surprising here. In KF5 we go great lengths to split the C++ libraries quite fine granular, not only based on different dependencies, but also on their purpose. For cmake libraries this correctness is apparently not a valid argument for splitting. OTOH, splitting the cmake library into two is considered bad because requiring the developer to install one more package is bad, but in C++ we'll have a lot of separate frameworks, and somebody wanting to build a tier3 framework will be required to install a whole bunch of packages, and this is not seen as a problem (it's actually the point of the splitting). But it's ok. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Sunday 10 November 2013, Alexander Neundorf wrote: On Sunday 10 November 2013, David Faure wrote: On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote: To build karchive itself, they would need cmake + tier0-kf5 + ECM Which is exactly what I want to avoid. You wrote To build software using karchive with cmake, they still need only cmake. but this requires karchive to be installed first. On a linux distro, no problem. But on Windows, they will have to build karchive themselves (unless we make binary packages, which I heavily doubt we will do). So the problem is real. I do NOT want to have to tell people install 3 build- system components before you can even build this very simple library. I guess the 3 buildsystem components would be cmake, ecm and tier0 ? I understand that this sounds like a lot when starting from scratch. As I said in some other thread, I was hoping that ecm would become so common, especially since I wanted it to be not bound to KDE, that it would anyway already be on the machine of a developer who uses cmake. This would leave only the tier0 package to be installed for the average developer using cmake. and, as Kevin suggested, maybe ecm could be integrated via git submodules into this tier0 package, so for the user it would be only one thing. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote: On Sunday 10 November 2013, Alexander Neundorf wrote: On Sunday 10 November 2013, David Faure wrote: On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote: To build karchive itself, they would need cmake + tier0-kf5 + ECM Which is exactly what I want to avoid. You wrote To build software using karchive with cmake, they still need only cmake. but this requires karchive to be installed first. On a linux distro, no problem. But on Windows, they will have to build karchive themselves (unless we make binary packages, which I heavily doubt we will do). So the problem is real. I do NOT want to have to tell people install 3 build- system components before you can even build this very simple library. I guess the 3 buildsystem components would be cmake, ecm and tier0 ? I understand that this sounds like a lot when starting from scratch. As I said in some other thread, I was hoping that ecm would become so common, especially since I wanted it to be not bound to KDE, that it would anyway already be on the machine of a developer who uses cmake. This would leave only the tier0 package to be installed for the average developer using cmake. and, as Kevin suggested, maybe ecm could be integrated via git submodules into this tier0 package, so for the user it would be only one thing. Actually I was more thinking about injecting this tier0 into each of the frameworks using a git submodule, so that ecm could be a regular dependency as originally planned... Now I guess we could do it for both, but it looks tricky for something which would have a separate release cycle like ECM. While for the tier0 the release cycle would be tied to the rest. 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 112880: Added KColorSchemeToken class.
On Oct. 21, 2013, 11:22 a.m., Kevin Ottens wrote: To get in this patch would benefit from being based on the frameworks branch and go into kdeclarative. Any chance for an update? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review42069 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Stephen Kelly wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. Chusslove Illich wrote: Right, a preprocessor macro. And I meant setting it by implementing the -define option in uic, rather than the more specific -domain. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui with explicit -tr option (and -include unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then ki18n_qt5_wrap_ui is not needed indeed. Stephen Kelly wrote: But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui That would also not be needed. The required options to uic would be used simply by linking to KI18n. Chusslove Illich wrote: So, one must be able to set two things. Add the TRANSLATION_DOMAIN macro; this can be done by add_definitions. Choose whether -tr tr2i18n or -tr tr2xi18n is issued to uic; how can this be done? Stephen Kelly wrote: I think there's no need for the add_definitions. We would add something like this to ki18n: set_property(TARGET KI18n PROPERTY INTERFACE_AUTOUIC_OPTIONS -include klocalizedstring -tr tr2i18n -define TRANSLATION_DOMAIN=$TARGET_PROPERTY:NAME) Additionally, if the TRANSLATION_DOMAIN is needed in c++ code that I write as a developer, we should this to ki18n:
Re: Review Request 113631: Allow compiling kwindowsystem on Windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113631/ --- (Updated Nov. 10, 2013, 3:46 p.m.) Review request for KDE Frameworks, Patrick Spendrin and Patrick von Reth. Changes --- Adding the Gang of the Patricks to this review, let's hope they'll pay attention and help us. :-) Repository: kdelibs Description --- Allow compiling kwindowsystem on Windows Diffs - tier1/CMakeLists.txt 277b3f0 tier1/kwindowsystem/CMakeLists.txt dc8fcae tier1/kwindowsystem/src/CMakeLists.txt d9d141e tier1/kwindowsystem/src/kkeyserver_win.h 6328f41 tier1/kwindowsystem/src/kstartupinfo.h 39c2935 tier1/kwindowsystem/src/kstartupinfo.cpp 402cc97 tier1/kwindowsystem/src/kwindowinfo_win.cpp d392fe9 tier1/kwindowsystem/src/kwindowsystem.h 0c6a930 tier1/kwindowsystem/src/kwindowsystem_win.cpp 23a6616 Diff: http://git.reviewboard.kde.org/r/113631/diff/ Testing --- Compiles (Windows 7, VS 2012 x64) 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 113657: Fix Standalone Configuration of DNSSD
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/#review43351 --- Ship it! I think that's fine to keep the modules private, they're not used anywhere else AFAIK. We use kdnssd instead of avahi or such directly. If we find more users later on then we can put the effort to have them in ECM of course. - Kevin Ottens On Nov. 7, 2013, 1:30 p.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/ --- (Updated Nov. 7, 2013, 1:30 p.m.) Review request for KDE Frameworks, Kevin Ottens, Aurélien Gâteau, and Stephen Kelly. Repository: kdelibs Description --- Moved FindAvahi.cmake and FindDNSSD.cmake into KDNSSD, fixed details when building with DNSSD and factored out the Frameworks version. Diffs - cmake/modules/CMakeLists.txt 7910270 cmake/modules/FindAvahi.cmake cmake/modules/FindDNSSD.cmake 8604bd5 tier2/dnssd/CMakeLists.txt 2cfcc40 Diff: http://git.reviewboard.kde.org/r/113657/diff/ Testing --- 1. Configure with cmake 2. Configure with cmake and -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 Configures OK in both cases. Builds OK in case 1, does not build yet in case 2. 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 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43353 --- Please someone with more cmake-fu than myself look at it. It's in fact important for the coming days to ease the transition to split repos. - Kevin Ottens On Nov. 7, 2013, 2:42 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 7, 2013, 2:42 p.m.) Review request for KDE Frameworks, Alexander Neundorf and Stephen Kelly. Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work 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 113731: Fix kdesu standalone build.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113731/ --- (Updated Nov. 10, 2013, 3:53 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Make kdesu build standalone. Diffs - tier3/kdesu/src/CMakeLists.txt 89b53e1e28c11f777b5433a97fbef14d6c5876a5 tier3/kdesu/CMakeLists.txt 9ac26ea1fc4ed83b62caa68f7d6ade3ae85ce3fe superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 Diff: http://git.reviewboard.kde.org/r/113731/diff/ Testing --- builds :) Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113730: Fix kpty standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113730/#review43354 --- This review has been submitted with commit d51d9cfba180345af4c0b5a23f81633122900042 by Maarten De Meyer to branch frameworks. - Commit Hook On Nov. 9, 2013, 10:54 a.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113730/ --- (Updated Nov. 9, 2013, 10:54 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kpty build standalone and with superbuild. I'm not sure if installing kprocess_p.h is the correct solution. Diffs - superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c56bea27fe26916bf5a7cbef612613578fd tier3/kpty/CMakeLists.txt f96ecabd729aea9f48e89ccc222517096487d780 tier3/kpty/src/ConfigureChecks.cmake a385e17276d8f9a3598f1434bd0da5e8b25f0218 tier3/kpty/tests/CMakeLists.txt f78e3fe105aae313dcb5eeb7524c12a8e8533bf0 Diff: http://git.reviewboard.kde.org/r/113730/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113730: Fix kpty standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113730/ --- (Updated Nov. 10, 2013, 3:53 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Make kpty build standalone and with superbuild. I'm not sure if installing kprocess_p.h is the correct solution. Diffs - superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 tier1/kcoreaddons/src/lib/CMakeLists.txt fad55c56bea27fe26916bf5a7cbef612613578fd tier3/kpty/CMakeLists.txt f96ecabd729aea9f48e89ccc222517096487d780 tier3/kpty/src/ConfigureChecks.cmake a385e17276d8f9a3598f1434bd0da5e8b25f0218 tier3/kpty/tests/CMakeLists.txt f78e3fe105aae313dcb5eeb7524c12a8e8533bf0 Diff: http://git.reviewboard.kde.org/r/113730/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113731: Fix kdesu standalone build.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113731/#review43355 --- This review has been submitted with commit f75df03e8af820f23a38c513e88c645970db5567 by Maarten De Meyer to branch frameworks. - Commit Hook On Nov. 9, 2013, 11:18 a.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113731/ --- (Updated Nov. 9, 2013, 11:18 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kdesu build standalone. Diffs - tier3/kdesu/src/CMakeLists.txt 89b53e1e28c11f777b5433a97fbef14d6c5876a5 tier3/kdesu/CMakeLists.txt 9ac26ea1fc4ed83b62caa68f7d6ade3ae85ce3fe superbuild/CMakeLists.txt 80de8667b338c91922f627eaf92073a9a51645d8 Diff: http://git.reviewboard.kde.org/r/113731/diff/ Testing --- builds :) Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113711: Clean up API of KPassivePopup
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113711/#review43357 --- Ship it! Ship It! - Kevin Ottens On Nov. 7, 2013, 6:57 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113711/ --- (Updated Nov. 7, 2013, 6:57 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KPassivePopup had a bunch of odd public API that no-one was using because it's useless to outside classes (even subclasses, of which there appear to be none). This hides that away, and makes the protected stuff actually useful. There are still some issues with the next to the taskbar positioning (it puts it alongside the entry instead of on the opposite side the screen edge), but that's less urgent than the API change. Clean up API of KPassivePopup Firstly, allow subclasses to more easily override the location: * remove defaultArea from the public API, as it is useless to clients * replace it with a virtual protected method defaultLocation Secondly, move other methods that should be private to the Private class. Thirdly, remove the Custom entry from the PopupStyle enum as there is, in practice, no easy way for subclasses to implement another style; by the time they do, they may as well start from scratch. Diffs - tier2/knotifications/src/kpassivepopup.h 4eb6ffc7b076391d3f74ce902cc964371b1046c8 tier2/knotifications/src/kpassivepopup.cpp f17086d3185e207b874f4dcfecf1da8715a3fd77 Diff: http://git.reviewboard.kde.org/r/113711/diff/ Testing --- Still builds, test app still puts the popups where expected. 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 113695: Fix KDEWebKit standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113695/#review43360 --- Ship it! Ship It! - Kevin Ottens On Nov. 7, 2013, 12:38 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113695/ --- (Updated Nov. 7, 2013, 12:38 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds missing dependencies, small other fixes. Diffs - superbuild/CMakeLists.txt 90688f6 tier3/kdewebkit/CMakeLists.txt b56e71d tier3/kdewebkit/src/CMakeLists.txt c48b7ed Diff: http://git.reviewboard.kde.org/r/113695/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113693: Fix KNotifyConfig standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113693/#review43361 --- Ship it! After adjusting the comment it can go in indeed. - Kevin Ottens On Nov. 7, 2013, 1:07 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113693/ --- (Updated Nov. 7, 2013, 1:07 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add the dependencies of dependencies. Small fixes. Diffs - superbuild/CMakeLists.txt 90688f6 tier3/knotifyconfig/CMakeLists.txt 8be2ceb tier3/knotifyconfig/tests/CMakeLists.txt 385ff70 Diff: http://git.reviewboard.kde.org/r/113693/diff/ Testing --- Builds, installs, the test seems to work. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113712: Add popup for window with SkipTaskbar set in kpassivepopuptest
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113712/#review43362 --- Ship it! Ship It! - Kevin Ottens On Nov. 8, 2013, 12:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113712/ --- (Updated Nov. 8, 2013, 12:12 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add popup for window with SkipTaskbar set in kpassivepopuptest KPassivePopup should place this next to the window itself. Diffs - tier2/knotifications/tests/kpassivepopuptest.cpp 266842aa336793248663a15e19d4ba22c32ee412 tier2/knotifications/tests/kpassivepopuptest.h c9620b975295be6d59b974824d1cb4e08c860f6f tier2/knotifications/tests/CMakeLists.txt ce87f1752856dcc0b37ef86fb3bfdbdaf4ef5685 tier2/knotifications/src/CMakeLists.txt cf312e028c323521504bd9ccd4c8f3f817e13497 tier2/knotifications/CMakeLists.txt 6df0022536436477cc9cd875e0bccd70e78d32d3 Diff: http://git.reviewboard.kde.org/r/113712/diff/ Testing --- Builds, runs, new test does the right thing. 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 113694: Fix KNewStuff standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113694/#review43363 --- Ship it! Ship It! - Kevin Ottens On Nov. 7, 2013, 1:04 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113694/ --- (Updated Nov. 7, 2013, 1:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adds dependencies to make sure KNewStuff can be compiled alone Diffs - superbuild/CMakeLists.txt 90688f6 tier3/knewstuff/CMakeLists.txt f7f4dfa Diff: http://git.reviewboard.kde.org/r/113694/diff/ Testing --- Builds and installs. All tests are commented out. 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 113696: Rename knewstuff private headers to _p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113696/#review43364 --- Ship it! Ship It! - Kevin Ottens On Nov. 6, 2013, 7:17 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113696/ --- (Updated Nov. 6, 2013, 7:17 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Renamed knewstuff private headers to _p.h and adjusted #include's accordingly. Diffs - tier3/knewstuff/src/attica/atticaprovider.h 38aacfa377c91c54951eec9923f9b1712a0f4e32 tier3/knewstuff/src/attica/atticaprovider.cpp b077b23a3decb644b6ab5d15dc1283dfcd0e05b2 tier3/knewstuff/src/core/author.h tier3/knewstuff/src/core/author.cpp 12cde54d806fdf674fb413d59a586db831de082d tier3/knewstuff/src/core/cache.h 03373377cb91df9d5448e6231b008bd7949a8364 tier3/knewstuff/src/core/cache.cpp 66e3ed13c690437cbbb3a43a518e22b5d5240581 tier3/knewstuff/src/core/engine.h 7f0bc3021ef21b1621bff51fcb76e0579452f6e7 tier3/knewstuff/src/core/engine.cpp 941b1d0753320f57641c868f94959d9bf93148f7 tier3/knewstuff/src/core/entryinternal.h 08f6dcf02e0a765a80a0df24375381e1d6fdf909 tier3/knewstuff/src/core/entryinternal.cpp 2eb592d771dbc3f5ec1e38b7c7d0231b49736543 tier3/knewstuff/src/core/installation.h aec5e71d449a3e13108e636553a721b56a1af08f tier3/knewstuff/src/core/installation.cpp 7ec710ac80ae2011e9d975aa5d00763b04b084bd tier3/knewstuff/src/core/provider.h 0e3f7bc6efd3d205442c70d79035984848a1b7c8 tier3/knewstuff/src/core/provider.cpp 294d8665971e8547abfccd47785f655a85d8796b tier3/knewstuff/src/core/security.h tier3/knewstuff/src/core/security.cpp eec03c39d3f1b5296ddd81525f4868359b46497c tier3/knewstuff/src/core/upload.h tier3/knewstuff/src/core/upload.cpp ef62cf10ad1d580df8b894ac70044ad9a286b827 tier3/knewstuff/src/core/xmlloader.h tier3/knewstuff/src/core/xmlloader.cpp 65b6de95c4902adb1beb2761dec54d7526036b2b tier3/knewstuff/src/downloadmanager.cpp df06786b0cf136c2f7f52e85cbeb7a61835acad6 tier3/knewstuff/src/downloadwidget.cpp 1d56e1106fb3ce1aa3f4a7f3b07a68732101b3ce tier3/knewstuff/src/downloadwidget.ui 17f2944e81c0510eb7ae85128e79e815eab1bf54 tier3/knewstuff/src/downloadwidget_p.h 080e1779e0d2ed110da28cc087218262fad1f333 tier3/knewstuff/src/entry_p.h 73c1ee8619b171f90706ba3ed323abbd00add455 tier3/knewstuff/src/staticxml/staticxmlprovider.h 52caed08f53d125928d12f329c96800530d9fcaa tier3/knewstuff/src/staticxml/staticxmlprovider.cpp e7dd0686f122c938cf87959478acc97a0a25723b tier3/knewstuff/src/ui/entrydetailsdialog.h 0add71dfecd4f0cb8653e9a90568bad5d9d2e008 tier3/knewstuff/src/ui/entrydetailsdialog.cpp 5a451086531c53af720a2874f5c3b5ed51d07423 tier3/knewstuff/src/ui/imageloader.h 5e87a7b7890b6678c4b94aacc1b2f84d001b7dd0 tier3/knewstuff/src/ui/imageloader.cpp 8e6ed061e421e985535228599ff9da17303bae46 tier3/knewstuff/src/ui/imagepreviewwidget.h tier3/knewstuff/src/ui/imagepreviewwidget.cpp d9d20775a9686715176ead2f24f122d82b88987b tier3/knewstuff/src/ui/itemsgridviewdelegate.h a5d793d8c859c25639921cc9a05233cb9879377e tier3/knewstuff/src/ui/itemsgridviewdelegate.cpp 3970287927e8c17acc9347adbae4c342c78d389a tier3/knewstuff/src/ui/itemsmodel.h 7bc691483b3f0a27dc0d35a7fa6a4ad877294c1a tier3/knewstuff/src/ui/itemsmodel.cpp d972c53f2963dba4ed55bfb484005b77b056c323 tier3/knewstuff/src/ui/itemsview.h tier3/knewstuff/src/ui/itemsview.cpp b200b651bf1c57b37c7d8cb8163246488e6b17fb tier3/knewstuff/src/ui/itemsviewbasedelegate.h bbb08dbc1755b9d9c5bde20c27e7bf368c149c29 tier3/knewstuff/src/ui/itemsviewbasedelegate.cpp 89e91f9563f95985759388dcfca76d480a9dedba tier3/knewstuff/src/ui/itemsviewdelegate.h 1df97a36fc72d9eb3b2d07c5edff0170db459ea5 tier3/knewstuff/src/ui/itemsviewdelegate.cpp 5289ee0093e7e4d02e6250bad8807f7c7e0d04c7 tier3/knewstuff/src/ui/progressindicator.h tier3/knewstuff/src/ui/progressindicator.cpp ab06ff19c103c4d809d9ef4b14586bcd936e75c5 tier3/knewstuff/src/upload/atticahelper.h tier3/knewstuff/src/upload/atticahelper.cpp c17b743c29943fbd25020dc9c8b7a0862cdc2458 tier3/knewstuff/src/uploaddialog_p.h 084d626c095465b5176aa928fed1d6d6342e6e2d Diff: http://git.reviewboard.kde.org/r/113696/diff/ Testing --- It still builds. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113708: Make kcmutils build standalone
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113708/#review43365 --- Ship it! Ship It! - Kevin Ottens On Nov. 7, 2013, 3:36 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113708/ --- (Updated Nov. 7, 2013, 3:36 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Make kcmutils build standalone. I'll add it to superbuild when commiting. Diffs - tier4/kcmutils/CMakeLists.txt ef65009 tier4/kcmutils/src/CMakeLists.txt daeb662 Diff: http://git.reviewboard.kde.org/r/113708/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/#review43366 --- Ship it! Ship It! - Kevin Ottens On Nov. 8, 2013, 9:04 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 8, 2013, 9:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Sunday 10 November 2013, Kevin Ottens wrote: On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote: On Sunday 10 November 2013, Alexander Neundorf wrote: On Sunday 10 November 2013, David Faure wrote: On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote: To build karchive itself, they would need cmake + tier0-kf5 + ECM Which is exactly what I want to avoid. You wrote To build software using karchive with cmake, they still need only cmake. but this requires karchive to be installed first. On a linux distro, no problem. But on Windows, they will have to build karchive themselves (unless we make binary packages, which I heavily doubt we will do). So the problem is real. I do NOT want to have to tell people install 3 build- system components before you can even build this very simple library. I guess the 3 buildsystem components would be cmake, ecm and tier0 ? I understand that this sounds like a lot when starting from scratch. As I said in some other thread, I was hoping that ecm would become so common, especially since I wanted it to be not bound to KDE, that it would anyway already be on the machine of a developer who uses cmake. This would leave only the tier0 package to be installed for the average developer using cmake. and, as Kevin suggested, maybe ecm could be integrated via git submodules into this tier0 package, so for the user it would be only one thing. Actually I was more thinking about injecting this tier0 into each of the frameworks using a git submodule, so that ecm could be a regular dependency as originally planned... yes, there are several ways how this could be done. Now I guess we could do it for both, but it looks tricky for something which would have a separate release cycle like ECM. While for the tier0 the release cycle would be tied to the rest. Personally I would have said that either this tier0 or all of KF5 should require some specific, released version of ECM, so that this version could be pulled from a branch (if this is where you see the problem). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders in
header files.
I think there's an aspect missing in your proposal. There's the convention we
want for #include and where we install. That's in the end two different things
even though related.
I think, that for all the frameworks, headers should be installed in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and the
convenience camel case ones. If we go for that, we get something consistent
install wise and easy to deal with. Then the distinction you make below is
just about the include path we want when someone pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then headers
should be installed in include and convenience headers should be
installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when someone
pulls the framework as a dependency then both $PREFIX/include/KF5/ and
$PREFIX/include/KF5/FrameworkName/ are added in the include path, thus
supporting the #include kfoo.h and #include KFoo styles.
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they should be
installed in include/{lowercaseframework} and convenience headers should
be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when someone
pulls the framework as a dependency then only $PREFIX/include/KF5/ is added in
the include path, thus supporting the #include FrameworkName/foo.h and
#include FrameworkName/Foo styles.
Some special files should still go in include:
{lowercaseframework}_export.h
{lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
I think it departs quite a bit from your initial proposal, making it slightly
more complicated on the include path side, but it has pros like:
* making it more homogeneous on the installation side;
* allows co-installability of major releases in the future.
Opinions?
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
Having a Tier 0 for cmake and git submodules
Hello, Since there's been several times discussions about having a kind of Tier 0 for building our frameworks containing what is right now in ECM kde-modules directory, but the idea was never really on the table because of the extra dependency it'd bring, I looked a bit at the git submodule option to get there. The motivation for going with a git submodule is that it would allow such a Tier 0 to be completely transparent to third parties who would want to grab a Tier 1 framework and not bother about installing anything else than our main dependencies (namely Qt, CMake and ECM). Again: If we force third parties to install another KDE specific dependency to build a Tier 1 framework from sources we failed. So after playing a bit with several solutions (I looked at git subtree too for instance), I still think that git submodule is the solution to use if we got for such a Tier 0... it's not perfect though. Indeed, submodules keep the information of the exact sha-1 used, there's no way to have them track a branch automatically. That's likely to turn into a problem (not for third parties this time but for our own developers) as from the master branch of a framework we probably always want the tipping point of the master branch of the repository containing the cmake files. Also git archive ignores submodules when generating the archive... But that's easy to fix and there's a git archive-all script available which does the recursive export. Now back to the submodules sha-1 update... The only thing I see to easily overcome that for our developers, is to have a hook, which would update the submodules for all the frameworks every time someone pushes in the tier 0 repository. Is it something the sysadmins would agree to have on the server? Any opinions or thoughts on that? If we agree on the approach I think we have a potential solution for injecting a tier 0 in all our frameworks that could be put into place when we start splitting the repositories. 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: Getting ecm files from the ECM package
On Sunday 10 November 2013 17:30:23 Alexander Neundorf wrote: On Sunday 10 November 2013, Kevin Ottens wrote: Now I guess we could do it for both, but it looks tricky for something which would have a separate release cycle like ECM. While for the tier0 the release cycle would be tied to the rest. Personally I would have said that either this tier0 or all of KF5 should require some specific, released version of ECM, so that this version could be pulled from a branch (if this is where you see the problem). The problem is in fact in the ways git submodule works (see my other email). Summary: a particular tag we could get it to work, a branch is trickier... 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: Having a Tier 0 for cmake and git submodules
On 2013-11-10, Kevin Ottens er...@kde.org wrote: Since there's been several times discussions about having a kind of Ti= er 0=20 for building our frameworks containing what is right now in ECM kde-mod= ules=20 directory, but the idea was never really on the table because of the ex= tra=20 dependency it'd bring, I looked a bit at the git submodule option to ge= t=20 there. Why move it out of e-c-m ? Also git archive ignores submodules when generating the archive... But = that's=20 easy to fix and there's a git archive-all script available which does t= he=20 recursive export. And if a distribution need to patch whatever is in the 'submodule', they have a enormous useless piece of work ahead for them. No. Let us not do that. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113711: Clean up API of KPassivePopup
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113711/#review43370 --- This review has been submitted with commit f33e6dea79e3edcdd59c688c4d6f69d1c93a6cb1 by Alex Merry to branch frameworks. - Commit Hook On Nov. 7, 2013, 6:57 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113711/ --- (Updated Nov. 7, 2013, 6:57 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KPassivePopup had a bunch of odd public API that no-one was using because it's useless to outside classes (even subclasses, of which there appear to be none). This hides that away, and makes the protected stuff actually useful. There are still some issues with the next to the taskbar positioning (it puts it alongside the entry instead of on the opposite side the screen edge), but that's less urgent than the API change. Clean up API of KPassivePopup Firstly, allow subclasses to more easily override the location: * remove defaultArea from the public API, as it is useless to clients * replace it with a virtual protected method defaultLocation Secondly, move other methods that should be private to the Private class. Thirdly, remove the Custom entry from the PopupStyle enum as there is, in practice, no easy way for subclasses to implement another style; by the time they do, they may as well start from scratch. Diffs - tier2/knotifications/src/kpassivepopup.h 4eb6ffc7b076391d3f74ce902cc964371b1046c8 tier2/knotifications/src/kpassivepopup.cpp f17086d3185e207b874f4dcfecf1da8715a3fd77 Diff: http://git.reviewboard.kde.org/r/113711/diff/ Testing --- Still builds, test app still puts the popups where expected. 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 113711: Clean up API of KPassivePopup
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113711/ --- (Updated Nov. 10, 2013, 5:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- KPassivePopup had a bunch of odd public API that no-one was using because it's useless to outside classes (even subclasses, of which there appear to be none). This hides that away, and makes the protected stuff actually useful. There are still some issues with the next to the taskbar positioning (it puts it alongside the entry instead of on the opposite side the screen edge), but that's less urgent than the API change. Clean up API of KPassivePopup Firstly, allow subclasses to more easily override the location: * remove defaultArea from the public API, as it is useless to clients * replace it with a virtual protected method defaultLocation Secondly, move other methods that should be private to the Private class. Thirdly, remove the Custom entry from the PopupStyle enum as there is, in practice, no easy way for subclasses to implement another style; by the time they do, they may as well start from scratch. Diffs - tier2/knotifications/src/kpassivepopup.h 4eb6ffc7b076391d3f74ce902cc964371b1046c8 tier2/knotifications/src/kpassivepopup.cpp f17086d3185e207b874f4dcfecf1da8715a3fd77 Diff: http://git.reviewboard.kde.org/r/113711/diff/ Testing --- Still builds, test app still puts the popups where expected. 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 113713: Solid UDisks2 backend: fixes to propertiesChanged signal handling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113713/#review43371 --- This review has been submitted with commit ece826d3495c82cdd6b0a6d8d45440c359b250c8 by Alex Merry to branch frameworks. - Commit Hook On Nov. 7, 2013, 7:08 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113713/ --- (Updated Nov. 7, 2013, 7:08 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Just a couple of potential issues I noticed while investigating warnings... UDisks2 backend: Ignore propertiesChanged signal for generic interfaces We only store properties for UDisks2-specific interfaces, so we should only listen to updates to properties on those interfaces. Invalidate properties on D-Bus are *modified* ones, not removed ones The UDisks2 backend was claiming that properties that were invalidated were removed; this is not true. While they should be removed from the cache, the properties themselves have not gone away. Diffs - tier1/solid/src/solid/backends/udisks2/udisksdevicebackend.cpp 32aa53fe5a7d8b29cd644f46b3d906bd64d16b69 Diff: http://git.reviewboard.kde.org/r/113713/diff/ Testing --- Builds, tests run. 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 113713: Solid UDisks2 backend: fixes to propertiesChanged signal handling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113713/#review43373 --- This review has been submitted with commit f5c87f8fc93df462551a8702f372095935a25770 by Alex Merry to branch frameworks. - Commit Hook On Nov. 7, 2013, 7:08 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113713/ --- (Updated Nov. 7, 2013, 7:08 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Just a couple of potential issues I noticed while investigating warnings... UDisks2 backend: Ignore propertiesChanged signal for generic interfaces We only store properties for UDisks2-specific interfaces, so we should only listen to updates to properties on those interfaces. Invalidate properties on D-Bus are *modified* ones, not removed ones The UDisks2 backend was claiming that properties that were invalidated were removed; this is not true. While they should be removed from the cache, the properties themselves have not gone away. Diffs - tier1/solid/src/solid/backends/udisks2/udisksdevicebackend.cpp 32aa53fe5a7d8b29cd644f46b3d906bd64d16b69 Diff: http://git.reviewboard.kde.org/r/113713/diff/ Testing --- Builds, tests run. 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 113712: Add popup for window with SkipTaskbar set in kpassivepopuptest
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113712/#review43372 --- This review has been submitted with commit 7ce144ac99c3f8024314162d2fa2cd428c7328a9 by Alex Merry to branch frameworks. - Commit Hook On Nov. 8, 2013, 12:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113712/ --- (Updated Nov. 8, 2013, 12:12 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Add popup for window with SkipTaskbar set in kpassivepopuptest KPassivePopup should place this next to the window itself. Diffs - tier2/knotifications/tests/kpassivepopuptest.cpp 266842aa336793248663a15e19d4ba22c32ee412 tier2/knotifications/tests/kpassivepopuptest.h c9620b975295be6d59b974824d1cb4e08c860f6f tier2/knotifications/tests/CMakeLists.txt ce87f1752856dcc0b37ef86fb3bfdbdaf4ef5685 tier2/knotifications/src/CMakeLists.txt cf312e028c323521504bd9ccd4c8f3f817e13497 tier2/knotifications/CMakeLists.txt 6df0022536436477cc9cd875e0bccd70e78d32d3 Diff: http://git.reviewboard.kde.org/r/113712/diff/ Testing --- Builds, runs, new test does the right thing. 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 113713: Solid UDisks2 backend: fixes to propertiesChanged signal handling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113713/ --- (Updated Nov. 10, 2013, 5:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Just a couple of potential issues I noticed while investigating warnings... UDisks2 backend: Ignore propertiesChanged signal for generic interfaces We only store properties for UDisks2-specific interfaces, so we should only listen to updates to properties on those interfaces. Invalidate properties on D-Bus are *modified* ones, not removed ones The UDisks2 backend was claiming that properties that were invalidated were removed; this is not true. While they should be removed from the cache, the properties themselves have not gone away. Diffs - tier1/solid/src/solid/backends/udisks2/udisksdevicebackend.cpp 32aa53fe5a7d8b29cd644f46b3d906bd64d16b69 Diff: http://git.reviewboard.kde.org/r/113713/diff/ Testing --- Builds, tests run. 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 113712: Add popup for window with SkipTaskbar set in kpassivepopuptest
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113712/ --- (Updated Nov. 10, 2013, 5:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Add popup for window with SkipTaskbar set in kpassivepopuptest KPassivePopup should place this next to the window itself. Diffs - tier2/knotifications/tests/kpassivepopuptest.cpp 266842aa336793248663a15e19d4ba22c32ee412 tier2/knotifications/tests/kpassivepopuptest.h c9620b975295be6d59b974824d1cb4e08c860f6f tier2/knotifications/tests/CMakeLists.txt ce87f1752856dcc0b37ef86fb3bfdbdaf4ef5685 tier2/knotifications/src/CMakeLists.txt cf312e028c323521504bd9ccd4c8f3f817e13497 tier2/knotifications/CMakeLists.txt 6df0022536436477cc9cd875e0bccd70e78d32d3 Diff: http://git.reviewboard.kde.org/r/113712/diff/ Testing --- Builds, runs, new test does the right thing. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 17:12:02 Sune Vuorela wrote: Why move it out of e-c-m ? To make e-c-m a neutral ground again, not something purely for KDE needs. I can understand that positioning. And if a distribution need to patch whatever is in the 'submodule', they have a enormous useless piece of work ahead for them. Well, to me it looks like something very easy to automate. It'd be the exact same files at the exact same place in each of the frameworks. Nothing you couldn't solve using a for loop in your shell. :-) 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 112880: Added KColorSchemeToken class.
On Oct. 21, 2013, 11:22 a.m., Kevin Ottens wrote: To get in this patch would benefit from being based on the frameworks branch and go into kdeclarative. Kevin Ottens wrote: Any chance for an update? Yes I will finish it, when have time. There are many pre-exams in university. - Denis --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review42069 --- On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Oct. 6, 2013, 7:24 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * Diffs - kdeui/CMakeLists.txt b439e04 includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote: Now back to the submodules sha-1 update... The only thing I see to easily overcome that for our developers, is to have a hook, which would update the submodules for all the frameworks every time someone pushes in the tier 0 repository. Is it something the sysadmins would agree to have on the server? Any opinions or thoughts on that? I'm very much reminded of kde-common/admin which was an external in all kde modules in kde3 times. Which is both good and bad :-) Good = same way to avoid a dependency just for the buildsystem, bad = makes a few actions as a developer more complex, like as you mentionned, having to update sha1s manually, in the case of git. Actually, I just realized that the same solution (to the same problem) is used in KDSoap (https://github.com/KDAB/KDSoap.git) with its autogen subdir which is a git submodule (to share it with other similar libs). It's actually working OK, the only downside is indeed the need to update it manually when committing a fix to a buildsystem file. Where git submodules is better than svn externals is that this won't slow down updating one's checkout (a separate command is needed for updating the submodule locally). But forgetting to do so isn't a risk, since git status (and the commented out list in git commit, etc.) reminds you to do so. If we're really just talking about the 3 cmake files for KDE, updates won't actually happen very often. OK, let's go for it. Let us NOT call it tier0 though :-) Note that we still need to ship them as a standalone package too, for people who might want to use them - KDE apps outside of git, or Qt apps that want to benefit from the rpath stuff that's currently only in there [although that's a bug IMHO], etc. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Changes --- Fix things raised by David. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs (updated) - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
On Nov. 10, 2013, 11:20 a.m., David Faure wrote: tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 300 http://git.reviewboard.kde.org/r/113704/diff/1/?file=211396#file211396line300 isn't there a better method to call than pid()? You're right; I missed the state() method last time I read through the QProcess API. On Nov. 10, 2013, 11:20 a.m., David Faure wrote: tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 216 http://git.reviewboard.kde.org/r/113704/diff/1/?file=211396#file211396line216 This could be improved to avoid loading the whole image in memory, given that QImageReader can read incrementally from a QIODevice. (but I won't block this commit for that, it was there before ;) Now reads in 4K blocks. On Nov. 10, 2013, 11:20 a.m., David Faure wrote: tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 53 http://git.reviewboard.kde.org/r/113704/diff/1/?file=211396#file211396line53 Prefer constructor-syntax over C casts. i.e. qint64(value) rather than (qint64)(value). C casts (in general, not in this particular instance) can lead to a lot of trouble, I like code to compile with -Wold-style-cast. Can't do it for the unsigned things, but I've changed it for the others. - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43334 --- On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On 2013-11-10, Kevin Ottens er...@kde.org wrote: --===3596639883239406900== Content-Type: multipart/signed; boundary=nextPart1424144.VkBYIHTjbs; micalg=pgp-sha1; protocol=application/pgp-signature --nextPart1424144.VkBYIHTjbs Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sunday 10 November 2013 17:12:02 Sune Vuorela wrote: Why move it out of e-c-m ? To make e-c-m a neutral ground again, not something purely for KDE need= s. I=20 can understand that positioning. Let's just rename most of them to make them not look like kde specifics. Except kdeinstalldirs. But well. cmake has gnuinstalldirs and similar, so that could kind of be okay to have. Then there is the extremely dangerous KDECompilerSettings that should be renamed to LOLPleaseAddSurprisesIntoTheCMakeSetup. srsly. I added a KDE Framework to my application and suddenly -DCMAKE_BUILD_TYPE=Debug is building with -O2. The other bits of the file seems to be filled with Is this still needed? Does this work? Should we consider sending it to the eternal bitfields? that leaves KDECMakeSettings which kind of could be renamed to 'PleaseUseSane2013Defaults' and thus no longer be KDE specific. We could then extend it in a couple of years if we need new changed sane defaults for 2015. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43380 --- Ship it! One more thing, but if this isn't possible, then ship it. tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31238 My suggestion was simply QImageReader ppmReader(io, ppm), to let it read directly from the QProcess iodevice. Then there's no need to write your own loop. Would that not work? (I'm not sure what happens if we have to wait for more data to be available, maybe QImageReader isn't ready for that) - David Faure On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013, David Faure wrote: On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote: Now back to the submodules sha-1 update... The only thing I see to easily overcome that for our developers, is to have a hook, which would update the submodules for all the frameworks every time someone pushes in the tier 0 repository. Is it something the sysadmins would agree to have on the server? Any opinions or thoughts on that? I'm very much reminded of kde-common/admin which was an external in all kde modules in kde3 times. Which is both good and bad :-) Good = same way to avoid a dependency just for the buildsystem, bad = makes a few actions as a developer more complex, like as you mentionned, having to update sha1s manually, in the case of git. Actually, I just realized that the same solution (to the same problem) is used in KDSoap (https://github.com/KDAB/KDSoap.git) with its autogen subdir which is a git submodule (to share it with other similar libs). It's actually working OK, the only downside is indeed the need to update it manually when committing a fix to a buildsystem file. Where git submodules is better than svn externals is that this won't slow down updating one's checkout (a separate command is needed for updating the submodule locally). But forgetting to do so isn't a risk, since git status (and the commented out list in git commit, etc.) reminds you to do so. If we're really just talking about the 3 cmake files for KDE, updates won't actually happen very often. OK, let's go for it. Let us NOT call it tier0 though :-) Note that we still need to ship them as a standalone package too, for people who might want to use them - KDE apps outside of git, or Qt apps that want to benefit from the rpath stuff that's currently only in there [although that's a bug IMHO], etc. just to make sure I understand correctly: this would mean that the 3 KDE* files from ecm plus the KF5 umbrella Config.cmake file would be used within KF5 as a git submodule. Users of KF5 can get access to it via using the installed KF5 umbrella package, or not if they don't want to. Is this the plan ? If so, can we then release ECM soon, with some cleanups ? This would also mean no more quick fixes/temporary hacks in ECM. And we should definitely get Stephens opinion on that. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113704: Fix EPS plugin
On Nov. 10, 2013, 6:39 p.m., David Faure wrote: tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 246 http://git.reviewboard.kde.org/r/113704/diff/2/?file=212428#file212428line246 My suggestion was simply QImageReader ppmReader(io, ppm), to let it read directly from the QProcess iodevice. Then there's no need to write your own loop. Would that not work? (I'm not sure what happens if we have to wait for more data to be available, maybe QImageReader isn't ready for that) Well, as it's set up, we feed the io device we're given (in EPS format) to gs via its stdin, and let it write to a file. Then we let QImageReader read the file (in PPM format). The buffer is used to do that first transfer, which doesn't involved QImageReader directly. Alternatively, we could write the io device contents (in EPS format) to a file, and pass the output (read) channel of the gs process to QImageReader, but I'm not sure that actually buys us anything. Avoiding the temporary file altogether sets us up for potential deadlocks. - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43380 --- On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 18:23:33 Sune Vuorela wrote: DCMAKE_BUILD_TYPE=Debug is building with -O2 Oh wow, I always thought this was cmake's doing, but you're right, it's not. This is an historical bit from the automake/unsermake times. We had debug (-O2 -g) and debugfull (no optimization, and -g3). So that's what we kept in kdelibs for kde4, and now it made it to ECM. But cmake already has both, just with different names! cmake has -O2 -g, it calls it RelWithDebInfo. And it almost has the last one, called Debug, it's just missing -g3 (== macro expansion in gdb, not a huge deal, could even be added to cmake I guess). So unless I'm missing something, let's just kill the KDE renaming, and use the upstream names for things. OK, in fact KDECompilerSettings makes a small difference between RelWithDebInfo and what it calls Debug: Debug also has -fno-reorder-blocks - fno-schedule-insns -fno-inline. So you simplified things a little bit when you said Debug is building with -O2 -- yes, but some optimizations are disabled, such as inlining which makes gdb usage a pain. So it's not a full O2. However I don't see a need for this, to be honest. RelWithDebInfo is fine for distros and for profiling, and for kde developers who don't expect to do a lot of step-by-step debugging in the apps they only use. cmake's Debug is the one to use when you expect to do that. So ECM's Debug with some optimizations but not all of them doesn't seem very useful. Note that KDECompilerSettings does set extra flags that we want, such as warnings (e.g. -Werror=return-type catches some nasty code sometimes). So that should stay, but it's build-type-unrelated and could be called ECMStricterCompilerFlags or something. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 19:42:46 Alexander Neundorf wrote: this would mean that the 3 KDE* files from ecm plus the KF5 umbrella Config.cmake file would be used within KF5 as a git submodule. Users of KF5 can get access to it via using the installed KF5 umbrella package, or not if they don't want to. This umbrella config thing isn't needed by the frameworks themselves, AFAICS. So it makes no sense to have them in a git submodule, i.e. copied into all frameworks. But I suppose it has to be installed somehow, so the current solution (a tier1, which can be avoided by using different cmake syntax, right?) is fine? Coming back to the 3 KDE* files: My preference #1 is Sune's suggestion: cleanup, de-kde-ify, keep what's left in ECM. My preference #2, if some stuff that we need really doesn't belong in ECM, is the git submodule. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43386 --- This review has been submitted with commit eecc95e4a8939924492369d39eb0e2ce658bd923 by Alex Merry to branch frameworks. - Commit Hook On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43385 --- This review has been submitted with commit b6873bb4c752e518b5da6125cdcf031b5c7828b0 by Alex Merry to branch frameworks. - Commit Hook On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 7:05 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43387 --- This review has been submitted with commit 72c38260b34bf03f0f3d807704580b576d991e6f by Alex Merry to branch frameworks. - Commit Hook On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43388 --- This review has been submitted with commit 858b2416420e5c5e1dabb581e7b10a858923135d by Alex Merry to branch frameworks. - Commit Hook On Nov. 10, 2013, 6:16 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 6:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). 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 113704: Fix EPS plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/#review43389 --- Ship it! tier1/kguiaddons/src/plugins/imageformats/eps.cpp http://git.reviewboard.kde.org/r/113704/#comment31243 Ah, yes, I misread. This code sounds OK then. - David Faure On Nov. 10, 2013, 7:05 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113704/ --- (Updated Nov. 10, 2013, 7:05 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- 4 commits. Previously, writing support was completely broken (it would write a PDF file instead of an EPS file). The rest of the changes mostly make it more maintainable. Disable EPS plugin on non-UNIX systems It depends on the gs command-line utility being in PATH, which is unlikely on Windows, for example. Use QProcess to run gs when reading EPS images Fix writing EPS files QPrinter is no longer capable of producing PostScript files, so we output to PDF then used GhostScript (or pdftops from Poppler) to convert the result to EPS. Note that GhostScript is already used by the reading code. Use qCDebug for the EPS plugin Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 005859ac6fd792f2589339bc68437dd2d965cc8f tier1/kguiaddons/src/plugins/imageformats/eps.cpp cb25052a9d7a01ea7a8ed8014726b762e8a5da16 Diff: http://git.reviewboard.kde.org/r/113704/diff/ Testing --- Successfully converted a JPG file to EPS and back again; both the final JPG and the intermediate EPS file display properly with Gwenview/Okular from KDE SC 4. This works both with pdftops present in PATH and without it (providing gs is in PATH). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sun, November 10, 2013 17:57:00 Kevin Ottens wrote: Now back to the submodules sha-1 update... The only thing I see to easily overcome that for our developers, is to have a hook, which would update the submodules for all the frameworks every time someone pushes in the tier 0 repository. Is it something the sysadmins would agree to have on the server? Any opinions or thoughts on that? I would highly recommend doing something similar to what was done for strigi when it was split into 5 git modules. There was something like strigi/strigiclient strigi/libstreams strigi/libstreamanalyzer strigi/strigiutils strigi/strigidaemon These are all separate, independently-buildable/packageable software modules. These are used directly by kdesrc-build (which doesn't support git-submodules) and also by the build.kde.org CI infrastructure. As a separate convenience for users building manually, from READMEs, etc., there is a separate strigi/strigi supermodule. If you clone that module you'll see that it has directories for each of the 5 strigi submodules, but that they're all empty. In other words, it's a shell already laid out for the user, who needs only to run git submodule update to get a full strigi checkout, which can be built all-at-once by the supermodule's shell CMakeLists.txt. Indeed, the CMakeLists.txt could even be configured to automatically handle the 'git submodule update' if desired. We could also do the tarball release from here in theory (seems to be what we do for strigi), though I'd recommend tarballs from the underlying submodules instead (which also eliminates the need for git archive-all). Splitting it up this way, we can emply proper inter-module dependencies (such as for distributions who track development from git, kdesrc-build, build.kde.org) without the requirement to write new code to support git- submodule just for this, while still allowing people who don't need to use/support such tools to get the full benefit of git-submodule doing the work for them. It also shouldn't add much (I doubt any!) work to the existing new code that would have to be written for a new git-submodule-using repository. The one concern is making sure that new code gets committed to the underlying submodule, but my understanding of git-submodule is that this would work correctly anyways (and it's an issue using submodules either way, whether we adopt my proposal or not). In short, I don't mind giving third-parties a way to quickly and easily grab tier0 without needing kdesrc-build (or anything other than git and CMake). We should even package convenience tier0 releases in tarball form. But we shouldn't reconfigure our git repositories or release/packaging processes to do this (at least to the extent of requiring one or both of git-submodule and source code updates during CMake). Instead we should simply make a separate git super-repo intended for that third-party usage and retain our existing separate repos for the benefit of our current devs, infrastructure, and interested third-parties/distribution packagers. Regards, - Michael Pyne 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: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 13:44:09 Michael Pyne wrote: I would highly recommend doing something similar to what was done for strigi when it was split into 5 git modules. I think you misunderstood the issue? A super-repo might help automating building all of KF5, but it doesn't solve the issue of defining the install dirs and compiler settings in the separate karchive tarball. The stuff in the super-repo won't be in the karchive tarball, so it's unrelated to the discussion in this thread, unless I'm missing something. [And FWIW, the strigi setup has always given me a lot of trouble (but probably because it was a special case rather than the common case)] -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
List of Frameworks
Hi, currently, http://community.kde.org/Frameworks/Epics/Modularization shows a list of modules in the respective Tiers. It does not, however, show whether it's functional, integration or a solution. Imo if would be good to have this as column, too. Since then a quick look allows us (for instate for KTextEditor/Kate Part) to find where we will finally end, depending on what actions/decisions we make. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
Hello,
Since there's been several times discussions about having a kind of Tier 0
for building our frameworks containing what is right now in ECM kde-modules
directory, but the idea was never really on the table because of the extra
dependency it'd bring, I looked a bit at the git submodule option to get
there.
The motivation for going with a git submodule is that it would allow such a
Tier 0 to be completely transparent to third parties who would want to grab
a Tier 1 framework and not bother about installing anything else than our
main dependencies (namely Qt, CMake and ECM).
Again: If we force third parties to install another KDE specific dependency
to build a Tier 1 framework from sources we failed.
So after playing a bit with several solutions (I looked at git subtree too
for instance), I still think that git submodule is the solution to use if
we got for such a Tier 0... it's not perfect though.
Indeed, submodules keep the information of the exact sha-1 used, there's no
way to have them track a branch automatically. That's likely to turn into a
problem (not for third parties this time but for our own developers) as from
the master branch of a framework we probably always want the tipping point
of the master branch of the repository containing the cmake files.
Also git archive ignores submodules when generating the archive... But
that's easy to fix and there's a git archive-all script available which
does the recursive export.
Now back to the submodules sha-1 update... The only thing I see to easily
overcome that for our developers, is to have a hook, which would update the
submodules for all the frameworks every time someone pushes in the tier 0
repository. Is it something the sysadmins would agree to have on the server?
Any opinions or thoughts on that?
If we agree on the approach I think we have a potential solution for
injecting a tier 0 in all our frameworks that could be put into place when
we start splitting the repositories.
Regards.
I'm about to write a blog about Kate on 5. In that context, I've quickly
created the frameworks 5 diagram with TikZ (I'm very much addicted to that).
Attached you can find the source code, along with the pdf file created by:
pdflatex kf5.tex
Feel free to put that into git, if you want. I've added a tier 0 already.
There, Tier 0 is basically defined by everything that is a requirement to
the other tiers.
Greetings,
Dominik
kf5.pdf
Description: Adobe PDF document
\documentclass{standalone}
\renewcommand*{\familydefault}{\sfdefault}
\usepackage{preview}
\usepackage{tikz}
\usetikzlibrary{calc, positioning, arrows}
\newcommand{\selfcircle}[1]{
\draw[-,scale=1.8] ($(#1.north west) + (2mm, 0)$) -- ++(0, 2mm) -- ++(-4mm, 0mm) -- ++(0mm, -4mm) -- ++(2mm, 0mm);
}
\begin{document}
\begin{preview}
\small
\begin{tikzpicture}[rectangle,
minimum height=1.5cm,
minimum width=3cm,
align=center,
node distance=4cm,
rounded corners=1mm,
very thick,
=latex]
\node[fill=green!20,draw=green!80] (t1s) {Solution\\Tier 1};
\node[fill=orange!20,draw=orange!80,align=center, right of=t1s] (t1i) {Integration\\Qt Addon\\Tier 1};
\node[fill=cyan!20,draw=cyan!80,align=center, right of=t1i] (t1f) {Functional\\Qt Addon\\Tier 1};
\node[fill=green!40,draw=green!80, node distance=3cm, above of=t1s] (t2s) {Solution\\Tier 2};
\node[fill=orange!40,draw=orange!80,align=center, right of=t2s] (t2i) {Integration\\Qt Addon\\Tier 2};
\node[fill=cyan!40,draw=cyan!80,align=center, right of=t2i] (t2f) {Functional\\Qt Addon\\Tier 2};
\node[fill=green!60,draw=green!80, node distance=3cm, above of=t2s] (t3s) {Solution\\Tier 3};
\node[fill=orange!60,draw=orange!80,align=center, right of=t3s] (t3i) {Integration\\Qt Addon\\Tier 3};
\node[fill=cyan!26,draw=cyan!80,align=center, right of=t3i] (t3f) {Functional\\Qt Addon\\Tier 3};
\node[fill=orange!80,draw=orange!80,align=center, node distance=3cm, above of=t3i] (t4i) {Look \ Feel\\Consistency\\Tier 4};
\node[fill=black,draw=black,circle, minimum size=1mm, inner sep=0mm] (pin) at ($(t3i) !0.5! (t4i)$) {};
\node[fill=black!10,draw=black, minimum width=11cm,minimum height=1cm,node distance=2cm, below of=t1i] (t0) {OS, Qt, Wayland/X11, system libraries, cmake modules, $\dots$};
% straight arrows from top to bottom
\draw[-] (t3s) -- (t2s);
\draw[-] (t2s) -- (t1s);
\draw[-] (t4i) -- (t3i);
\draw[-] (t3i) -- (t2i);
\draw[-] (t2i) -- (t1i);
\draw[-] (t3f) -- (t2f);
\draw[-] (t2f) -- (t1f);
\draw[-] (t1s.south) -- (t1s |- t0.north);
\draw[-] (t1i.south) -- (t1i |- t0.north);
\draw[-] (t1f.south) -- (t1f |- t0.north);
% straight arrows from left to right
\draw[-] (t3s) -- (t3i);
\draw[-] (t3i) -- (t3f);
% arrows from solution to integration, and integration to
Re: Review Request 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 10, 2013, 11:42 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest 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 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/#review43394 --- This review has been submitted with commit b1b4d885e1e3dc30eb5367be1f1aee01300a0359 by Alex Richardson to branch frameworks. - Commit Hook On Nov. 8, 2013, 9:04 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 8, 2013, 9:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest 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 113670: Only link to Qt5::X11Extras and ${X11_LIBRARIES} if X11 was found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/#review43395 --- This review has been submitted with commit 92ae4f49927e6b2f0b6567bc58db1cd51761cee7 by Alex Richardson to branch frameworks. - Commit Hook On Nov. 8, 2013, 9:04 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113670/ --- (Updated Nov. 8, 2013, 9:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Link kde4support privately to QtX11Extras, QtSvg and QtTest Otherwise every user of the target KF5::KDE4Support will also have Qt5::X11Extras Qt5::Svg Qt5::Test linked. This can cause linker errors like ld: cannot find -lQt5::Test REVIEW: 113670 Diffs - tier4/kde4support/src/CMakeLists.txt cbfac3e tier4/kde4support/src/kdeui/kxerrorhandler.h babf931 tier4/kde4support/src/kdeui/kxerrorhandler.cpp 3f4765d Diff: http://git.reviewboard.kde.org/r/113670/diff/ Testing --- I previously got the following error compiling okteta, now it works: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::X11Extras /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lQt5::Svg QtX11Info and QtSvg are not used in any installed headers, so IMO this should be fine qtest_kde.h does actually include QtTest headers, but only uses these types inside macros. And I guess any user of that header already also links to QtTest 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 113657: Fix Standalone Configuration of DNSSD
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/ --- (Updated Nov. 11, 2013, 12:21 a.m.) Review request for KDE Frameworks, Kevin Ottens, Aurélien Gâteau, and Stephen Kelly. Changes --- Fixing the issue raised about KF5_VERSION Repository: kdelibs Description --- Moved FindAvahi.cmake and FindDNSSD.cmake into KDNSSD, fixed details when building with DNSSD and factored out the Frameworks version. Diffs (updated) - cmake/modules/CMakeLists.txt 7910270 cmake/modules/FindAvahi.cmake cmake/modules/FindDNSSD.cmake 8604bd5 tier2/dnssd/CMakeLists.txt 2cfcc40 Diff: http://git.reviewboard.kde.org/r/113657/diff/ Testing --- 1. Configure with cmake 2. Configure with cmake and -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 Configures OK in both cases. Builds OK in case 1, does not build yet in case 2. 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 113657: Fix Standalone Configuration of DNSSD
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/#review43396 --- This review has been submitted with commit 39e87ae731a0972f3dbc532f1832527582551a00 by David E. Narvaez to branch frameworks. - Commit Hook On Nov. 11, 2013, 12:21 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/ --- (Updated Nov. 11, 2013, 12:21 a.m.) Review request for KDE Frameworks, Kevin Ottens, Aurélien Gâteau, and Stephen Kelly. Repository: kdelibs Description --- Moved FindAvahi.cmake and FindDNSSD.cmake into KDNSSD, fixed details when building with DNSSD and factored out the Frameworks version. Diffs - cmake/modules/CMakeLists.txt 7910270 cmake/modules/FindAvahi.cmake cmake/modules/FindDNSSD.cmake 8604bd5 tier2/dnssd/CMakeLists.txt 2cfcc40 Diff: http://git.reviewboard.kde.org/r/113657/diff/ Testing --- 1. Configure with cmake 2. Configure with cmake and -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 Configures OK in both cases. Builds OK in case 1, does not build yet in case 2. 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 113657: Fix Standalone Configuration of DNSSD
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113657/ --- (Updated Nov. 11, 2013, 12:25 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Kevin Ottens, Aurélien Gâteau, and Stephen Kelly. Repository: kdelibs Description --- Moved FindAvahi.cmake and FindDNSSD.cmake into KDNSSD, fixed details when building with DNSSD and factored out the Frameworks version. Diffs - cmake/modules/CMakeLists.txt 7910270 cmake/modules/FindAvahi.cmake cmake/modules/FindDNSSD.cmake 8604bd5 tier2/dnssd/CMakeLists.txt 2cfcc40 Diff: http://git.reviewboard.kde.org/r/113657/diff/ Testing --- 1. Configure with cmake 2. Configure with cmake and -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 Configures OK in both cases. Builds OK in case 1, does not build yet in case 2. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: List of Frameworks
On Sun, Nov 10, 2013 at 9:58 PM, Dominik Haumann dhaum...@kde.org wrote: Hi, currently, http://community.kde.org/Frameworks/Epics/Modularization shows a list of modules in the respective Tiers. It does not, however, show whether it's functional, integration or a solution. Imo if would be good to have this as column, too. Since then a quick look allows us (for instate for KTextEditor/Kate Part) to find where we will finally end, depending on what actions/decisions we make. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel You can find it here, somewhat: http://community.kde.org/Frameworks/Epics/Splitting_kdelibs Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113792: Fix Build of KDNSSD with DNSSD Backend
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Adjusting the code to changes in Qt5. The nature of the changes makes me wonder if this code is maintained at all or if the DNSSD backend should be dropped. Diffs - tier2/dnssd/src/mdnsd-servicebrowser.cpp 37449db tier2/dnssd/src/mdnsd-publicservice.cpp 5da6f97 tier2/dnssd/src/mdnsd-domainbrowser.cpp 21c359e tier2/dnssd/src/CMakeLists.txt c71ade2 tier2/dnssd/CMakeLists.txt 13497d1 Diff: http://git.reviewboard.kde.org/r/113792/diff/ Testing --- 1. Configure KDNSSD with -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 2. Build Builds successfully. 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 113723: Fix KIO to build standalone, prepare for moving into its tier
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/ --- (Updated Nov. 11, 2013, 3:23 a.m.) Review request for KDE Frameworks. Changes --- updated following (some of) david's comments. Repository: kdelibs Description --- As you will see, this splitting was a bit harder than others: - KIO was using a couple of private headers from kjobwidgets, which now they will be installed. - The xslt_kde target was being used from KDocTools without having it exported. Now it will be properly exported. - Also defines all dependencies so it can be compiled independently, modularization is done as well. Diffs (updated) - staging/kio/src/ioslaves/help/CMakeLists.txt 40637dc staging/kio/src/filewidgets/CMakeLists.txt 31fe8c6 staging/kio/CMakeLists.txt 6c7297e cmake/modules/FindGSSAPI.cmake cmake/modules/CMakeLists.txt 07f7eac staging/kio/src/ioslaves/http/kcookiejar/CMakeLists.txt 2630f01 staging/kio/src/ioslaves/http/tests/CMakeLists.txt 52c9f6c staging/kio/src/widgets/CMakeLists.txt d90386d staging/kio/src/widgets/kopenwithdialog.cpp cb4fc0f staging/kio/tests/CMakeLists.txt 6cee291 superbuild/CMakeLists.txt 53f5952 tier1/kcoreaddons/src/lib/CMakeLists.txt 4e6e206 tier1/kcoreaddons/src/lib/jobs/kcompositejob_p.h 20baf7c tier2/kdoctools/CMakeLists.txt c2256ff tier2/kdoctools/KDocToolsConfig.cmake d501dc8 tier2/kdoctools/KDocToolsConfig.cmake.in PRE-CREATION tier2/kdoctools/src/CMakeLists.txt 3940e98 tier3/kded/KDEDConfig.cmake.in 32f8d56 Diff: http://git.reviewboard.kde.org/r/113723/diff/ Testing --- Builds, Installs, tests still pass; both modularized and monolithic kdelibs. 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 113723: Fix KIO to build standalone, prepare for moving into its tier
On Nov. 9, 2013, 12:47 a.m., David Faure wrote: staging/kio/CMakeLists.txt, line 30 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line30 already listed 6 lines above I had to add it because it's a dependency-of-a-dependency. I'll add a comment about that. On Nov. 9, 2013, 12:47 a.m., David Faure wrote: tier3/kservice/src/CMakeLists.txt, line 91 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212066#file212066line91 Why? My grepping for KServiceOffer says that it's only used in the kservice framework. /home/kde-devel/frameworks/kdelibs/staging/kio/src/widgets/kopenwithdialog.cpp:50:27: fatal error: kserviceoffer.h: No such file or directory #include kserviceoffer.h But it wasn't needed, I removed the include and it still works. On Nov. 9, 2013, 12:47 a.m., David Faure wrote: staging/kio/CMakeLists.txt, line 35 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line35 already listed 3 lines before. Dependency of a dependency On Nov. 9, 2013, 12:47 a.m., David Faure wrote: staging/kio/CMakeLists.txt, line 42 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line42 needed? Dependency of a dependency On Nov. 9, 2013, 12:47 a.m., David Faure wrote: tier1/kcoreaddons/src/lib/CMakeLists.txt, line 128 http://git.reviewboard.kde.org/r/113723/diff/1/?file=212060#file212060line128 I think we should instead treat them as separate libs, and remove the inheritance from KCompositeJobPrivate in KIO::JobPrivate. It's just an optimization. We don't want to break BIC in an existing libkio if we ever change kcoreaddons' private classes. (Unless we can guarantee that they are always the same version - like Qt does, but the difference is that they don't need to install private headers for this; and they have a runtime check for version mismatches). All in all, I think an extra call to new per kio job is the simplest solution; a kio job takes much longer than that anyway. Can we then just skip this part and make this a different patch? I can do it, but it seems unrelated to me. - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/#review43285 --- On Nov. 11, 2013, 3:23 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113723/ --- (Updated Nov. 11, 2013, 3:23 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- As you will see, this splitting was a bit harder than others: - KIO was using a couple of private headers from kjobwidgets, which now they will be installed. - The xslt_kde target was being used from KDocTools without having it exported. Now it will be properly exported. - Also defines all dependencies so it can be compiled independently, modularization is done as well. Diffs - staging/kio/src/ioslaves/help/CMakeLists.txt 40637dc staging/kio/src/filewidgets/CMakeLists.txt 31fe8c6 staging/kio/CMakeLists.txt 6c7297e cmake/modules/FindGSSAPI.cmake cmake/modules/CMakeLists.txt 07f7eac staging/kio/src/ioslaves/http/kcookiejar/CMakeLists.txt 2630f01 staging/kio/src/ioslaves/http/tests/CMakeLists.txt 52c9f6c staging/kio/src/widgets/CMakeLists.txt d90386d staging/kio/src/widgets/kopenwithdialog.cpp cb4fc0f staging/kio/tests/CMakeLists.txt 6cee291 superbuild/CMakeLists.txt 53f5952 tier1/kcoreaddons/src/lib/CMakeLists.txt 4e6e206 tier1/kcoreaddons/src/lib/jobs/kcompositejob_p.h 20baf7c tier2/kdoctools/CMakeLists.txt c2256ff tier2/kdoctools/KDocToolsConfig.cmake d501dc8 tier2/kdoctools/KDocToolsConfig.cmake.in PRE-CREATION tier2/kdoctools/src/CMakeLists.txt 3940e98 tier3/kded/KDEDConfig.cmake.in 32f8d56 Diff: http://git.reviewboard.kde.org/r/113723/diff/ Testing --- Builds, Installs, tests still pass; both modularized and monolithic kdelibs. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Having a Tier 0 for cmake and git submodules
On Sun, November 10, 2013 20:11:07 David Faure wrote: On Sunday 10 November 2013 13:44:09 Michael Pyne wrote: I would highly recommend doing something similar to what was done for strigi when it was split into 5 git modules. I think you misunderstood the issue? A super-repo might help automating building all of KF5, but it doesn't solve the issue of defining the install dirs and compiler settings in the separate karchive tarball. The stuff in the super-repo won't be in the karchive tarball, so it's unrelated to the discussion in this thread, unless I'm missing something. I believe the idea is that the karchive tarball would have an implicit dependency on a KF5 umbrella supermodule, no? I.e. what we're calling ECM now would be replaced by a tier0... although, re-reading Kévin's email, it seems that ECM would still be a separate dependency (but made generic) and that tier0 would be implicitly included with all tier1 repositories (or, *all* repositories?). I have to admit I'd like that even less, if we're going to be making one-stop git modules for developer convenience I'd argue that we should replace ECM in that list of dependencies with Alex's proposed KF5 umbrella, which gives the same number of overall dependencies but still has the submodule magic (to hide the actual number of dependencies) and retains the generic/KDE split for CMake settings. As you mention elsewhere we'd still need to support a separate release of our KDE CMake build system files for third-party software to depend on. I will point out that kdecvs-build (from way back in the day) had to support kde-common/admin, which wasn't much fun either. I was very glad to have gotten away from that for KDE 4, especially since each tarball release had seemingly 800k added just from KDE 3 buildsystem cruft alone, which had to be duplicated into the tarball each time. [And FWIW, the strigi setup has always given me a lot of trouble (but probably because it was a special case rather than the common case)] Same here, it was the reason kdesrc-build now supports a build-script-ignore file to completely hide the strigi/strigi super-repository... but that feature ended up being needed for various websites now based in git anyways. Regards, - Michael Pyne 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: Re: List of Frameworks
On Monday, November 11, 2013 02:22:43 Aleix Pol wrote: On Sun, Nov 10, 2013 at 9:58 PM, Dominik Haumann dhaum...@kde.org wrote: Hi, currently, http://community.kde.org/Frameworks/Epics/Modularization shows a list of modules in the respective Tiers. It does not, however, show whether it's functional, integration or a solution. Imo if would be good to have this as column, too. Since then a quick look allows us (for instate for KTextEditor/Kate Part) to find where we will finally end, depending on what actions/decisions we make. Greetings, Dominik You can find it here, somewhat: http://community.kde.org/Frameworks/Epics/Splitting_kdelibs Ah thanks, that's exactly what I was looking for. Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
