Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,All,clang - Build # 35 - Still Failing!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=All,compiler=clang/35/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Future frameworks releases
On Jun 16, 2015 12:14 PM, Christian Mollekopf chrig...@fastmail.fm wrote: I'm glad to hear that. Until then I guess my options are limited: * I can keep kimap out of frameworks, but that doesn't buy me a whole lot as I still rely on other frameworks, and most of the PIM libraries really ought to be frameworks. So I'm not inclined to do that. * I can maintain versioned branches for all frameworks I need, which is going to be a PITA, but at least for me only. This is likely what's going to happen until we can adjust the versioning policy somehow from by POV. Christian, You said you use Qt 4.6, but never update it, and workaround the issues solved in later versions of Qt. What stops you from doing the same for Qt5 and KF5? For example, you can freeze dependencies of KImap, etc at Qt 5.4.2 and KF 5.11 and workaround the bugs existing in these versions. If KImap is not part of KF5 (or not version-locked with KF5), then updates of KImap friends will obviously be possible without touching Qt5 or dependent KF5 frameworks. -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,All,clang - Build # 34 - Still Failing!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=All,compiler=clang/34/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,NoX11,clang - Build # 35 - Still Failing!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=NoX11,compiler=clang/35/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,NoX11,clang - Build # 36 - Fixed!
We thank you for fixing your build!___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
On June 17, 2015, 7:24 a.m., David Faure wrote: I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :( Alex Richardson wrote: Possibly we should let desktopfileparser read a servicetype file? Was also suggested here: https://git.reviewboard.kde.org/r/121672/ Sebastian Kügler wrote: So it has to look in standardpaths and somewhere in the buildpath for a service file, then use that to generate the json file? I guess the servicefile could be fairly simple, as it just has to note unknown key/type combinations. The KDE4-style service files do have that information, and as long as we don't have to parse that at runtime, we should be fine. On the other hand, we'll get build-time dependencies on these servicetype files, as it's now not good enough anymore to install them at some point, the resulting json information is going to differ then. Sebastian Kügler wrote: Observation: I'm looking into parsing the proper servicetype, and I think it could be quite straightforward, if we're OK with going over all servicetypes installed at. Would incur some cost, but it would mean that apps can -- yet again -- add their own non-bool, non-int and non-string keys. But ... as to this patch, I'd still like to see it go in because the formfactor key makes sense for pretty much all services, plugins and application, so the usecase is not simply per app, but we want to limit the plugins and apps per formfactor (this would also allow us starting with a different commandline option on a different formfactor (by providing more than one desktop file), and it's IMO the most flexible solution we can provide). It also means, that it should probably be elevated to premier API, so a new getter for KPluginMetaData makes sense. I'll add that and will update this patch. At the same time, I'll work on parsing the servicetypes from desktoptojson, that should work just fine, as long as servicetypes are available at compile time (would not cause regressions anyway, since we don't support it right now, so would be a mere addition). Ah OK I didn't know it would make sense for all services, plugins and applications. +1 then. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 --- On June 17, 2015, 11 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 17, 2015, 11 p.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b src/lib/plugin/kpluginmetadata.h 4572d36 src/lib/plugin/kpluginmetadata.cpp eaaf0b9 Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 17, 2015, 11 p.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Changes --- Add QStringList KPluginMetaData::formFactors() API, incl. autotest. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs (updated) - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b src/lib/plugin/kpluginmetadata.h 4572d36 src/lib/plugin/kpluginmetadata.cpp eaaf0b9 Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
On June 17, 2015, 7:24 a.m., David Faure wrote: I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :( Alex Richardson wrote: Possibly we should let desktopfileparser read a servicetype file? Was also suggested here: https://git.reviewboard.kde.org/r/121672/ Sebastian Kügler wrote: So it has to look in standardpaths and somewhere in the buildpath for a service file, then use that to generate the json file? I guess the servicefile could be fairly simple, as it just has to note unknown key/type combinations. The KDE4-style service files do have that information, and as long as we don't have to parse that at runtime, we should be fine. On the other hand, we'll get build-time dependencies on these servicetype files, as it's now not good enough anymore to install them at some point, the resulting json information is going to differ then. Observation: I'm looking into parsing the proper servicetype, and I think it could be quite straightforward, if we're OK with going over all servicetypes installed at. Would incur some cost, but it would mean that apps can -- yet again -- add their own non-bool, non-int and non-string keys. But ... as to this patch, I'd still like to see it go in because the formfactor key makes sense for pretty much all services, plugins and application, so the usecase is not simply per app, but we want to limit the plugins and apps per formfactor (this would also allow us starting with a different commandline option on a different formfactor (by providing more than one desktop file), and it's IMO the most flexible solution we can provide). It also means, that it should probably be elevated to premier API, so a new getter for KPluginMetaData makes sense. I'll add that and will update this patch. At the same time, I'll work on parsing the servicetypes from desktoptojson, that should work just fine, as long as servicetypes are available at compile time (would not cause regressions anyway, since we don't support it right now, so would be a mere addition). - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 --- On June 11, 2015, 4:16 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 11, 2015, 4:16 a.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124118: Make it possible to use KCoreAddons's desktoptojson in cross-compiled environments
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124118/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Follows the lead of kconfig patch: https://git.reviewboard.kde.org/r/124104/ Diffs - CMakeLists.txt 552851d KF5CoreAddonsConfig.cmake.in caa1c0a autotests/CMakeLists.txt 51fcfb4 src/desktoptojson/CMakeLists.txt e6041cb Diff: https://git.reviewboard.kde.org/r/124118/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 124104: Make it possible to use kconfig_compiler from different sources
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/#review81550 --- From a cross-compile POV, this makes sense. I can't comment on the CMake foo, however. - Sebastian Kügler On June 18, 2015, 1:19 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/ --- (Updated June 18, 2015, 1:19 a.m.) Review request for Build System, KDE Frameworks, Matthew Dawson, and Harald Sitter. Repository: kconfig Description --- Separates the tooling that is supposed to be used at run-time so that we can specify which to use explicitly. Ideally this would be done automagically, for now we'll have to specify -DKF5ConfigCompiler_DIR=... Additionally, we should make kconfig_compiler co-installable by putting it in libexec, but I'd prefer to do that in a future patch. This same process should also happen on other frameworks. Diffs - CMakeLists.txt f510e3e KF5ConfigConfig.cmake.in b4e5f56 src/kconfig_compiler/CMakeLists.txt ec4a733 Diff: https://git.reviewboard.kde.org/r/124104/diff/ Testing --- Works as expected on my debian chroot environment. 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 124104: Make it possible to use kconfig_compiler from different sources
On June 15, 2015, 11:12 p.m., Matthew Dawson wrote: src/kconfig_compiler/CMakeLists.txt, line 16 https://git.reviewboard.kde.org/r/124104/diff/1/?file=380232#file380232line16 Does this mean a cross-compiled KConfig won't be built right for development on the target? If this happens regardless, is the cross compiling still possible? My CMake foo is weak, so if no one knows an alternative, I'm fine. I'd just prefer KConfig to work on the target for development too. Aleix Pol Gonzalez wrote: Well, the idea is that if you're cross-compiling, the generated executable won't work on the host architecture, by definition. In case it's needed, we could import an actual KF5ConfigCompilerConfig.cmake from the host architecture. In this case it doesn't really make sense though. What I meant is that a cross-compilied KConfig would be built in such a way that transporting it to its native environment would allow it to be used as a complete development environment (assuming all the development related files were copied). With this change, that doesn't work anymore. It's a corner case, and if it breaks this otherwise fine RR, I'm not worried. But it would be nice to have. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/#review81501 --- On June 17, 2015, 9:19 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/ --- (Updated June 17, 2015, 9:19 p.m.) Review request for Build System, KDE Frameworks, Matthew Dawson, and Harald Sitter. Repository: kconfig Description --- Separates the tooling that is supposed to be used at run-time so that we can specify which to use explicitly. Ideally this would be done automagically, for now we'll have to specify -DKF5ConfigCompiler_DIR=... Additionally, we should make kconfig_compiler co-installable by putting it in libexec, but I'd prefer to do that in a future patch. This same process should also happen on other frameworks. Diffs - CMakeLists.txt f510e3e KF5ConfigConfig.cmake.in b4e5f56 src/kconfig_compiler/CMakeLists.txt ec4a733 Diff: https://git.reviewboard.kde.org/r/124104/diff/ Testing --- Works as expected on my debian chroot environment. 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 124104: Make it possible to use kconfig_compiler from different sources
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/#review81545 --- Ship it! Ship It! - Harald Sitter On June 18, 2015, 1:19 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/ --- (Updated June 18, 2015, 1:19 a.m.) Review request for Build System, KDE Frameworks, Matthew Dawson, and Harald Sitter. Repository: kconfig Description --- Separates the tooling that is supposed to be used at run-time so that we can specify which to use explicitly. Ideally this would be done automagically, for now we'll have to specify -DKF5ConfigCompiler_DIR=... Additionally, we should make kconfig_compiler co-installable by putting it in libexec, but I'd prefer to do that in a future patch. This same process should also happen on other frameworks. Diffs - CMakeLists.txt f510e3e KF5ConfigConfig.cmake.in b4e5f56 src/kconfig_compiler/CMakeLists.txt ec4a733 Diff: https://git.reviewboard.kde.org/r/124104/diff/ Testing --- Works as expected on my debian chroot environment. 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 124104: Make it possible to use kconfig_compiler from different sources
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124104/ --- (Updated June 18, 2015, 3:19 a.m.) Review request for Build System, KDE Frameworks, Matthew Dawson, and Harald Sitter. Changes --- Simplify the approach, this way we can just specify KF5_HOST_TOOLING once, as a list. Repository: kconfig Description --- Separates the tooling that is supposed to be used at run-time so that we can specify which to use explicitly. Ideally this would be done automagically, for now we'll have to specify -DKF5ConfigCompiler_DIR=... Additionally, we should make kconfig_compiler co-installable by putting it in libexec, but I'd prefer to do that in a future patch. This same process should also happen on other frameworks. Diffs (updated) - CMakeLists.txt f510e3e KF5ConfigConfig.cmake.in b4e5f56 src/kconfig_compiler/CMakeLists.txt ec4a733 Diff: https://git.reviewboard.kde.org/r/124104/diff/ Testing --- Works as expected on my debian chroot environment. 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 124118: Make it possible to use KCoreAddons's desktoptojson in cross-compiled environments
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124118/#review81544 --- autotests/CMakeLists.txt (line 49) https://git.reviewboard.kde.org/r/124118/#comment55894 I have no experience with cross compiling, but shouldn't this be `if(NOT ...)` as now the test will only be compiled when crosscompiling? - Alex Richardson On June 18, 2015, 2:39 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124118/ --- (Updated June 18, 2015, 2:39 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Follows the lead of kconfig patch: https://git.reviewboard.kde.org/r/124104/ Diffs - CMakeLists.txt 552851d KF5CoreAddonsConfig.cmake.in caa1c0a autotests/CMakeLists.txt 51fcfb4 src/desktoptojson/CMakeLists.txt e6041cb Diff: https://git.reviewboard.kde.org/r/124118/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 124116: KPlotWidget: no need to setMinimumSize or resize.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124116/#review81542 --- Ship it! Ship It! - Christoph Feck On June 17, 2015, 3:01 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124116/ --- (Updated June 17, 2015, 3:01 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kplotting Description --- The minimumSizeHint() implementation (and the default size policy) already sets a minimum size. Let users of the class call setMinimumSize if they want to, and let Qt resize to the sizeHint() by default, that's what it's for. Diffs - src/kplotwidget.cpp 6122e2f0987998601ff6d0fd9437eb122c031839 Diff: https://git.reviewboard.kde.org/r/124116/diff/ Testing --- The example looks like it did before ;) In my app it works too. Next step: changing that minimum size hint to 100 for the height, there's no reason to require 150 pixels vertically for a small graph. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124118: Make it possible to use KCoreAddons's desktoptojson in cross-compiled environments
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124118/ --- (Updated June 18, 2015, 3:52 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Follows the lead of kconfig patch: https://git.reviewboard.kde.org/r/124104/ Diffs (updated) - CMakeLists.txt 552851d KF5CoreAddonsConfig.cmake.in caa1c0a autotests/CMakeLists.txt 51fcfb4 src/desktoptojson/CMakeLists.txt e6041cb Diff: https://git.reviewboard.kde.org/r/124118/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
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,All,clang - Build # 38 - Fixed!
We thank you for fixing your build!___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,All,clang - Build # 37 - Failure!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=All,compiler=clang/37/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Future frameworks releases
2015-06-16 12:54 GMT+03:00 Christian Mollekopf chrig...@fastmail.fm: On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote: 2015-06-11 21:20 GMT+03:00 Sebastian Kügler se...@kde.org: Introducing exceptions increases the complexity of dealing with frameworks, their value really is in shared processes and requirements. I am strongly against watering it down. If some library is better off with its own versioning scheme and release process, then it simply should not be part of our Frameworks releases, but something else (which is entirely possible, still). Hi everyone, I totally agree that we should leave the KF5 policies alone. KImap and other libraries can easily be part of something else - a new product to aggregate disparate libraries based on Qt5/KF5. I was thinking of naming it Lamedorks 5.x, but Albert will kill me for such a name, so backing off to KDE Vinegret 5.x ;) Suggested policies for KDE Vinegret: 1. License, coding style and base technologies used: same as for KF5 (LGPL2+/KDE, KDELibs coding style, Qt5/KF5 partial C++11), 2. Release cycle: same as for KF5 (released once a month, but may not include some of the libraries - see entry 3 below; message freeze starts 2 weeks before a scheduled release.) 2a. It might be best to release KV5 on a same day with KF5. 3. Releases are automated with scripts and done in the same way as for KF5 (always releasing from master, each library has it own tarball.) 4. Maintainer of each library can decide whether to do a release or skip it for a given month. 5. Version number can be either automatically bumped or configurable manually in a text file. 6. Dependencies' version numbers are never bumped, even for dependencies on KF5. 7. SOVERSION is always taken care of by the library maintainer. 8. Tarball file names follow library version numbers, e.g. kimap-2.3.0.tar.xz. The KV5 releases should not necessarily have same version numbers as KF5, it can be for example KDE Vinegret 5/2015-07. I think it's even better than KDE Vinegret 5.12 because this way no one will expect it to contain kimap-5.12.0.tar.xz. So KV5 will be around only to simplify releasing of a huge number of libraries. In the above I mentioned that releasing of each library should be optional and version numbers be configurable. Here is a possible approach to defining this in metadata.yaml (or a similar config in a library's Git repo): (a). If versionMapping is defined, then it is a dictionary that maps from KV5 release numbers to library version numbers, for example: versionMapping: 5/2015-07: 2.2.1 5/2015-08: none 5/2015-09: 2.3.0 In this case the release scripts will bump the version in CMakeLists.txt to 2.2.1 for the July release and will tarball the library as kimap-2.2.1.tar.xz. KImap will not be included in the August release, there will be only a reference to the latest released version (kimap-2.2.1) in the release notes for KV5/2015-08. In September, the release scripts will bump the library version to 2.3.0 and create a new tarball again. (b). If versionMapping is not defined in metadata.yaml, then the library maintainer is happy with automated version bumping releasing each month. Because 5/2015-08 is not a nice version number for a library, we should probably default to so predefined mapping like this: 5/2015-07: 5.12.0 5/2015-08: 5.13.0 5/2015-09: 5.14.0 If versionMapping is already present, no one updates metadata.yaml on time and thus it misses information about the version number for a coming KV5 release, then this library will not be released (same as if there was a 5/2015-xx: none line). KV5 is not going to be a solution for one person or one use case, because many other libraries were about to join KF5 while they don't really need to in my opinion. For example the following libraries can probably join the new product: - kimap and other libs extracted from kdepimlibs, - kproperty, kreport and libs extracted from Calligra, - libqapt, - libqgit2, - libkipi, libkgeomap, libkvkontakte and other libs used mainly by the digiKam project. The idea of a new product came to my mind before I actually started spending hours reading these exhausting threads, and while reading I did not see any major problems that this new product could not solve. If you see any bottleneck with it, your comments are very welcome. This describes nicely what I think frameworks should become (I like the version bumping concept I discussed with David in the initial thread better, but details aside this is spot on). I think however it would be a bad idea to create a second set of libraries next to frameworks, because that would IMO defeat the purpose of frameworks. If frameworks is a collection of high quality kde/qt libraries, it shouldn't have a competitor that does essentially the same thing just without the versioning policy. This
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 --- I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :( - David Faure On June 11, 2015, 4:16 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 11, 2015, 4:16 a.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124101: Reenable support for KDateTime streaming to kDebug/qDebug, for more SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124101/ --- (Updated June 17, 2015, 10:42 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit bcad4105178086b09c6b80014377fc79fdf558b2 by Friedrich W. H. Kossebau to branch master. Repository: kdelibs4support Description --- When porting code to KF5 while using kdelibs4support, `kDebug() someKDateTimeObject;` will not build. Because for some undocumented reason (at least in current repo, did not investigate further) `QDebug operator(QDebug s, const KDateTime time);` had been disabled. I could not see any problems after reenabling it again. So would propose to do it for everyone, to make kdelibs4support a tiny bit more source-compatible for kdelibs4-using code :) Diffs - src/kdecore/kdebug.h ff7607f src/kdecore/kdebug.cpp 2705ec9 Diff: https://git.reviewboard.kde.org/r/124101/diff/ Testing --- Thanks, Friedrich W. H. Kossebau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: kdelibs4support master kf5-qt5 » OSX,clang - Build # 14 - Failure!
Check console output at https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/14/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124101: Reenable support for KDateTime streaming to kDebug/qDebug, for more SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124101/#review81521 --- Ship it! Yes. I think it was disabled while moving stuff around into different repos, at some point kdebug must have moved before kdatetime. - David Faure On June 15, 2015, 11:01 a.m., Friedrich W. H. Kossebau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124101/ --- (Updated June 15, 2015, 11:01 a.m.) Review request for KDE Frameworks. Repository: kdelibs4support Description --- When porting code to KF5 while using kdelibs4support, `kDebug() someKDateTimeObject;` will not build. Because for some undocumented reason (at least in current repo, did not investigate further) `QDebug operator(QDebug s, const KDateTime time);` had been disabled. I could not see any problems after reenabling it again. So would propose to do it for everyone, to make kdelibs4support a tiny bit more source-compatible for kdelibs4-using code :) Diffs - src/kdecore/kdebug.h ff7607f src/kdecore/kdebug.cpp 2705ec9 Diff: https://git.reviewboard.kde.org/r/124101/diff/ Testing --- Thanks, Friedrich W. H. Kossebau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
On June 17, 2015, 8:24 a.m., David Faure wrote: I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :( Possibly we should let desktopfileparser read a servicetype file? Was also suggested here: https://git.reviewboard.kde.org/r/121672/ - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 --- On June 11, 2015, 5:16 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 11, 2015, 5:16 a.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,All,clang - Build # 33 - Failure!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=All,compiler=clang/33/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » OSX,NoX11,clang - Build # 33 - Failure!
Check console output at https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=OSX,Variation=NoX11,compiler=clang/33/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124116: KPlotWidget: no need to setMinimumSize or resize.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124116/ --- Review request for KDE Frameworks and Christoph Feck. Repository: kplotting Description --- The minimumSizeHint() implementation (and the default size policy) already sets a minimum size. Let users of the class call setMinimumSize if they want to, and let Qt resize to the sizeHint() by default, that's what it's for. Diffs - src/kplotwidget.cpp 6122e2f0987998601ff6d0fd9437eb122c031839 Diff: https://git.reviewboard.kde.org/r/124116/diff/ Testing --- The example looks like it did before ;) In my app it works too. Next step: changing that minimum size hint to 100 for the height, there's no reason to require 150 pixels vertically for a small graph. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124066: Recognize X-KDE-FormFactor as stringlist
On June 17, 2015, 7:24 a.m., David Faure wrote: I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :( Alex Richardson wrote: Possibly we should let desktopfileparser read a servicetype file? Was also suggested here: https://git.reviewboard.kde.org/r/121672/ So it has to look in standardpaths and somewhere in the buildpath for a service file, then use that to generate the json file? I guess the servicefile could be fairly simple, as it just has to note unknown key/type combinations. The KDE4-style service files do have that information, and as long as we don't have to parse that at runtime, we should be fine. On the other hand, we'll get build-time dependencies on these servicetype files, as it's now not good enough anymore to install them at some point, the resulting json information is going to differ then. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 --- On June 11, 2015, 4:16 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/ --- (Updated June 11, 2015, 4:16 a.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kcoreaddons Description --- This patch adds X-KDE-FormFactor to the keys recognized as stringlists. We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device. The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the host application filters based on these. If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need. The naming of the key is of course open to better suggestions. Diffs - autotests/data/fakeplugin.desktop 95152f6 autotests/kpluginmetadatatest.cpp 231ac36 src/lib/plugin/desktopfileparser.cpp b19da6b Diff: https://git.reviewboard.kde.org/r/124066/diff/ Testing --- added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm. Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
