Re: Review Request 112896: Rework NETWM classes
On Sept. 26, 2013, 4:27 a.m., Fredrik Höglund wrote: I'm just going to point out something I know you already know since we've discussed it many times; that an xcb port of the NETWM classes already exists in a branch. Martin Gräßlin wrote: my aim was to write the unit test and that was the big junk of this work compared to the xcb changes (which I thought to be easier than trying to rebase the branch :-( ) Fredrik Höglund wrote: The problem with rebasing the branch was solved a long time ago. There shouldn't be any conflicts except maybe in CMakeLists.txt files. ah, I didn't know that. I will have a look and see whether I can integrate the unit tests and the bug fixes on top of your branch. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112896/#review40840 --- On Sept. 23, 2013, 3:11 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112896/ --- (Updated Sept. 23, 2013, 3:11 p.m.) Review request for KDE Frameworks. Description --- This is a patch series, if needed I can push the branch. The patches address the following topics: * add unit tests for NETRootInfo and NETWinInfo which do not require a running window manager. Test coverage of netwm.h is: ** line coverage: 75 % ** functions coverage: 84 % ** branch coverage: 62 % The tests start their own Xvfb to have a clean state and not mess up with the Window Manager of a user or cause followint tests to fail on the CI system * areas which are covered by unit tests are changed from XLib to XCB. This mostly affects changing and reading window properties * API is changed from XLib types to XCB types. E.g. xcb_window_t instead of Window. Note: this is an API break, which I consider as necessary, given that especially the type Window is problematic. * several bugs which were discovered through the added tests are fixed * NETWinInfo2 is merged into NETWinInfo (marked as TODO KDE5) * Small wrapper class for intern atom added to KXUtils. Similar code already in usage in KWin. = Commits: commit 2e50845a5d0df436106aeb776e3936691c32a753 Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 14:31:42 2013 +0200 Use XCB for reading properties in NETRootInfo::update Viewport handling was incorrect and is adjusted to be read correctly. commit 23887726c03c49b4e0021c01f319653d3b9f36c5 Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 11:41:26 2013 +0200 Use XCB for reading properties in NETWinInfo::update Those areas which are covered by unit tests are migrated from XGetWindowProperty to the xcb variant. BlocksCompositing had an incorrect read - it expected a string atom, but actually uses a cardinal. This bug is fixed. commit 2731ebbc85eddb885700232f98e0e429cb0e066b Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 09:41:28 2013 +0200 Use XCB to change the Client dependent properties of NETWinInfo Those properties for which we have unit tests are changed to XCB to either change or delete the property. commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a Author: Martin Gräßlin mgraess...@kde.org Date: Fri Sep 20 09:58:09 2013 +0200 Unit test for Client aspect of NETWinInfo Similar to the NETWinInfo test with WindowManager aspect, just verifying the properties which can only be set by a Client. The test found highlights a few possible problems: * for some window types a fallback type is specified, but the lenght is set to 1, thus the fallback type is not set at all * Fullscreen monitors property is not handled in the event function commit 2731ebbc85eddb885700232f98e0e429cb0e066b Author: Martin Gräßlin mgraess...@kde.org Date: Mon Sep 23 09:41:28 2013 +0200 Use XCB to change the Client dependent properties of NETWinInfo Those properties for which we have unit tests are changed to XCB to either change or delete the property. commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a Author: Martin Gräßlin mgraess...@kde.org Date: Fri Sep 20 09:58:09 2013 +0200 Unit test for Client aspect of NETWinInfo Similar to the NETWinInfo test with WindowManager aspect, just verifying the properties which can only be set by a Client. The test found highlights a few possible problems: * for some window types a fallback type is specified, but the lenght is set to 1, thus the fallback type is not set at all * Fullscreen monitors property is not handled in the event function
Review Request 112964: Prepare KPrintUtils cmake stuff
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112964/ --- Review request for KDE Frameworks. Description --- ...before splitting. Diffs - staging/kprintutils/CMakeLists.txt 28ce872 staging/kprintutils/KPrintUtilsConfig.cmake.in f281555 Diff: http://git.reviewboard.kde.org/r/112964/diff/ Testing --- Still builds. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks Overview
On Wed, Sep 25, 2013 at 8:22 AM, Alexander Neundorf neund...@kde.org wrote: On Tuesday 24 September 2013, Ben Cooksley wrote: On Sep 24, 2013 7:33 AM, Alexander Neundorf neund...@kde.org wrote: On Monday 23 September 2013, Sebastian Kügler wrote: Hey, On Monday, September 23, 2013 00:27:21 Cornelius Schumacher wrote: On Thursday 19 September 2013 Sebastian Kügler wrote: http://community.kde.org/Frameworks/Overview I have put the data on Inqlude (see http://inqlude.org/edge.html). Thanks. One issue though, we're duplicating incomplete information that is in flux. (For example, I know of at least one framework that has been added to tier2 (I think) since last week. The information will need constant updating for a few more months. Having it in to places doesn't make that easier. Can I update the info on inqlude.org somehow, so we can ditch the wiki version? It would be nice, if we could improve the presentation of the different libraries along with the code. The goal of Inqlude is to make them easily accessible not only to us, but also to Qt developers who don't necessarily know anything about KDE or might have (more or less founded) objections against using KDE libraries. To reach this we'll need to present KF5 in a bit more independent way, and make sure that each library can stand on its own. Technically, this is the current focus. We're splitting kdelibs. As to communication, it probably needs a bit of boilerplate. (Which the bits I wrote don't contain purposefully.) Otherwise, you're right, we need to work on the presentation side here. IMO, if projects.kde.org would have the wiki enabled, the project pages there could be an easy way to have simple homepages for all the frameworks: https://projects.kde.org/projects/kdesupport/attica Due to maintenance and performance concerns, sysadmin would like to move away from Chiliproject. Oh, really ? What alternatives are you looking at ? Personally I like redmine/chili a lot. Yep. At the moment there are no real contenders as such - which is why it has not yet been replaced. Phabricator is being monitored for progress on a blocking issue however. The primary issues are those of performance ( Enabling the wiki would complicate this when a replacement is found. It would also create competition with the main wikis. I don't think so. As Cornelius put it To reach this we'll need to present KF5 in a bit more independent way, and make sure that each library can stand on its own. IMO a kind of separate home page for each library is part of that. Would something similar to the Manifesto site fit this? Alex Regards, Ben ___ 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 112921: Adjust CMakeLists.txt files in KEmoticons (prior to splitting)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112921/#review40906 --- Ship it! Ship It! - David Faure On Sept. 25, 2013, 8:21 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112921/ --- (Updated Sept. 25, 2013, 8:21 p.m.) Review request for KDE Frameworks. Description --- Adjust CMakeLists.txt files in KEmoticons (prior to splitting) Diffs - staging/kemoticons/autotests/CMakeLists.txt b7e890c19af2ba7febc7a45fc4a73daa25ea4f74 staging/kemoticons/src/providers/adium/CMakeLists.txt c94c0be669ed1b55bc6fd5fbe036d1e38228066c staging/kemoticons/src/providers/kde/CMakeLists.txt e6d4243538e6f95db664efe0b8b162523a6b1179 staging/kemoticons/src/providers/xmpp/CMakeLists.txt f034de047847ffec50ac6a68977b01809010447d Diff: http://git.reviewboard.kde.org/r/112921/diff/ Testing --- It builds. Tests pass. I tested moving the framework to tier3 without any compile erors. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 112966: Dispatch KInterProcessWindowing to other frameworks
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112966/ --- Review request for KDE Frameworks, Kevin Ottens and Martin Gräßlin. Description --- This review dispatches content of the KInterProcessWindowing framework to other frameworks: - KMessageBox methods are moved to KWidgetsAddons, with a small duplication of code from KWindowSystem - KUserTimestamp namespace is moved to KWindowSystem Diffs - CMakeLists.txt 0939738 KDE5PORTING.html 57ecf2e KDELibs4Config.cmake 562fa3a khtml/java/CMakeLists.txt daa51ee khtml/java/tests/CMakeLists.txt eaa715a kioslave/http/kcookiejar/CMakeLists.txt b3985fb staging/CMakeLists.txt 900bdae staging/kde4support/src/CMakeLists.txt 46fce06 staging/kde4support/src/kdeui/kmessagebox_queued.cpp 54db324 staging/kinterprocesswindowing/CMakeLists.txt 3cb2127 staging/kinterprocesswindowing/KInterProcessWindowingConfig.cmake.in 717587c staging/kinterprocesswindowing/src/CMakeLists.txt 126f9bf staging/kinterprocesswindowing/src/config-kinterprocesswindowing.h.cmake 5169547 staging/kinterprocesswindowing/src/kmessagebox_kiw.h e53a18f staging/kinterprocesswindowing/src/kmessagebox_kiw.cpp 3b63c9a staging/kinterprocesswindowing/src/kusertimestamp.h 0316a15 staging/kinterprocesswindowing/src/kusertimestamp.cpp 38459e0 staging/kinterprocesswindowing/tests/CMakeLists.txt b326815 staging/kinterprocesswindowing/tests/kmessageboxwidtest.h 097756a staging/kinterprocesswindowing/tests/kmessageboxwidtest.cpp 972e57e tier1/kwidgetsaddons/src/kmessagebox.h f34c2c4 tier1/kwidgetsaddons/src/kmessagebox.cpp 1fff72f tier1/kwidgetsaddons/tests/CMakeLists.txt 4297a3b tier1/kwidgetsaddons/tests/kmessageboxwidtest.cpp PRE-CREATION tier1/kwindowsystem/src/CMakeLists.txt 31fb53e tier1/kwindowsystem/src/kusertimestamp.h PRE-CREATION tier1/kwindowsystem/src/kusertimestamp.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112966/diff/ Testing --- Still builds, tests pass. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112928: Template files for frameworks
On Sept. 26, 2013, 10:27 p.m., Alexander Neundorf wrote: template/CMakeLists.txt, line 22 http://git.reviewboard.kde.org/r/112928/diff/5/?file=192796#file192796line22 The idea here was that you can simply list all required KF5 frameworks in one find_package() call: find_package(KF5 COMPONENTS CMake Compiler InstallDirs KCoreAddons Solid ) When not doing this, you can also use the longer include() syntax instead of the find_package(KF5) syntax: include(KDECMakeSettings) include(KDECompilerSettings) include(KDEInstallDirs) find_package(KCoreAddons) Stephen Kelly wrote: What would make sense to me is this: As a downstream KDE application find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) As a downstream which is not a KDE application: find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) That way, when we're building KF5 tier1, we're not finding KF5. We're finding and using ECM. When we're building KF5 tier2, we're finding out tier1 deps and we're finding and using ECM. etc. That maps to reality. It's a bit unfortunate that find_package(KF5) has to be a FindKF5 in ECM, but that's ok IMO. Thanks, Steve. Alexander: I am still not sure what the arguments after REQUIRED are, I just cargo-culted them. Are you saying this is just a way to avoid adding include() lines? If so, how comes the arguments after REQUIRED are not exactly the same as the one you used in your include() lines? Steve: this sounds good to me, but would be tricky to keep readable if we fit all in one template file. Maybe it would be better to create different templates, like templates/tier1, templates/tiern, templates/kde-app, templates/qt-app? I am worried about the templates bit-rotting though. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/#review40893 --- On Sept. 26, 2013, 4:37 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/ --- (Updated Sept. 26, 2013, 4:37 p.m.) Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and Stephen Kelly. Description --- This patch adds a template/ dir which contains example CMakeLists.txt and FooBarConfig.cmake.in files, based on what exists in current frameworks. Diffs - template/CMakeLists.txt PRE-CREATION template/FooBarConfig.cmake.in PRE-CREATION template/setup.sh PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112928/diff/ Testing --- 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 112928: Template files for frameworks
On Sept. 26, 2013, 8:27 p.m., Alexander Neundorf wrote: template/CMakeLists.txt, line 22 http://git.reviewboard.kde.org/r/112928/diff/5/?file=192796#file192796line22 The idea here was that you can simply list all required KF5 frameworks in one find_package() call: find_package(KF5 COMPONENTS CMake Compiler InstallDirs KCoreAddons Solid ) When not doing this, you can also use the longer include() syntax instead of the find_package(KF5) syntax: include(KDECMakeSettings) include(KDECompilerSettings) include(KDEInstallDirs) find_package(KCoreAddons) Stephen Kelly wrote: What would make sense to me is this: As a downstream KDE application find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) As a downstream which is not a KDE application: find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) That way, when we're building KF5 tier1, we're not finding KF5. We're finding and using ECM. When we're building KF5 tier2, we're finding out tier1 deps and we're finding and using ECM. etc. That maps to reality. It's a bit unfortunate that find_package(KF5) has to be a FindKF5 in ECM, but that's ok IMO. Thanks, Steve. Aurélien Gâteau wrote: Alexander: I am still not sure what the arguments after REQUIRED are, I just cargo-culted them. Are you saying this is just a way to avoid adding include() lines? If so, how comes the arguments after REQUIRED are not exactly the same as the one you used in your include() lines? Steve: this sounds good to me, but would be tricky to keep readable if we fit all in one template file. Maybe it would be better to create different templates, like templates/tier1, templates/tiern, templates/kde-app, templates/qt-app? I am worried about the templates bit-rotting though. My comment was more about what is maintained in the repos and what I find readable and what I think maps to reality. My comment was not spefically about what a template-based generator would generate. After being generated from a template the code will have to be changed and maintained anyway. I'd put a comment in the single template that you have, not create multiple templates. That would only have people wondering what to use. Note though that what I said would make sense to me is not the current state. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/#review40893 --- On Sept. 26, 2013, 2:37 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/ --- (Updated Sept. 26, 2013, 2:37 p.m.) Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and Stephen Kelly. Description --- This patch adds a template/ dir which contains example CMakeLists.txt and FooBarConfig.cmake.in files, based on what exists in current frameworks. Diffs - template/CMakeLists.txt PRE-CREATION template/FooBarConfig.cmake.in PRE-CREATION template/setup.sh PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112928/diff/ Testing --- 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: QTimeZone merged for 5.2
On Wednesday 25 September 2013 11:28:54 John Layt wrote: On 24 September 2013 19:24, Kevin Ottens er...@kde.org wrote: On Tuesday 24 September 2013 19:03:21 John Layt wrote: I'll do some analysis on the use of all the widgets and what ones are worth keeping, and look at the Qt widgets to see if they're worth switching to, if not before then at Qt Dev Days / Qt Contributors Day. OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We really need to put this issue to a rest, it's been lingering for way too long. Really looking forward to your analysis! Started to look at the number of uses, but lxr hardly shows any. Does lxr include .ui files, or do I need to grep? I don't think it does unfortunately. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Wednesday 25 September 2013 01:13:05 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Why you guys don't treat e-c-m as a dependency for the tier system but treat kdoctools as one? Well, e-c-m is one too many for my taste to be honest. But we have no way around it I'm afraid. :-) I mean they are both prerequisites for the other modules (and if you remove KArchive from kdoctools as the thread title suggests both are 'non-kde'), aren't they? Indeed, that makes for a: 3) make kdoctool not depend on anything else from KDE Frameworks, and frameworks which have manpages can optionally use it. Makes for a kind of exception in the way we manage the dependencies so far, not sure I like this increase in complexity either. Personally I think I would aim for: * no docbook in tier 1; * remove the KArchive dependency of kdoctools (making it tier 1); * make it an optional dependencies for tier 2 and 3 frameworks which would need it. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112928: Template files for frameworks
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/ --- (Updated Sept. 27, 2013, 5:05 p.m.) Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and Stephen Kelly. Changes --- Add templates for subdirs as well. Based on feedback when devs where confused how to generate the target export files (needed CMake commands are in src/CMakeLists.txt). The template actually can actually be built and installed now, which is helpful to make sure it is still valid. Description --- This patch adds a template/ dir which contains example CMakeLists.txt and FooBarConfig.cmake.in files, based on what exists in current frameworks. Diffs (updated) - template/CMakeLists.txt PRE-CREATION template/FooBarConfig.cmake.in PRE-CREATION template/autotests/CMakeLists.txt PRE-CREATION template/setup.sh PRE-CREATION template/src/CMakeLists.txt PRE-CREATION template/src/myclass.h PRE-CREATION template/src/myclass.cpp PRE-CREATION template/tests/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112928/diff/ Testing --- 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 112928: Template files for frameworks
On Sept. 26, 2013, 10:27 p.m., Alexander Neundorf wrote: template/CMakeLists.txt, line 22 http://git.reviewboard.kde.org/r/112928/diff/5/?file=192796#file192796line22 The idea here was that you can simply list all required KF5 frameworks in one find_package() call: find_package(KF5 COMPONENTS CMake Compiler InstallDirs KCoreAddons Solid ) When not doing this, you can also use the longer include() syntax instead of the find_package(KF5) syntax: include(KDECMakeSettings) include(KDECompilerSettings) include(KDEInstallDirs) find_package(KCoreAddons) Stephen Kelly wrote: What would make sense to me is this: As a downstream KDE application find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) As a downstream which is not a KDE application: find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) In the KF5 tier1 buildsystems: find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) That way, when we're building KF5 tier1, we're not finding KF5. We're finding and using ECM. When we're building KF5 tier2, we're finding out tier1 deps and we're finding and using ECM. etc. That maps to reality. It's a bit unfortunate that find_package(KF5) has to be a FindKF5 in ECM, but that's ok IMO. Thanks, Steve. Aurélien Gâteau wrote: Alexander: I am still not sure what the arguments after REQUIRED are, I just cargo-culted them. Are you saying this is just a way to avoid adding include() lines? If so, how comes the arguments after REQUIRED are not exactly the same as the one you used in your include() lines? Steve: this sounds good to me, but would be tricky to keep readable if we fit all in one template file. Maybe it would be better to create different templates, like templates/tier1, templates/tiern, templates/kde-app, templates/qt-app? I am worried about the templates bit-rotting though. Stephen Kelly wrote: My comment was more about what is maintained in the repos and what I find readable and what I think maps to reality. My comment was not spefically about what a template-based generator would generate. After being generated from a template the code will have to be changed and maintained anyway. I'd put a comment in the single template that you have, not create multiple templates. That would only have people wondering what to use. Note though that what I said would make sense to me is not the current state. Oh OK. Actually, I would not put instructions for application in there, just tier1 and tier N+1. Application instructions should be kept somewhere else IMO. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/#review40893 --- On Sept. 27, 2013, 5:05 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/ --- (Updated Sept. 27, 2013, 5:05 p.m.) Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and Stephen Kelly. Description --- This patch adds a template/ dir which contains example CMakeLists.txt and FooBarConfig.cmake.in files, based on what exists in current frameworks. Diffs - template/CMakeLists.txt PRE-CREATION template/FooBarConfig.cmake.in PRE-CREATION template/autotests/CMakeLists.txt PRE-CREATION template/setup.sh PRE-CREATION template/src/CMakeLists.txt PRE-CREATION template/src/myclass.h PRE-CREATION template/src/myclass.cpp PRE-CREATION template/tests/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112928/diff/ Testing --- 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: QTimeZone merged for 5.2
On 25 September 2013 17:21, Mark mark...@gmail.com wrote: snip I've been talking to the QML component guys and they will have a new calendar component for 5.3 that they need QCalendarSystem for as well. /snip Hi John, What you said there sounds very interesting to me! Do you have any link for me where i can read about that or where current code in that area is being developed? Cheers, Mark Sure. Just to correct myself, Mitch says its the QtQuick Controls' Calendar, not the actual QCalendarWidget. Not that I know what that means, I really need to take a QML course :-) https://codereview.qt-project.org/#change,45769 http://qt-project.org/doc/qt-5.1/qtqml/qml-qtqml2-date.html (the from* methods are missing.. see next link for those). https://codereview.qt-project.org/#patch,sidebyside,61255,1,src/qml/doc/snippets/qml/date.qml In response I pointed him at my draft QCalendarSystem class. http://qt-project.org/wiki/Qt-5-ICU#955c0120c32f7991db7d55a94df808c2. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 27 September 2013 16:52, Kevin Ottens er...@kde.org wrote: On Wednesday 25 September 2013 11:28:54 John Layt wrote: Started to look at the number of uses, but lxr hardly shows any. Does lxr include .ui files, or do I need to grep? I don't think it does unfortunately. No, doesn't appear to, I'm busy doing a full checkout of every repo... Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112928: Template files for frameworks
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/#review40917 --- This looks complete to me. - Stephen Kelly On Sept. 27, 2013, 3:05 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/ --- (Updated Sept. 27, 2013, 3:05 p.m.) Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and Stephen Kelly. Description --- This patch adds a template/ dir which contains example CMakeLists.txt and FooBarConfig.cmake.in files, based on what exists in current frameworks. Diffs - template/CMakeLists.txt PRE-CREATION template/FooBarConfig.cmake.in PRE-CREATION template/autotests/CMakeLists.txt PRE-CREATION template/setup.sh PRE-CREATION template/src/CMakeLists.txt PRE-CREATION template/src/myclass.h PRE-CREATION template/src/myclass.cpp PRE-CREATION template/tests/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112928/diff/ Testing --- 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: Frameworks Overview
On Friday 27 September 2013, Ben Cooksley wrote: ... Yep. At the moment there are no real contenders as such - which is why it has not yet been replaced. Phabricator is being monitored for progress on a blocking issue however. The primary issues are those of performance ( That's a pity. Enabling the wiki would complicate this when a replacement is found. It would also create competition with the main wikis. I don't think so. As Cornelius put it To reach this we'll need to present KF5 in a bit more independent way, and make sure that each library can stand on its own. IMO a kind of separate home page for each library is part of that. Would something similar to the Manifesto site fit this? You mean http://manifesto.kde.org ? Are these plain html pages, or is it using some CMS or wiki ? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
