Re: Submitting KTextTemplate for KF6
On 05/03/2022 18:16, Ben Cooksley wrote: On Sun, Mar 6, 2022 at 6:00 AM Stephen Kelly wrote: On 26/02/2022 10:38, Volker Krause wrote: > On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote: >> Hello, >> >> The Qt 5 based Grantlee libraries were depended on by some KDE applications. >> >> For Qt 6, I've created a separate repo for KTextTemplate for one of the >> Grantlee libraries. The other library is separate and can be dealt with >> separately. >> >> Currently the code lives here: >> >> https://github.com/steveire/ktexttemplate >> >> I'd like to get the process moving on getting this reviewed and into KF6. >> >> It's not clear to me what the next step is. I tried googling terms like >> "how to submit a library to kde frameworks", but didn't find anything >> useful. >> >> https://techbase.kde.org/KDE_Frameworks describes how to build >> frameworks, but not how to submit a new one. >> >> I've checked and I can still use invent.kde.org <http://invent.kde.org>, so it would be good if >> there is a standard process I can follow for the rest. > I don't think the process of integrating a so far external project into > Frameworks happened often enough for this to be documented as a streamlined > process. I'd suggest the following steps: > > (1) Import the repo into invent.kde.org <http://invent.kde.org> > (2) Go through the KDE Review process > (3) Request inclusion into Frameworks > > Happy to see this moving :) Ok. I was thinking there might be some 'review' area of invent.k.o, but I've just made https://invent.kde.org/skelly/ktexttemplate Does that satisfy (1)? It starts the process yes. I think there are changes like CamelCase headers to conform to KF6 norms. I'm not sure if others can help with that now. Can any KDE account push to the above repo? No, only you are able to push to that repository, but people can send you merge requests. To give people access to the repository you can either: a) Invite the teams/kde-developers group to the repository as a 'Developer' which will grant access to it; or I've done this part now. I thought I started the KDE Review process when I sent the original email here, but without a written-down process I'm not certain. Maybe things can be moved along now? Thanks, Stephen.
Re: Submitting KTextTemplate for KF6
On 26/02/2022 10:38, Volker Krause wrote: On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote: Hello, The Qt 5 based Grantlee libraries were depended on by some KDE applications. For Qt 6, I've created a separate repo for KTextTemplate for one of the Grantlee libraries. The other library is separate and can be dealt with separately. Currently the code lives here: https://github.com/steveire/ktexttemplate I'd like to get the process moving on getting this reviewed and into KF6. It's not clear to me what the next step is. I tried googling terms like "how to submit a library to kde frameworks", but didn't find anything useful. https://techbase.kde.org/KDE_Frameworks describes how to build frameworks, but not how to submit a new one. I've checked and I can still use invent.kde.org, so it would be good if there is a standard process I can follow for the rest. I don't think the process of integrating a so far external project into Frameworks happened often enough for this to be documented as a streamlined process. I'd suggest the following steps: (1) Import the repo into invent.kde.org (2) Go through the KDE Review process (3) Request inclusion into Frameworks Happy to see this moving :) Ok. I was thinking there might be some 'review' area of invent.k.o, but I've just made https://invent.kde.org/skelly/ktexttemplate Does that satisfy (1)? I think there are changes like CamelCase headers to conform to KF6 norms. I'm not sure if others can help with that now. Can any KDE account push to the above repo? Thanks, Stephen.
Submitting KTextTemplate for KF6
Hello, The Qt 5 based Grantlee libraries were depended on by some KDE applications. For Qt 6, I've created a separate repo for KTextTemplate for one of the Grantlee libraries. The other library is separate and can be dealt with separately. Currently the code lives here: https://github.com/steveire/ktexttemplate I'd like to get the process moving on getting this reviewed and into KF6. It's not clear to me what the next step is. I tried googling terms like "how to submit a library to kde frameworks", but didn't find anything useful. https://techbase.kde.org/KDE_Frameworks describes how to build frameworks, but not how to submit a new one. I've checked and I can still use invent.kde.org, so it would be good if there is a standard process I can follow for the rest. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 30/12/2019 10:55, Christoph Cullmann wrote: Hi, With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? QTextDocument is exactly what it's about, which makes the name KF6::TextDocument fully appropriate and correct. Before starting this work, let's clarify whether we can find a more unique name (like KF6:GrantleeTextDocument). The name I suggest is already correct. Since I haven't used Grantlee yet, I sm likely not the best person to find a better name ;) Remember, Grantlee is a set of Frameworks (*Just like KF5/6*) which happens to contain just TWO independent libraries. Hmm, I am not that sure about that naming. Let's discuss it in the future (when KF6 is open) when everyone participating in the discussion can know what is being discussed. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 30/12/2019 08:55, Dominik Haumann wrote: Hi, Stephen Kelly mailto:steve...@gmail.com>> schrieb am So., 29. Dez. 2019, 15:03: On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: > Why are you proposing to do a step back instead to the old state, which > everyone including you considered not that satisfying? Because it's a temporary situation. We still have a way forward in KF6 (which will open in a few months). Generally, getting Grantlee into KF5 now also establishes the wrong precedent. Grantlee should be split into two repos each with a tier 1 library (KF6::TextDocument and KF6::TextTemplate). The two are independent and have nothing to do with each other aside from authorship. That seems to be something you were objecting to, so I want to make sure that's something addressed on its own. The two KF6 libraries will then follow the KF6 naming conventions etc. With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? QTextDocument is exactly what it's about, which makes the name KF6::TextDocument fully appropriate and correct. Before starting this work, let's clarify whether we can find a more unique name (like KF6:GrantleeTextDocument). The name I suggest is already correct. Since I haven't used Grantlee yet, I sm likely not the best person to find a better name ;) Remember, Grantlee is a set of Frameworks (*Just like KF5/6*) which happens to contain just TWO independent libraries. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: Why are you proposing to do a step back instead to the old state, which everyone including you considered not that satisfying? Because it's a temporary situation. We still have a way forward in KF6 (which will open in a few months). Generally, getting Grantlee into KF5 now also establishes the wrong precedent. Grantlee should be split into two repos each with a tier 1 library (KF6::TextDocument and KF6::TextTemplate). The two are independent and have nothing to do with each other aside from authorship. That seems to be something you were objecting to, so I want to make sure that's something addressed on its own. The two KF6 libraries will then follow the KF6 naming conventions etc. I hope my personal objections raised about it becoming an official KF module already now have not arrived with you as objection in general. Not at all. I agree that the two libraries should be consistent with the rest of the Frameworks. On the opposite, I agree with the ideas behind this move. I have just strict feeling about KF as a product itself when it comes to consumer as well as cross-module ontributor experience. So please be aware that I would be sad if you decided to have Grantlee go back to lonely cowboy mode :) Only temporarily :). Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 22/12/2019 16:08, Stephen Kelly wrote: On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: Perhaps joining the "Release Service" (formerly known as "KDE Applications") is a better place then, it also contains a set of libraries already. That would serve the purpose of having releases happening regularly. The goals of making Grantlee a Framework are: * Make more frequent releases which don't depend on me * Make it more easy for others to contribute to development I think at the point that renaming happens, the name Grantlee will disappear, and we'll have two libraries (KF5::TextDocument and KF5::TextTemplates or so in CMake and probably removing the C++ namespace). I think all of that should be done together and I don't think that should be done until compatibility is broken to become Qt6-based (KF6). My conclusion from reading this thread is that this is the way forward: * Grantlee does not become a KF5 framework. I'll continue to make releases from github if needed based on Qt 5. We can consider re-evaluating that in the future. * For KF6, I will submit two separate Tier 1 frameworks, in two different repos, what I here called ktextdocument/KF6::TextDocument and ktexttemplate/KF6::TextTemplate The two libraries are independent. Having them in the same KF* repo doesn't make sense. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: Perhaps joining the "Release Service" (formerly known as "KDE Applications") is a better place then, it also contains a set of libraries already. That would serve the purpose of having releases happening regularly. The goals of making Grantlee a Framework are: * Make more frequent releases which don't depend on me * Make it more easy for others to contribute to development I think at the point that renaming happens, the name Grantlee will disappear, and we'll have two libraries (KF5::TextDocument and KF5::TextTemplates or so in CMake and probably removing the C++ namespace). I think all of that should be done together and I don't think that should be done until compatibility is broken to become Qt6-based (KF6). If joining the Release Service helps reach the goals, and there is consensus that Grantlee can't be a framework without partial renaming (ie renaming the CMake interface but little else) in KF5, then that might be the way to go. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote: Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly: Great, Grantlee is now available at g...@git.kde.org:grantlee.git. I've pushed a few commits to make it depend on ECM etc. Once the review period is finished it can be part of KF5 releases. There are quite some things which yet need to be done for now: to be a true KF module there is a set of policies which needs to be met, see https://community.kde.org/Frameworks/Policies 1) Framework directory structure: moving stuff into src/, autotests/ & docs/ 2) Framework documentation: current system needs adaption to both online (KApiDox) and offline (ECMAddQCH) systems Cool, I wonder if there's another multi-library framework for comparison? Another challenge would be moving into the KF5 namespace for the library artifacts (at least I would expect/recommend this to happen, for consistent user experience) a) include dirs below subdir KF5/ b) CMake modules with KF5 prefix c) CMake imported target in KF5 namespace I don't support changing things like this in the KF5 timeframe. Now, the question is if we want Grantlee to be backwards-compatible after the move into KDE Frameworks, or if some breakage is possible? When it comes to CMake targets & modules, the first challenge is: Grantlee5 supports components, "Templates" & "TextDocument". To allow people doing e.g. --- 8< --- find_package(Grantlee5 CONFIG COMPONENTS Templates) --- 8< --- So when Grantlee becomes a component in KF5 itself, so people would use for finding it --- 8< --- find_package(KF5 CONFIG COMPONENTS Grantlee) --- 8< --- these two, "Templates" & "TextDocument", would need to become subcomponents. Which though is a concept CMake does not support. So what to do here? Split Grantlee into two separate libs, with separate CMake config files? Done by KF5NewStuff, where one repo provides 2 separate configs. Or just merge and do not allow making dep chain more narrow (Grantlee's TextDocument pulls in QtGui as dep, so fails if no devel package not present)? Then Grantlee's CMake module brings two namespaced imported targets: * Grantlee5::Templates * Grantlee5::TextDocument With Grantlee being part of KDE Frameworks, one would expect to have targets named like * KF5::GrantleeTemplates * KF5::GrantleeTextDocument or similar. I'm fine with any of this kind of stuff in the KF6 timeframe. Just, seems CMake does not expect the use case of exporting targets with different names, there is only one property available to set the base name, cmp. current --- 8< --- set_property(TARGET Grantlee_Templates PROPERTY EXPORT_NAME Templates) --- 8< --- So when wanting to keep backward compatibility, we are stuck here with the old basenames. Do you know any simple trick to have a separate CMake config file with separate imported targets, which still refer to the same library executable? Never done myself, so no idea what could be done. Doing a separate target and exporting that one will fail possibly once trying to set OUTPUT_NAME property to the same, Perhaps one could do a manual cmake config file which has the old one as find_dependency and then defines an alias target on the imported target? I don't think any of this matters in the KF6 timeframe. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 21/12/2019 21:33, Volker Krause wrote: * Attracting external components and having them opt to move under the Frameworks umbrella is a sign that we are doing things right IMHO. So let's make this easy for people and avoid scaring off their users by forcing a larger migration on them when joining Frameworks. I definitely want to keep things as they are. Grantlee has lots of users. The mutual advantages of making Grantlee a KF5 Framework without changing how it's used in CMake (aside from a few minor details like the fact of the ECM dependency) are what makes KF5 attractive. * We are less than two years away from KF6, a time where people expect to have to do a larger migration anyway. Deferring some of the necessary changes to then might be a compromise that works for now. This seems like the right way to me. Let's make the fundamental changes for KF6. The timing of KF6 and the introduction of Grantlee to KF5 are favorable to that. Another option is to skip KF5 and make Grantlee a KF6 frameworks whenever that opens. Thoughts? Thanks, Volker PS: @Steve: I missed the doxygen discussion on IRC earlier, customizing doxygen is possible via docs/Doxyfile.local, which just gets appended to the Doxyfile from kapidox IIUC, maybe that helps already? Cool, I'll look into it. Thanks, Stephen.
Re: Submitting Grantlee as a KF5 Framework
On 08/12/2019 10:12, laurent Montel wrote: Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit : Hi, very happy to see Grantlee "coming home" :) Technically I think it's largely in line with Frameworks requirements already, and it has been reliably powering e.g. KMail's message viewer for years. Moving to a faster and, more importantly, predictable release cycle would help us a lot with upstreaming extensions and improvements though, and would allow us to get rid of some repeated code in applications. Indeed same for kaddressbook/knotes/akregator :) Longer term I'd also hope we can add the support for QtGui types (icons, colors, palettes, etc) that is currently spread around application code, either as a plugin in the Grantlee repo directly, or as a tier 2 framework on top. So, definitely a +1 from me! +1 for me too Great, Grantlee is now available at g...@git.kde.org:grantlee.git. I've pushed a few commits to make it depend on ECM etc. Once the review period is finished it can be part of KF5 releases. Thanks, Stephen.
Submitting Grantlee as a KF5 Framework
Hello, I have been developing Grantlee for over 10 years with contributions from a community of others mostly connected with KDE. https://github.com/steveire/grantlee I have not been able to maintain a reasonable release cadence of Grantlee in the last few years (last release 3 years ago), so I'm submitting Grantlee to KDE Review with the aim of addition to KDE Frameworks. Grantlee consists of two libraries, * Grantlee::Templates is a text-template system based on Qt introspection * Grantlee::TextDocument is a builder design pattern implementation for processing QTextDocuments Grantlee is already a dependency of several KDE applications, but it is treated as an external dependency. This change would make it a Tier 1 KDE Framework. $ apt-cache rdepends libgrantlee-templates5 libgrantlee-templates5 Reverse Depends: libgrantlee5-dev skrooge rocs libkf5pimcommon5abi3 libkf5messageviewer5abi5 libkf5messageviewer-plugins libkf5kaddressbookgrantlee5 libkf5grantleetheme5 libkf5grantleetheme-plugins libkf5calendarutils5abi1 libkf5calendarutils-bin kdepim-addons kjots khelpcenter kdevelop52-libs kdevelop $ apt-cache rdepends libgrantlee-textdocument5 libgrantlee-textdocument5 Reverse Depends: libgrantlee5-dev libkf5pimtextedit5abi3 libkf5messageviewer5abi5 libkf5messagecomposer5abi2 kjots My intention is to make one more release of Grantlee myself before turning it into a KDE Frameworks repository. I don't think much needs to change in terms of the C++ code. The namespace would remain Grantlee:: etc, so that releases made from KDE Frameworks will be binary compatible with previous Grantlee5 releases. However, I've not been putting time into making releases (The last release was over 3 years ago). This is a proposal to submit Grantlee as a KF5 repository. It should be a natural addition to the KF5 ecosystem. This move will mean: * Grantlee will be released regularly as part of KF5 * All KDE contributors will have the commit bit to make changes * My guilt about lack of releases will be reduced Grantlee::Templates depends on QtQml for script bindings (can be disabled at build time). Grantlee::TextDocument depends only on QtGui. I'm not quite familiar with what needs to happen to complete this transition. It seems to me that something along these lines ought to do it: * I make one last release of Grantlee myself * Set up a new KDE repository for me to push to * Integrate KF5 buildsystem into Grantlee (ECM for example) * Set up CI for that repository * Set up doxygen generation for the repository * Transfer grantlee.org to KDE sysadmin Grantlee already has ki18n integration in the form of a library implementing Grantlee abstractions: https://cgit.kde.org/grantleetheme.git/about/ Initial reviews and comments welcome! Thanks, Stephen.
Re: [Kde-bindings] A new attempt on PyKDE5 binding generation
Albert Astals Cid wrote: > El divendres, 8 d’abril de 2016, a les 0:29:57 CEST, Stephen Kelly va > escriure: >> Albert Astals Cid wrote: >> > So my suggestion would be renaming pykde5.git to pykf5.git, and that >> > means *only* KDE Frameworks 5 bindings would go in there, any other >> > repo that wants to provide python bindings (say okular, marble or >> > krita) should do somewhere else, ideally their own repo so the binding >> > and the original code are close together and it's easier to keep in >> > sync when api changes. >> >> FYI, this issue came up recently in the context of bindings to another >> language (QML): >> >> http://thread.gmane.org/gmane.comp.kde.devel.frameworks/30734/focus=30770 >> >> I'm not very familiar with python bindings generally. Would it be >> practical to put the bindings in the same repo as the library they relate >> to? > > See the answer he made to one of my previous emails, in short no. Ah, yes. I see that this exact issue was discussed already. I wasn't reading closely enough when catching up on this thread, so sorry for that. However, the answer doesn't seem to shorten to 'no' to me. A CMake macro can be put in extra-cmake-modules, and the tools for binding generation can be put 'somewhere' which doesn't constitute a 'part of the tiers' in the same way that ECM is not 'part of the tiers' for the purpose of deciding 'what is tier 1'. If there's no packaging-related reason to avoid that approach, I wonder if we can discuss it. Thanks, Steve.
Re: [Kde-bindings] A new attempt on PyKDE5 binding generation
Albert Astals Cid wrote: > So my suggestion would be renaming pykde5.git to pykf5.git, and that means > *only* KDE Frameworks 5 bindings would go in there, any other repo that > wants to provide python bindings (say okular, marble or krita) should do > somewhere else, ideally their own repo so the binding and the original > code are close together and it's easier to keep in sync when api changes. FYI, this issue came up recently in the context of bindings to another language (QML): http://thread.gmane.org/gmane.comp.kde.devel.frameworks/30734/focus=30770 I'm not very familiar with python bindings generally. Would it be practical to put the bindings in the same repo as the library they relate to? Thanks, Steve.
Re: Fwd: Required VS compiler
Dominik Haumann wrote:
> I still see QStringLiteral fixes from time to time on the commit
> mailing list. Given MSVC 2015 Community Edition is available
> just like v2013, and it seems to work I believe that committing
> such fixes does not make sense, in fact, it often makes code
> worse.
If the QStringLiteral fixes you are referring to are changing eg
QStringLiteral("foo" "bar")
I too noticed MSVC 2015 handles that fine while investigating
https://llvm.org/bugs/show_bug.cgi?id=26980
Thanks,
Steve.
Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement
On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote: This patch is not correct. What repo were you trying to build? Add cmake_minimum_required(VERSION 2.8.9) there. Stephen Kelly wrote: Why did this review go quiet? Did you pull and realize that line was already there in whatever repo you're looking at? René J.V. Bertin wrote: What, my 2 replies below aren't sufficient? :) If you missed them, that'd probably support of my idea that most KDE devs are focussed away from flogging dead horses (i.e., KDE4 code, to quote one of those devs, a rather visible one I won't name). No, I didn't pull whatever repo after pulling the 4.14 branch head of one of the KDE PIM components and bumping into this error. Luigi Toscano wrote: David Faure, durink Akademy, was rebuilding the last kdelibs4 branch for most applications, I think to ensure that the changes in the default cmake policy did not break them. He did various fixes, so I think that fixing this in the proper way (which I can't help to, sorry) would be good. René J.V. Bertin wrote: And he did a good job *on Linux* to the extent that I haven't been able to trigger the issue on my Linux rig (Kubuntu 14.04.3LTS with cmake 3.0.1). Which is why my patch is Mac-specific. But frankly, I don't see the point in obliging each and every dependent project to declare the minimum required cmake version. Not if that's not a requirement of cmake itself, nor of the project, but of one of the libraries it uses. I really don't see how this is different from, say, declaring CMake macros that are specific to KDE and not to a given dependent project. On the contrary, it seems clear that the version requirement stems from something done in (or included by) a cmake file that's installed through kdelibs. In my book that makes it kdelibs' responsibility to declare the minimum required version. If it's not yet set, and/or as long as subsequent calls to `cmake_minimum_required` do not override (= downgrade) minimum versions set by preceding calls. That said, I'm going to have to get back to my Mac to verify why I apparently missed kdepim commit 8a187bc316271caed9c2591d91fb8706abe5c665 (Fix the build after yet another cmake policy change) or what else is going on. Not if that's not a requirement of cmake itself It is a requirement of cmake itself, and it has been for 6 years. - Stephen --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/#review84062 --- On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/ --- (Updated Aug. 19, 2015, 5:41 p.m.) Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- The recent removal of the code block from FindKDE4Internal.cmake starting with the `cmake_minimum_required` statement breaks configuring on OS X: ``` -- The C compiler identification is AppleClang 6.0.0.657 -- The CXX compiler identification is AppleClang 6.0.0.657 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA -- Looking for QT_MAC_USE_COCOA - found -- Found Qt-Version 4.8.7 (using /opt/local/libexec/qt4/bin/qmake) -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - found -- Found Threads: TRUE CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:112 (elseif): given arguments: VERSION_LESS 3.1
Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement
On Aug. 19, 2015, 6:03 p.m., Jeremy Whiting wrote: Ship It! Don't ship it :). - Stephen --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/#review84061 --- On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/ --- (Updated Aug. 19, 2015, 5:41 p.m.) Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- The recent removal of the code block from FindKDE4Internal.cmake starting with the `cmake_minimum_required` statement breaks configuring on OS X: ``` -- The C compiler identification is AppleClang 6.0.0.657 -- The CXX compiler identification is AppleClang 6.0.0.657 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA -- Looking for QT_MAC_USE_COCOA - found -- Found Qt-Version 4.8.7 (using /opt/local/libexec/qt4/bin/qmake) -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - found -- Found Threads: TRUE CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:112 (elseif): given arguments: VERSION_LESS 3.1 Unknown arguments specified Call Stack (most recent call first): /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:501 (_pkgconfig_parse_options) /opt/local/share/cmake-3.2/Modules/FindOpenSSL.cmake:43 (pkg_check_modules) /opt/local/share/apps/cmake/modules/Qt4ConfigDependentSettings.cmake:224 (FIND_PACKAGE) /opt/local/share/apps/cmake/modules/FindQt4.cmake:1207 (INCLUDE) /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:425 (find_package) /opt/local/share/cmake-3.2/Modules/FindKDE4.cmake:108 (find_package) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! ``` The attached patch is the minimum reintroduction of the removed code that allows the cmake procedure to conclude successfully. CMake experts might be aware of other ways to address this issue more in line with the reason the block was removed. Diffs - cmake/modules/FindKDE4Internal.cmake 7d54b9b Diff: https://git.reviewboard.kde.org/r/124824/diff/ Testing --- On OS X 10.9.5 with KDELibs 4.14.11 (v4.14.10-20-g150d983) and CMake 3.2.2 . The unmodified code from v4.14.10-20-g150d983 is fine on Linux with cmake 3.0.1 . Thanks, René J.V. Bertin
Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/#review84062 --- This patch is not correct. What repo were you trying to build? Add cmake_minimum_required(VERSION 2.8.9) there. - Stephen Kelly On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/ --- (Updated Aug. 19, 2015, 5:41 p.m.) Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- The recent removal of the code block from FindKDE4Internal.cmake starting with the `cmake_minimum_required` statement breaks configuring on OS X: ``` -- The C compiler identification is AppleClang 6.0.0.657 -- The CXX compiler identification is AppleClang 6.0.0.657 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA -- Looking for QT_MAC_USE_COCOA - found -- Found Qt-Version 4.8.7 (using /opt/local/libexec/qt4/bin/qmake) -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - found -- Found Threads: TRUE CMake Error at /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:112 (elseif): given arguments: VERSION_LESS 3.1 Unknown arguments specified Call Stack (most recent call first): /opt/local/share/cmake-3.2/Modules/FindPkgConfig.cmake:501 (_pkgconfig_parse_options) /opt/local/share/cmake-3.2/Modules/FindOpenSSL.cmake:43 (pkg_check_modules) /opt/local/share/apps/cmake/modules/Qt4ConfigDependentSettings.cmake:224 (FIND_PACKAGE) /opt/local/share/apps/cmake/modules/FindQt4.cmake:1207 (INCLUDE) /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:425 (find_package) /opt/local/share/cmake-3.2/Modules/FindKDE4.cmake:108 (find_package) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! ``` The attached patch is the minimum reintroduction of the removed code that allows the cmake procedure to conclude successfully. CMake experts might be aware of other ways to address this issue more in line with the reason the block was removed. Diffs - cmake/modules/FindKDE4Internal.cmake 7d54b9b Diff: https://git.reviewboard.kde.org/r/124824/diff/ Testing --- On OS X 10.9.5 with KDELibs 4.14.11 (v4.14.10-20-g150d983) and CMake 3.2.2 . The unmodified code from v4.14.10-20-g150d983 is fine on Linux with cmake 3.0.1 . Thanks, René J.V. Bertin
Re: Distros and QtWebEngine
Lisandro Damián Nicanor Pérez Meyer wrote: Fair enough. One of them starts in [0], but there was another thread in which even Lars participated. So far I haven't been able to find it, I'll keep trying. Found the other one! FYI, if you provide a gmane link, you provide the whole thread: http://thread.gmane.org/gmane.comp.lib.qt.devel/19929/focus=2 Thanks, Steve.
Re: Syncing ECM release number with KF5
I have no particular objection, So, what needs to be done to get this synced up? Bump the version in the CMakeLists.txt and update some release-tarball-creating script? David I guess the latter is for you? Thanks, Steve. On Fri, Mar 27, 2015 at 7:49 PM, Michael Palimaka kensing...@gentoo.org wrote: On 28/03/15 03:48, Alex Merry wrote: On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote: Hello, ECM release numbers are in sync with KF5 release numbers, except for the major component. This means that if you want to build the 5.x.y release you have to download the 1.x.y release of ECM. That doubles the complexity of your script which downloads the tarball to build it. That is bad and it is not necessary. Let's sync the major number for the next release. At some point the reason to make them out of sync was to be able to make ECM releases more frequently. That is very rare because KF5 releases are happening every month. If ECM needs to make an out of band release, it can use the 4th version number component. I have no particular objection, although I think doubling the complexity of scripts is overstating things a little. Alex Is ECM actually part of KF5, or just happens to be released alongside it? (I thought the latter, hence the different version). FWIW the different version doesn't bother me at all as a downstream.
Re: Gitorious going offline
On 03/16/2015 05:28 PM, Ivan Čukić wrote: From www.gitorious.org System notice: Gitorious is being acquired by GitLab and gitorious.org will shut down end of May. Please import your repositories to We still have a few projects on there. One notable being Grantlee (at least, my kdesrc-build looks for it over there). I guess this should be dealt with sooner than later. :) I've pushed Grantlee to github: https://github.com/steveire/grantlee Please update your scripts. Thanks, Steve.
Re: Gitorious going offline
On 03/16/2015 05:28 PM, Ivan Čukić wrote: From www.gitorious.org System notice: Gitorious is being acquired by GitLab and gitorious.org will shut down end of May. Please import your repositories to We still have a few projects on there. One notable being Grantlee (at least, my kdesrc-build looks for it over there). I guess this should be dealt with sooner than later. :) And thanks for being on-top of this :).
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
Harald Sitter wrote: xnox was nice enough to look into this in detail and identified the problem as having a much smaller scope than I had originally thought. 1) What is the problem? 2) Why does the package creation result in broken cmake files generated from the Qt tarball? Thanks, Steve.
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote: 2) Why does the package creation result in broken cmake files generated from the Qt tarball? The package creation does not result in broken cmake files generated from the Qt tarball. Great. It's just there is no clean way to override some of the chosen (hardcoded at Qt buildtime) paths, instead of at buildtime against multiple, possibly partial, stacks of Qts. I can think of several questions to ask/things to point out in response to this, but as you answered my above question already, I think I'll step back out of the thread instead. Thanks, Steve.
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote: I am also not sure yet, if a cross-moc is required or whether a native moc binary can be re-used. It's one of the open questions that I still have, and need to investigate the actual code generator / code generated. Even if the code generated is 'portable' today, there is no guarantee it will remain so. The appropriate action for you to take, therefore, is not to read the code, but to discuss it/the problem you are trying to solve on the mailing list. Thanks, Steve.
Re: Less time for KDE... :-)
Alexander Neundorf wrote: Hi, for very happy personal reasons (since Tuesday, named David :-) ) Awesome, congratulations! Steve.
Re: Review Request 113503: make dbus dependency optional in JobWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/#review42744 --- tier2/kjobwidgets/CMakeLists.txt http://git.reviewboard.kde.org/r/113503/#comment30900 You don't need COMPONENTS here. I'm not sure about whether it's needed in the next line. tier2/kjobwidgets/CMakeLists.txt http://git.reviewboard.kde.org/r/113503/#comment30901 You probably want if (Qt5DBus_FOUND) ? I think that the target is only created if it is found, but I can't be sure. A Config file can set its _FOUND variable to false if a necessary condition is not met (eg a file missing which should be packaged like a macros file - See the Qt config files for more.) tier2/kjobwidgets/src/CMakeLists.txt http://git.reviewboard.kde.org/r/113503/#comment30902 Ditto. Indentation. tier2/kjobwidgets/src/CMakeLists.txt http://git.reviewboard.kde.org/r/113503/#comment30903 Use PRIVATE, not LINK_PRIVATE (new in 2.8.12). Indentation and extra newline. tier2/kjobwidgets/src/CMakeLists.txt http://git.reviewboard.kde.org/r/113503/#comment30904 Indent. - Stephen Kelly On Oct. 30, 2013, 10:08 a.m., Sune Vuorela wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/ --- (Updated Oct. 30, 2013, 10:08 a.m.) Review request for KDE Frameworks, kdelibs and Stephen Kelly. Repository: kdelibs Description --- Make dbus dependency optional in JobWidgets Many don't have dbus available on all platforms, especially windows, but JobWidgets is very much useful without it. Diffs - tier2/kjobwidgets/CMakeLists.txt ca53024 tier2/kjobwidgets/src/CMakeLists.txt 0a575a6 tier2/kjobwidgets/src/config-kjobwidgets.h.cmake 35b64a2 tier2/kjobwidgets/tests/kjobtrackerstest.cpp 7a61407 Diff: http://git.reviewboard.kde.org/r/113503/diff/ Testing --- build tested on windows without dbus. not yet tested on other platforms Thanks, Sune Vuorela
Re: Review Request 113139: Try to export include targets for Plasma as well
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/#review41324
---
Which kde-workspace branch should I use to test this?
src/plasma/CMakeLists.txt
http://git.reviewboard.kde.org/r/113139/#comment30269
The if-else shouldn't be needed. INSTALL_INTERFACE should already check if
${INCLUDE_INSTALL_DIR} is absolute.
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/
---
(Updated Oct. 7, 2013, 8:13 a.m.)
Review request for kdelibs, Plasma and Stephen Kelly.
Repository: plasma-framework
Description
---
Add include targets for KF5::plasma, which will hopefully contribute towards
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
Diffs
-
src/plasma/CMakeLists.txt b21fd7b
Diff: http://git.reviewboard.kde.org/r/113139/diff/
Testing
---
In place on CI build system. Proper include path now given to compiler.
Thanks,
Ben Cooksley
Re: Review Request 113139: Try to export include targets for Plasma as well
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113139/#review41331 --- Ship it! Unfortunately it isn't entirely successful as it seems camelcase headers are installed by KF5::plasma into include/KDE/Plasma/ Odd. I tried to add this dir, but seem to have hit a bug I'll look into. Patch looks good for now I think, thanks! - Stephen Kelly On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113139/ --- (Updated Oct. 7, 2013, 8:13 a.m.) Review request for kdelibs, Plasma and Stephen Kelly. Repository: plasma-framework Description --- Add include targets for KF5::plasma, which will hopefully contribute towards fixing the kde-workspace[master] build on build.kde.org. Unfortunately it isn't entirely successful as it seems camelcase headers are installed by KF5::plasma into include/KDE/Plasma/ but it should be a start... Diffs - src/plasma/CMakeLists.txt b21fd7b Diff: http://git.reviewboard.kde.org/r/113139/diff/ Testing --- In place on CI build system. Proper include path now given to compiler. Thanks, Ben Cooksley
Re: Review Request 113139: Try to export include targets for Plasma as well
On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
src/plasma/CMakeLists.txt, line 173
http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173
The if-else shouldn't be needed. INSTALL_INTERFACE should already check
if ${INCLUDE_INSTALL_DIR} is absolute.
Ben Cooksley wrote:
I copied this code from KCoreAddons in kdelibs[frameworks]. Shall I
correct it there as well?
It appears in several other frameworks too. Actually your snippet is needed
until CMake 2.8.12. I'll remove it from them all when kde requires that version.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/#review41324
---
On Oct. 7, 2013, 10:48 a.m., Ben Cooksley wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/
---
(Updated Oct. 7, 2013, 10:48 a.m.)
Review request for kdelibs, Plasma and Stephen Kelly.
Repository: plasma-framework
Description
---
Add include targets for KF5::plasma, which will hopefully contribute towards
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
Diffs
-
src/plasma/CMakeLists.txt b21fd7b
Diff: http://git.reviewboard.kde.org/r/113139/diff/
Testing
---
In place on CI build system. Proper include path now given to compiler.
Thanks,
Ben Cooksley
Re: kde-workspace master becomes Qt5-based
Sebastian Kügler wrote: We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. I tried building the branch. It requires qimageblitz, which I didn't see a Qt 5 version for, and soprano which has a non-building qt5_port branch. Do you have local working branches of those? Thanks, Steve.
Re: Review Request 112756: KLinkItemSelectionModel: Do not change current index of mapped model if the mapped one is invalid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112756/#review40705 --- Ship it! Ship It! - Stephen Kelly On Sept. 16, 2013, 1:56 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112756/ --- (Updated Sept. 16, 2013, 1:56 p.m.) Review request for kdelibs and Stephen Kelly. Description --- I noticed Gwenview keyboard navigation broke with the latest KLinkItemSelectionModel changes: in browse mode, in a folder which contains both folders and images, something like this: dir1 dir2 img1 img2 if img1 is selected, pressing the left arrow makes dir1 selected instead of dir2. This can be explain as so: given the following model A with content: 0. dir1 1. dir2 2. img1 3. img2 model B a proxy model on A with content: 0. img1 1. img2 AView and BView, views on each models and a KLinkItemSelectionModel to link selections between AView and BView. Setting current index in AView to row 1, which does not exist in BView, currently causes KLinkItemSelectionModel to set BView current index to invalid, which in turns cause KLinkItemSelectionModel to set AView current index to invalid. Patch in this request prevents invalid indexes from being propagated. I am not sure it is the best behavior though: maybe we don't want to propagate invalid indexes, unless the original index is invalid itself? If I set current index of AView to invalid, maybe BView current index should become invalid as well? I am happy to implement this alternate behavior if you think it's better. Diffs - kdeui/itemviews/klinkitemselectionmodel.cpp be8395f kdeui/tests/klinkitemselectionmodeltest.cpp 91540fd Diff: http://git.reviewboard.kde.org/r/112756/diff/ Testing --- Existing test case has been extended to test behavior in case of invalid indexes. Gwenview keyboard behavior is not broken anymore. Thanks, Aurélien Gâteau
Re: Regression in CMake breaking builds
Alexander Neundorf wrote: It looks like it is related to using imported targets in try_compile(): -- Enabling c++0x support for unordered map CMake Error at cmTryCompileExec236800853Targets.cmake:96 (add_library): add_library cannot create imported target Qt4::QtGui because another target with the same name already exists. Call Stack (most recent call first): CMakeLists.txt:11 (include) Mea culpa. Fixed now in next: http://thread.gmane.org/gmane.comp.programming.tools.cmake.scm/7716 Thanks for reporting, Steve.
Re: Review Request 111953: KLinkItemSelectionModel: synchronize currentIndex
On Aug. 14, 2013, 7:30 a.m., Commit Hook wrote: This review has been submitted with commit 5bab478dd04d85a6017c54bc986bcf0b9e235264 by Michael Bohlender to branch master. What is this about? Was it pushed to a local clone or so? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111953/#review37747 --- On Aug. 14, 2013, 7:30 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111953/ --- (Updated Aug. 14, 2013, 7:30 a.m.) Review request for kdelibs, Michael Bohlender and Stephen Kelly. Description --- In addition to synchronizing selection, make KLinkItemSelectionModel also synchronize the current index. This fixes a bug in Gwenview where image operations are not applied to the correct images when multiple images are selected. This addresses bug 322850. http://bugs.kde.org/show_bug.cgi?id=322850 Diffs - kdeui/itemviews/klinkitemselectionmodel.h 392da46 kdeui/itemviews/klinkitemselectionmodel.cpp ee55d4f kdeui/tests/klinkitemselectionmodeltest.h f3e0fd1 kdeui/tests/klinkitemselectionmodeltest.cpp c3f7132 Diff: http://git.reviewboard.kde.org/r/111953/diff/ Testing --- - Extended unit-tests to test the current index is synchronized. - Verified the bug is fixed in Gwenview. Thanks, Aurélien Gâteau
Re: Review Request 111953: KLinkItemSelectionModel: synchronize currentIndex
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111953/#review37417 --- Have you tried kdepim applications with this patch too? Many of them use this class. kdeui/itemviews/klinkitemselectionmodel.cpp http://git.reviewboard.kde.org/r/111953/#comment27688 Excess whitespace. - Stephen Kelly On Aug. 8, 2013, 8:15 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111953/ --- (Updated Aug. 8, 2013, 8:15 p.m.) Review request for kdelibs and Stephen Kelly. Description --- In addition to synchronizing selection, make KLinkItemSelectionModel also synchronize the current index. This fixes a bug in Gwenview where image operations are not applied to the correct images when multiple images are selected. This addresses bug 322850. http://bugs.kde.org/show_bug.cgi?id=322850 Diffs - kdeui/itemviews/klinkitemselectionmodel.h 392da46 kdeui/itemviews/klinkitemselectionmodel.cpp ee55d4f kdeui/tests/klinkitemselectionmodeltest.h f3e0fd1 kdeui/tests/klinkitemselectionmodeltest.cpp c3f7132 Diff: http://git.reviewboard.kde.org/r/111953/diff/ Testing --- - Extended unit-tests to test the current index is synchronized. - Verified the bug is fixed in Gwenview. Thanks, Aurélien Gâteau
Re: KF5 Update Meeting Minutes 2013-w31
Kevin Ottens wrote:
Once the splitting will be done I'm not so sure it's better than using
directly the namespaced target names. The reason being that variables are
really a pain with cmake... I mean if you mistakenly use a variable name
which doesn't exist it's just expanded to nothing. Target names don't have
that problem.
For example:
cmake_minimum_required(VERSION 2.8)
project(foo)
add_executable(someexe main.cpp)
target_link_libraries(someexe ${Qt5Core_LIBRARIES})
CMake runs without failure.
Change it to
target_link_libraries(someexe Qt5::Core)
and CMake 2.8.13 will recognise the double colons as signifying an IMPORTED
target:
stephen@hal:~/dev/src/playground/cmake/build{master}$ cmake ..
-- The C compiler identification is GNU 4.7.3
-- The CXX compiler identification is GNU 4.7.3
-- Check for working C compiler: /usr/lib/icecc/bin/cc
-- Check for working C compiler: /usr/lib/icecc/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/icecc/bin/c++
-- Check for working CXX compiler: /usr/lib/icecc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
CMake Error at CMakeLists.txt:21 (add_executable):
Target foo links to IMPORTED target Qt5::Core but the IMPORTED target
was not found. Perhaps a find_package() call is missing?
target_link_libraries(foo ${KCoreAddons_LIBRARY_TARGETS} )
will guarantee that this thing contains targets, and that these targets
snip
Or you could actually explain what's needed for us to make it proper, so
that someone like Benjamin can look into it. I'd rather see more team work
in the CMake area than it currently is...
The problem is that external users of frameworks (including other
frameworks) would use namespaced target names. Eg, KAuth would do this:
find_package(KCoreAddons REQUIRED)
target_link_libraries(KAuth KF5::KCoreAddons)
However, as KAuth and KCoreAddons are part of the same buildsystem,
'KF5::KCoreAddons' is not defined, but 'KCoreAddons' is. The variable
abstracts that away, but it is indeed a temporary measure until the repo
split.
Another solution, coming in 2.8.13 is ALIAS targets:
add_library(KCoreAddons ...)
add_library(KF5::KCoreAddons ALIAS KCoreAddons)
# Works even in same buildsystem
target_link_libraries(KAuth KF5::KCoreAddons)
So, if this target/variable task is deferred until CMake 2.8.13 can be used,
the variables don't have to be used even in an intermediate state.
* using cmake withint KDE frameworks
The most pressing at the moment is the later. The other parts are
important of course, but the part about using cmake within KDE Frameworks
is badly needed already.
Any idea what is missing? Or what is the problem that makes it needed so
badly?
Thanks,
Steve.
Re: KF5 Update Meeting Minutes 2013-w31
Kevin Ottens wrote: So, if this target/variable task is deferred until CMake 2.8.13 can be used, the variables don't have to be used even in an intermediate state. I see, but when is 2.8.13 supposed to be released? I'd rather have us move forward. 2.8.12 will be released in a few weeks. 2.8.13 about 3 months after that. Thanks, Steve.
Re: Review Request 111158: Fix KLinkItemSelectionModel handling of QItemSelectionModel::Toggle flag
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/58/#review34939 --- Ship it! Ship It! - Stephen Kelly On June 21, 2013, 10:45 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/58/ --- (Updated June 21, 2013, 10:45 a.m.) Review request for kdelibs and Stephen Kelly. Description --- Summarizing the comment block: KLISM::select(QModelIndex,...) was calling QISM::select(QModelIndex,...) but QISM::select(QModelIndex,...) calls QISM::select(QItemSelection,...) which is virtual, so it ends up calling KLISM::select(QItemSelection,...). When using the Toggle selection flag, this ends up toggling the selection twice. This was breaking image multi-selection in Gwenview: - open an image Gwenview - show the thumbnail bar - click on the [+] button to select a second image = without the patch, image 2 does not get selected With the patch it gets selected and... Gwenview crashes as soon as you deselect image 2, but that is a bug in Gwenview. Fix for it is going to be pushed. Diffs - kdeui/itemviews/klinkitemselectionmodel.cpp 3c57c18239580497f659ef343c65be39998c2cb7 kdeui/tests/CMakeLists.txt 235e31e826ab8331f30c6e15c874bdc647d9efac kdeui/tests/klinkitemselectionmodeltest.h PRE-CREATION kdeui/tests/klinkitemselectionmodeltest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/58/diff/ Testing --- Added a unit-test. Tested in Gwenview. Thanks, Aurélien Gâteau
Re: KF5 Update Meeting 2013-w20
David Faure wrote: On Monday 20 May 2013 11:53:18 Alexander Neundorf wrote: there was a review request for a find-module for libusb1 here a few days ago, which we have already in e-c-m, but he can't use it because it is not released Could we maybe release a first version of ECM with only find modules, and without the frameworks stuff ? Obviously KF5 wouldn't be able to use that, so it would keep depending on ECM-from-git (and we could still change the API for that stuff if needed, which I assume is the reason for Stephen's no). But this way, Qt4/KDE4 apps could start using ECM, for shared find modules. Again, I see no need for KDE4 apps to use ecm. kdelibs is the appropriate place to put such modules for KDE4, if upstreaming to cmake is not an option. Thanks, Steve.
Re: KDE Workspace broken due to upstream CMake changes
Ben Cooksley wrote: Hi Alex, Can someone more familiar with the CMake community please inform them of this regression? http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776
Re: KF5 Update Meeting 2013-w20
Alexander Neundorf wrote: On Thursday 16 May 2013, Stephen Kelly wrote: Kevin Ottens wrote: Beside that, I would like if we could do a release of extra-cmake-modules as soon as possible, so other projects, KDE and non-KDE can start to make use of it and people can start to contribute. I guess that once we're happy with the cleanup pass that's something which could be done. I still don't want to release ecm until we're closer to releasing frameworks. There were people asking for something like e-c-m on the cmake list, and just a few days ago somebody here asked for something which we have already in e-c- m, but not in KDE 4.x. Can you be more specific in both cases? Now he has to duplicate it and we have to keep it in sync. He has to keep in sync, if it matters. We don't. A release would force us to be more careful about what we do there, which is IMO a good thing. I'm not convinced. I don't see any need to release it until KF5 is closer to release. Thanks, Steve.
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 2:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 2:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? Stephen Kelly wrote: No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 Andrea Scarpino wrote: I don't want to remove the 'qmake' word from the FindQt4.cmake file, but ATM that file looks for: qmake qmake4 qmake-qt4 (and so on) in this order. Why not using this one instead? qmake4 qmake-qt4 qmake... Did you follow the link I sent to the thread on the cmake list? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 2:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 2:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 108889: Add QML_INSTALL_DIR variable to KDE pathes
Sebastian Kügler wrote: On Sunday, February 10, 2013 14:33:49 Thiago Macieira wrote: On domingo, 10 de fevereiro de 2013 21.22.05, Sebastian Kügler wrote: Apparently not. I've looked at where the example imports from the Qt codebase install these things, and that is indeed $PREFIX/qml, not inside the plugin directory. This location is also where these imports are being found automatically, i.e. without specifying additional import pathes (which we have to do for Plasma in kdelibs 4). Technically, it's $ARCHDATADIR/qml. The Qt build makes ARCHDATADIR=PREFIX by default. But everyone installing Qt to PREFIX=/usr should set it ARCHDATADIR=$LIBDIR/qt5. So that means that qtquick2 imports should go there, and that we should advise people in our build instructions to build with --archdatadir=$LIBDIR/qt5? Which would bring me to my next question: How do I find out the ARCHDATA dir from a cmake script then? (Yes, noob question.) It is not currently set by the cmake scripts because I did not know why anyone would want it. What do you need it for, exactly? Thanks, Steve.
Re: Review Request 108889: Add QML_INSTALL_DIR variable to KDE pathes
Sebastian Kügler wrote: What do you need it for, exactly? To find out where Qt will look for QtQuick2 imports (that's $ARCHDATADIR/qml, defaulting to $PREFIX/qml, which leads to /usr/qml). I'd like to be able to install Plasma QtQuick2 imports into a path where they'll actually be found, that's the QML_INSTALL_DIR which the patch from this thread adds. Isn't it inappropriate for KDE to install things into the Qt installation? That's for Qt stuff? Isn't there a way to tell Qt where to find QML imports in alternative locations? I don't know myself, but I'd want to know if what you want to do is the oppostite of what is advised in the docs or not. Can you point at any relevant docs? Thanks, Steve.
Re: Kdelibs Coding Style vs. preparations for Qt5
Kevin Ottens wrote: We should push to use the class name only includes I think. I agree. We have a buildsystem that is good enough that we can specify the directories to look for the 'class name' headers in, and it is in the buildsystem that that stuff belongs. See the kinds of practical problems 'module includes' create: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/44780/focus=44893 Thanks, Steve.
Re: Kdelibs Coding Style vs. preparations for Qt5
Thiago Macieira wrote: On sábado, 29 de dezembro de 2012 22.58.49, Kevin Ottens wrote: On Saturday 29 December 2012 11:06:30 David Faure wrote: Well, for frameworks that intend to be as close to Qt as possible they should do the same (for the convenience of developers who don't use qmake/cmake but set up their project configuration in their IDE by hand, for instance Visual Studio). This means re-adding the missing QtWidgets/ in public headers once Qt5 is required in KF5. Out of curiosity, is it something which got documented in the Qt project? Or that's more a custom? (doesn't make it less valid, I'm being curious here and couldn't find the info) syncqt complains if public headers have Qt includes that aren't in the QtModule/ClassName or QtModule/classname.h form. syncqt is a Qt-internal tool. It is relevant to the headers of Qt itself, but not relevant outside it. Thanks, Steve.
Re: kde-workspace/4.9 messed up
Christoph Feck wrote: On Sunday 11 November 2012 12:00:05 Pino Toscano wrote: Hi, somehow the master branch of kde-workspace has been merged in the KDE/4.9 branch, with obvious consequences. Can anyone please fix this mess? Thanks, Uh oh, I think I did git reset origin/HEAD --hard in the 4.9 branch, to get rid of an initial commit I made in that branch. So HEAD doesn't refer to the remote head in the current branch, but always to the head of master? Something like that. It's similar to the mess that was just fixed yesterday in kdelibs: http://thread.gmane.org/gmane.comp.kde.devel.core/76984 Amazing that two people make the same mistake in such a short time, after such a long time without a similar issue. Someone needs to force-push the branch. Sysadmin knows what to do, so please talk to them to get it fixed. Thanks, Steve.
Re: kdelibs git mess
Christoph Feck wrote: Hi, my git foo is limited, but if I interpret http://ompldr.org/vZzZxaw correctly, then somehow master got merged into KDE/4.9 branch, meaning, for example, that Alex's commits to depend on cmake 2.8.8 are now in KDE/4.9 branch. I suggest to not to commit to kdelibs, until this is resolved. There is indeed breakage there. One way it could have happened is if Marco made a commit on his KDE/4.9 branch, and then accidentally did a 'git rebase origin/master' or similar and pushed the result. As far as I can see, this could happen for any branch at any time. There may be a way to add a server-side hook for it, which I've emailed sysadmin about. The fix should be for dfaure to reset the 4.9 branch to the v4.9.3 tag, cherry-pick the commits made after that and force push the result. He's going to do that now I think. Thanks, Steve.
Re: Requiring cmake 2.8.9 for kdelibs 4.10 ?
Alexander Neundorf wrote: On Monday 01 October 2012, David Faure wrote: On Monday 01 October 2012 09:53:22 Stephen Kelly wrote: Instead, I say we should do a 'pain free' update to 2.8.7 now, and an update to 2.8.11 later. Yes. I disagree. If we upgrade now, I want to have at least 2.8.8 This has a lof of work for supporting cmake's Config.cmake files, and with 2.8.8 I can finally point users how to create properly working (including Windows) Config.cmake files with reasonable effort. I don't see why that can't wait a little while longer. What is Windows-specific about how we create Config files currently? KDE 4.10 is scheduled for January 23rd, CMake 2.8.8 has been released April 19th, so it is 9 months old. The distros people are using to develop KDE 4.10 ship with CMake 2.8.7 (eg latest Ubuntu). I think that's a more significant fact. The next version of Ubuntu will ship at the end of October and will have CMake 2.8.9 I guess. I don't think everyone upgrades immediately though, and I don't know the release schedules of other distros. I don't think it's a good idea to depend on CMake 2.8.8 for KDE 4.10. If you commit it though, I won't revert. I'm just claiming it's not a great idea, and I don't see the particular urgent need. Thanks, Steve.
Re: Requiring cmake 2.8.9 for kdelibs 4.10 ?
Alexander Neundorf wrote: On Monday 01 October 2012, David Faure wrote: On Monday 01 October 2012 09:53:22 Stephen Kelly wrote: Instead, I say we should do a 'pain free' update to 2.8.7 now, and an update to 2.8.11 later. Yes. I disagree. If we upgrade now, I want to have at least 2.8.8 This has a lof of work for supporting cmake's Config.cmake files, and with 2.8.8 I can finally point users how to create properly working (including Windows) Config.cmake files with reasonable effort. I don't see why that can't wait a little while longer. What is Windows-specific about how we create Config files currently? KDE 4.10 is scheduled for January 23rd, CMake 2.8.8 has been released April 19th, so it is 9 months old. The distros people are using to develop KDE 4.10 ship with CMake 2.8.7 (eg latest Ubuntu). I think that's a more significant fact. The next version of Ubuntu will ship at the end of October and will have CMake 2.8.9 I guess. I don't think everyone upgrades immediately though, and I don't know the release schedules of other distros. I don't think it's a good idea to depend on CMake 2.8.8 for KDE 4.10. If you commit it though, I won't revert. I'm just claiming it's not a great idea, and I don't see the particular urgent need. Thanks, Steve.
Re: Review Request: Add Activity Awareness to KFilePlaces* Widget (OnlyInActivity)
David Faure wrote: If we (=someone) make a frameworks branch for kactivities, it should be quite simple to port that away from kdecore (I suppose it was mostly using KPluginLoader, which has now moved to the kservice framework). So this might just be a matter of updating a few CMakeLists.txt files. The work to use only an individual framework (eg kservice) as a dependency isn't really in the frameworks branch yet though. With CMake 2.8.10 close to release, that will be possible soon though. (Recall the issues with exported targets, which are fixable with the new CMake). Thanks, Steve.
Re: Review Request: fix exports using Q_DECL_EXPORT
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105452/#review15424 --- I disagree. I think the best solution is to have a copy of the cmake generate export header stuff in frameworks and use the new macro in the copy. The copy can be removed when we depend on a later version of CMake. - Stephen Kelly On July 5, 2012, 1:09 p.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105452/ --- (Updated July 5, 2012, 1:09 p.m.) Review request for kdelibs, Stephen Kelly, David Faure, and Alexander Neundorf. Description --- This fix is needed for some custom exports on windows. Given there is no KDE_EXPORT anymore, I use Q_DECL_EXPORT for now. See also the discussion on kde-frameworks-de...@kde.org. Diffs - kdecore/localization/ktranscript.cpp 08ebf0e kdecore/util/kexportplugin.h 775ed48 Diff: http://git.reviewboard.kde.org/r/105452/diff/ Testing --- windows only. Thanks, Patrick Spendrin
Re: kdelibs and Qt version dependency
Dirk Mueller wrote: On Tuesday 05 June 2012, Albert Astals Cid wrote: On May 19, Dawit Alemayehu commited a change that uses QSslConfiguration::testSslOption that is only available in Qt 4.8 This means that both kdelibs 4.8.4 and kdelibs 4.9 now depend in Qt 4.8 instead Qt 4.7 Hi Albert, thanks for noticing. I confirmed the issue and I can confirm that 4.8.3 compiled fine with Qt 4.7. a) Do you think it makes sense to change our Qt required version from Qt 4.7 in kdelibs 4.8.3 to Qt 4.8 in kdelibs 4.8.4 ? I think for kdelibs 4.8.4 we should make the dependency on Qt 4.8 optional. can we ifdef the change for Qt 4.8? is there a way to fallback ? b) Do you think kdelibs 4.9 should depend in Qt 4.8 or not? I'd be in favor of that change. Greetings, Dirk I agree with Dirk on both counts.
Re: kdelibs splitting: May results, plans for June
Alexander Neundorf wrote: Ah, right. Can you put a copy of FindLibLZMA.cmake into tier1/karchive/cmake/ ? (it will be in cmake 2.8.9) Then we don't need the CMAKE_MODULE_PATH from kdelibs anymore, and karchive is more standalone. Or we can bump the dependency to 2.8.9 when the RC 1 comes out (soon) and save the work of porting to a copy. Thanks, Steve.
Re: QtScript considered dangerous
Dominik Haumann wrote: On Friday, 25. May 2012 21:42:50 Stephen Kelly wrote: Christoph Cullmann wrote: Still, a fix for QtScript would be the nicest solution or a port to the new engine provided in Qt5, as I understood, there QtScript is anyway deprecated in favour of the V8 based new variant? Nope. QtScript might be 'done' - meaning no one is working on it and there's no replacement. The v8 stuff is not public API like QtScript is, so it is not a replacement. But does the new engine provide the same nice features to easily wrap your objects and expose a custom API? Yes. That's how QtDeclarative works. As it's internal, non-public API, that doesn't really matter much. Maybe a public API will be created to replace QtScript eventually though... According to the docs http://doc-snapshot.qt-project.org/5.0/qjsengine.html QJSEngine and QJSValue are already public API. Maybe I'm mistaken? That's interesting. Maybe I am mistaken. It doesn't look like it's intended to be a QtScript replacement as it is, but I'll ask on the ml. Thanks, Steve.
Re: TechBase git policies, infrastructure documentation, please
Alexander Neundorf wrote: It would be just *great* if you could put this on techbase.kde.org :-) I'd suggest you just copy it into wherever you would look for it. Mostly it's not kde specific anyway. It's just about knowing how to use git. Thanks, Steve.
Re: Review Request: Fix Solid CMake check with Qt 5
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/#review13267 --- Please do not submit this. It is out of date. You are probably using qt5.git which is way out of date. This is not needed anymore. - Stephen Kelly On May 1, 2012, 11:28 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/ --- (Updated May 1, 2012, 11:28 p.m.) Review request for kdelibs. Description --- Fix CMake configure with Qt 5 DBusTools is required so that qt5_add_dbus_interfaces is available Not sure if this is the preferred way of solving the issue, but it works for me. Diffs - tier1/solid/src/solid/CMakeLists.txt f309a64 Diff: http://git.reviewboard.kde.org/r/104820/diff/ Testing --- Configuring didn't work before, now it does. Thanks, Alexander Richardson
Re: Review Request: Fix Solid CMake check with Qt 5
On May 2, 2012, 11:43 a.m., Stephen Kelly wrote: Please do not submit this. It is out of date. You are probably using qt5.git which is way out of date. This is not needed anymore. Alexander Richardson wrote: Ok. How do I get a Qt 5 with which I can build kdelibs? Checkout master in every repo? I'm not familiar with the script you are using or with qt5.git. If you have qtbase.git and qtsvg.git (master) that's enough to build most of frameworks. I don't know if that would break your script and cause you to need to update the rest too. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/#review13267 --- On May 1, 2012, 11:28 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/ --- (Updated May 1, 2012, 11:28 p.m.) Review request for kdelibs. Description --- Fix CMake configure with Qt 5 DBusTools is required so that qt5_add_dbus_interfaces is available Not sure if this is the preferred way of solving the issue, but it works for me. Diffs - tier1/solid/src/solid/CMakeLists.txt f309a64 Diff: http://git.reviewboard.kde.org/r/104820/diff/ Testing --- Configuring didn't work before, now it does. Thanks, Alexander Richardson
Re: TechBase git policies, infrastructure documentation, please
Alexander Neundorf wrote: git is a powerful tool, and you can use it in many different ways. It needs to be easy to find out how git is intended to be used in KDE. I don't know where this is documented. I expect this on techbase. It is indeed not on techbase as far as I can see too. Do you have specific questions? Are you looking for tutorials on how to use git generally (not KDE specific), or are you looking for policies (KDE specific)? Does running gitk in the repos answer any policies questions or raise new ones? eg in CMake git, every commit is not on master but a different branch. If you look at gitk in the kdelibs repo for example, you see that that is not how people are committing. People commit directly to KDE/4.8 or directly to frameworks. Periodically, someone (most recently me) merges the KDE/4.8 branch into the frameworks branch. Thanks, Steve.
Re: TechBase git policies, infrastructure documentation, please
Alexander Neundorf wrote: On Sunday 29 April 2012, Stephen Kelly wrote: Alexander Neundorf wrote: git is a powerful tool, and you can use it in many different ways. It needs to be easy to find out how git is intended to be used in KDE. I don't know where this is documented. I expect this on techbase. It is indeed not on techbase as far as I can see too. Do you have specific questions? Are you looking for tutorials on how to use git generally (not KDE specific), I kind of manage to get along with it in the mean time, if I know what I should do. Ok, here's a question: I'd like to modify the buildsystem for kdelibs/tier1/itemmodels/, but in some branch so others can have a look at it. What is the recommended way to do this ? It this specific case, it's likely that the whole of what you want to change and have reviewed can be shown as one single patch (even if you split it into multiple patches when you commit). The cases where it takes more than one patch, that is also easiest (for me at least) as just creating a file with the patches and sending it with email. Reviewboard is only practical for one patch at a time afaik, but I'm not a Reviewboard fan anyway. or are you looking for policies (KDE specific)? This one. What is the git workflow/are the git workflows to use in KDE. Including use cases like doing minor fixes, normal feature development, experimental stuff to show somebody, etc. Ideally including the typical git commands to use for that. Assuming you know how to make commits and assuming you start with a clean checkout: vi tier1/itemmodels/CMakeLists.txt # ... git commit -m lorem ipsum vi tier1/itemmodels/CMakeLists.txt # ... git commit -m prink the retjuts vi tier1/itemmodels/CMakeLists.txt # ... git commit -m unfubar the dolors Then git format-patch --stdout origin/frameworks will print out the patches and commit messages. Redirect it to a file and send the file for review. Then someone will give feedback and might say that there is a small change needed to the first patch (the lorem ipsum one). You do this: git rebase -i origin/master You see this with some instructions: pick 514c03d lorem ipsum pick 2ab30eb prink the retjuts pick 9266e12 unfubar the dolors you replace 'pick' with 'edit' in your editor, save and exit. You make the change suggested in the review. You use: git commit --ammend Then git rebase --continue Then use gitk and you will see that the lorem ipsum commit now has your change. http://book.git-scm.com/4_interactive_rebasing.html Google 'interactive rebase' for more. Then when you push, you might get this: To g...@git.kde.org:kdelibs ! [rejected]frameworks - frameworks (non-fast-forward) error: failed to push some refs to 'g...@git.kde.org:kdelibs' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Just do this: git pull --rebase Then git push again. If we have multiple recommended workflows, it would be really good to have an overview where I can see which workflow should be used where. E.g. below you describe what should be done in kdelibs. Now if I want to fix something e.g. in kdegames, where do I find out what workflow should be used there. You look in gitk and see what the people do. If people commit directly to the branch you want to commit to, you do the same. It would be unusual for that not to be the case, so just assume that you always just make commits, rebase/rewrite them until they are correct, git pull --rebase, and then git push. This should be on techbase. Did we settle on the branch names ? Is this documented on techbase, in the git section ? To keep useful history, don't push work branches to kdelibs.git. Instead push to a scratch repo, ask for reviews of that branch, and when it's ready, rebase it to master in kdelibs.git, and push that. http://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_scratch_repositories Having it somewhere in a blog is only slightly better than nothing. KDE should have a place where you can easily find how to start development. While with cvs and svn there is mostly one way to use branches etc., with git you can do whatever you want, and we don't have this documented. E.g for CMake itself this is documented here: http://www.cmake.org/Wiki/CMake/Git Something similar for KDE is missing, at least on techbase. Alex P.S. Stephen, you're doing great work on KDE frameworks :-) Thanks, :)
Re: Using KColorScheme in style only (Was: fix frameworks-kactions compile error)
Hugo Pereira Da Costa wrote: On 04/19/2012 11:27 AM, Stephen Kelly wrote: Would it be possible to remove the use of KColorScheme from these widgets in general? In my oppinion, yes. Good enough for me, thanks :)
Re: Using KColorScheme in style only (Was: fix frameworks-kactions compile error)
Hi, can anyone who knows about styles/KColorScheme comment on this?
Thanks,
Stephen Kelly wrote:
Kevin Ottens wrote:
On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
[...]
At the center of the questions of what to do with KUrlLabel and
KCapacityBar are the question of what to do about their KColorScheme
dependency. Their use of KColorScheme seems to me like something that
should be handled by the style instead (otherwise, for example,
QProgressBar wouldn't look consistent with a KCapacityBar with its
backgrounds and fill etc). Oxygen may already even handle a KCapacityBar
(I'm not certain):
kde-workspace/kstyles/oxygen{master}$ git grep CapacityBar
oxygenstyle.cpp:CE_CapacityBar( newControlElement(
CE_CapacityBar ) )
oxygenstyle.cpp:if( element == CE_CapacityBar )
oxygenstyle.cpp:fcn = Style::drawCapacityBarControl;
oxygenstyle.cpp:bool Style::drawCapacityBarControl( const
QStyleOption* option, QPainter* painter, const QWidget* widget ) const
oxygenstyle.h:virtual bool drawCapacityBarControl( const
QStyleOption*, QPainter*, const QWidget* ) const;
oxygenstyle.h:QStyle::ControlElement CE_CapacityBar;
KColorScheme is very different from QPalette. It seems to have 4
dimensions that QPalette doesn't have. I'm all for configuration, but I
think it should have an affect in the style, not in the widgets
themselves. Any thoughts?
Would it be possible to remove the use of KColorScheme from these
widgets in general?
I'm unfortunately completely ignorant regarding KColorScheme... I agree
it should probably not leak into our widgets and be used by the styles
only though.
Hugo, any ideas/comment on this? The background is here:
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/473/focus=485
Thanks,
Why does KPushButton have a delayedMenu?
Hi there, I'm trying to figure out why KPushButton has a feature of a 'delayed' menu. Why would applications need that? What problems does it solve? Can the problem be solved in Qt? Thanks, Steve.
Re: Why does KPushButton have a delayedMenu?
Kevin Krammer wrote: On Friday, 2012-04-06, Stephen Kelly wrote: Eike Hein wrote: On 04/06/2012 01:08 PM, Richard Moore wrote: It's for things like a browser's back button where a click moves you back, wheras press and hold shows a menu of the recent history. Another use is in Konsole (and Yakuake) where click-and-hold on the New Tab button opens a popup menu allowing the choice of which profile to use. Ah, I see. I thought it was some internalized workaround for some bug or other, but that looks like something that could be added to Qt. QToolButton has that, see QToolButton::ToolButtonPopupMode My guess for it not being in QAbstractButton is that it doesn't make sense for QCheckBox and QRadioButton. Interesting. So should KPushButtons which wish to use the delayed popup stuff be changed to QToolButtons, or should we try to get the feature from QToolButton to QAbstractButton. I don't think it would be too unusual to have parts of an interface which not all subclasses make use of. Or maybe the menu popup stuff can be refactored into an internal class used by both QToolButton and QPushButton, and add the feature and API to QPushButton that way. Either way, it would need to be done in a BC way in Qt 5.1. Any volunteers? Also, any arguments supporting getting it into Qt? Can someone tell me where I would see it used outside of a toolbar (Where a QToolButton should be used instead)? Also, I'm a bit confused by the docs for this stuff: /** * Sets a delayed popup menu * for consistency, since menu() isn't virtual */ void setDelayedMenu(QMenu *delayed_menu); /** * returns a delayed popup menu * since menu() isn't virtual */ QMenu *delayedMenu(); What does the delayed menu stuff have to do with menu() not being virtual? Would it be easier if it was virtual? Should we try to make it virtual (any volunteers?)? Always thought QToolButton should be a mode of QPushButton instead of a separate class :) Maybe... I guess it would be possible in theory to get its features into QPushButton and deprecate QToolButton, but again, someone would have to justify and implement that. Thanks, Steve.
Re: Review Request: Make KAuth ready for frameworks + API Changes
Dario Freddi wrote: gitk indeed has a screwy visualization in there. You conclusion that the tool is screwy is interesting for a few reasons. Maybe some day you'll reconsider it. More importantly though, you seem to have broken the frameworks branch. True, sorry about that. This is fixed now. Thanks.
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 30, 2012, 1:14 p.m., Dario Freddi wrote: April is upon us. If no objections arise in the time being, these changes will be merged on Sunday, after which I'll ask Kevin to move KAuth back to tier2/ for prime time. Stephen Kelly wrote: Thanks for making this happen! :) Instead of merging, please rebase your work like this: git fetch origin git checkout kauth-unit-tests git rebase origin/frameworks git checkout frameworks git rebase kauth-unit-tests gitk # Make sure it still looks ok. git push This will instead replay your changes on top of the tip of the frameworks branch instead of creating a merge, which is not needed. Dario Freddi wrote: I always do this - nice to know that others love rebased branches :D Stephen Kelly wrote: Great. Good to know. You did use the word 'merge' though, which triggered my alarm. :) Thanks, Kevin Ottens wrote: So that you know, it's perfectly fine to me if you do the move yourself, it has my approval already once you rebased on master. Now if you prefer me to do it myself I can, it's just no a requirement. Dario Freddi wrote: I'd ask you to please complete the move yourself, given that I am not still completely familiar with what's involved (which maybe is just git mv, but just in case) I saw the branch was merged in. Did something go wrong with the rebase idea? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review12013 --- On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 30, 2012, 1:14 p.m., Dario Freddi wrote: April is upon us. If no objections arise in the time being, these changes will be merged on Sunday, after which I'll ask Kevin to move KAuth back to tier2/ for prime time. Stephen Kelly wrote: Thanks for making this happen! :) Instead of merging, please rebase your work like this: git fetch origin git checkout kauth-unit-tests git rebase origin/frameworks git checkout frameworks git rebase kauth-unit-tests gitk # Make sure it still looks ok. git push This will instead replay your changes on top of the tip of the frameworks branch instead of creating a merge, which is not needed. Dario Freddi wrote: I always do this - nice to know that others love rebased branches :D Stephen Kelly wrote: Great. Good to know. You did use the word 'merge' though, which triggered my alarm. :) Thanks, Kevin Ottens wrote: So that you know, it's perfectly fine to me if you do the move yourself, it has my approval already once you rebased on master. Now if you prefer me to do it myself I can, it's just no a requirement. Dario Freddi wrote: I'd ask you to please complete the move yourself, given that I am not still completely familiar with what's involved (which maybe is just git mv, but just in case) Stephen Kelly wrote: I saw the branch was merged in. Did something go wrong with the rebase idea? Dario Freddi wrote: The branch was rebased in fact. But was subsequently merged with --no-ff to have a way to track all the changes with the merge commit (which is nothing but a simple at this point, this branch was integrated). So actually, all of the commits are in fact rebased on top of (previous) framework It was rebased onto some relatively recent commit, but not the tip of the branch. I don't understand why you bothered rebasing if you were just going to merge after doing so anyway (--no-ff). I don't see the value in --no-ff at all. It's just as clear that the commits are related because they come from the same person for one thing, and because you prefix the first line with the topic for another. --no-ff doesn't get you anything useful if you already have that. I just don't understand the obsession with merges in repos, but as far as I can see I'm on my own there... - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review12013 --- On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new
Re: Review Request: Make KAuth ready for frameworks + API Changes
Now I'm confused. Stephen Kelly wrote: It was rebased onto some relatively recent commit, but not the tip of the branch. You disagreed with what I said: - Given that the branch was rebased on top of the last frameworks' commit (as you can see from the log), ... actually I don't see that in the log. Here's what I see: http://i.imgur.com/xhbCC.png Do we have a difference in definitions, or is something else causing the confusion? - Last but not least, looking just at the merge commit shows you the full diff the branch introduced - in such a case, for example, is incredibly useful to track all of the API changes at once. Yes, you could have used git diff merge commit first commit before the rebased branch and it would have had the same effect, but the approach is more clean I tried this with gitk and git show. Neither worked as you describe. Starting from the point that this discussion is mostly about one's own taste (and again, that's why we NEED a clear policy), my reason for doing this is that: Policies won't help. Only technical measures like not accepting pushes with merges, except between release-lines (master, 4.8 branch etc) would work, if such a thing would be decided on, or if your workflow became policy, only accepting pushes with only merge commits on release-line branches. I doubt such a thing could be both decided on though. I can imagine what the hook would look like in both cases. More importantly though, you seem to have broken the frameworks branch. For example (there are other breakages) 046123dcd8f0f9b900ed1d694e7bbb9f21549ade breaks the build because earlyAuthorize has been removed and you didn't port the users of it in the frameworks branch away from that API. Could you do the port and push a commit fixing the build of the whole frameworks branch? I guess maybe until now you have only compiled KAuth or somthing. Thanks, Steve.
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 30, 2012, 1:14 p.m., Dario Freddi wrote: April is upon us. If no objections arise in the time being, these changes will be merged on Sunday, after which I'll ask Kevin to move KAuth back to tier2/ for prime time. Thanks for making this happen! :) Instead of merging, please rebase your work like this: git fetch origin git checkout kauth-unit-tests git rebase origin/frameworks git checkout frameworks git rebase kauth-unit-tests gitk # Make sure it still looks ok. git push This will instead replay your changes on top of the tip of the frameworks branch instead of creating a merge, which is not needed. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review12013 --- On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client in the same process, in the unit test I am resorting to making the dbus service of the helper live in a separate thread, to prevent asynchronous DBus calls from failing due to QDBus' local-loop optimization. The test is also run on the session bus. Diffs - staging/kauth/CMakeLists.txt PRE-CREATION staging/kauth/autotests/BackendsManager.h PRE-CREATION staging/kauth/autotests/BackendsManager.cpp PRE-CREATION staging/kauth/autotests/CMakeLists.txt PRE-CREATION staging/kauth/autotests/HelperTest.cpp PRE-CREATION staging/kauth/autotests/SetupActionTest.cpp PRE-CREATION staging/kauth/autotests/TestBackend.h PRE-CREATION staging/kauth/autotests/TestBackend.cpp PRE-CREATION staging/kauth/autotests/TestHelper.h PRE-CREATION staging/kauth/autotests/TestHelper.cpp PRE-CREATION
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 21, 2012, 8:54 p.m., Alexander Neundorf wrote:
I did not yet have time to look through the git branch...
So, kauth, we have a bunch of cmake macros related to this in
kdelibs/cmake/KDE4Macros.cmake, right ?
What about them ?
They are already in ${CMAKE_SOURCE_DIR}/staging/kauth/cmake/KAuthMacros.cmake
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/#review11717
---
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/
---
(Updated March 18, 2012, 10:25 p.m.)
Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf.
Description
---
Preamble - sorry for having to name-call people but apparently we still don't
have a frameworks way for reviewing code (which sucks). And sorry for the
long summary, but it's worth reading. However.
This huge patchsets brings KAuth in the marvelous world of Frameworks. If you
dislike ReviewBoard's way of displaying diffs or simply want to see a commit
list, please refer to the URL in Branch.
First of all, I pulled in a dependency on KJob after a chat with Kevin. This
makes KAuth tier2, but shouldn't be a big issue.
Then there's the hard part: source compatibility is reasonably broken here.
The changes I had to do were mostly for the sake of revamping the internal
workflow of the library. The main problem KAuth had was the fact it was
completely synchronous, leading to a multitude of problems. After these
changes it's fully asynchronous instead (reason for pulling in KJob), the API
was simplified, and some unused features like multiple action execution have
been removed.
The main changes at a glance:
* Some renaming to the enums
* Moving Action ActionReply to be implicitly shared
* Removing ActionWatcher (now useless due to the new semantics of execute
* Removing some useless APIs from Action, namely executeActions,
execute(helper)
* execute() now returns a KJob
* helperID() - helperId()
* Static action replies are now static accessors returning a new instance.
This was a complete mistake in the first place, but it's still there with a
different semantic to ease porting. The main use case for changing this is a
failure to handle implicitly shared classes in multithreaded environments
with that approach.
Of course, while it would be awesome to have all the code reviewed, I
understand it's a very big change so I'd like at least some feedback on the
following points:
* General sanity of the new API
* Consistency of the enums. StatusInvalid vs. ExecuteMode vs.
AuthorizationDeniedError. While the semantic seems correct to me, I'd like to
have some feedback on whether consistency is valuable in the ordering of
typevalue vs. valuetype and which one should be preferred in case.
* Whether to deprecate static accessors such as static const ActionReply
SuccessReply(). I strongly favor this.
* Whether the new dependency of kcoreaddons for the sake of using KJob is
reasonable or I should go for a different alternative.
* CMake sanity for the new dependency of kcoreaddons.
The code is pretty much unit-tested and it should have a decent coverage,
even if I had no way to check this. For unit tests, I had to create a fake
authorization backend for testing purposes, whereas I managed to reuse the
dbus backend for helper communication, so that I could even test that. For
running the helper and the client in the same process, in the unit test I am
resorting to making the dbus service of the helper live in a separate thread,
to prevent asynchronous DBus calls from failing due to QDBus' local-loop
optimization. The test is also run on the session bus.
Diffs
-
staging/kauth/CMakeLists.txt PRE-CREATION
staging/kauth/autotests/BackendsManager.h PRE-CREATION
staging/kauth/autotests/BackendsManager.cpp PRE-CREATION
staging/kauth/autotests/CMakeLists.txt PRE-CREATION
staging/kauth/autotests/HelperTest.cpp PRE-CREATION
staging/kauth/autotests/SetupActionTest.cpp PRE-CREATION
staging/kauth/autotests/TestBackend.h PRE-CREATION
staging/kauth/autotests/TestBackend.cpp PRE-CREATION
staging/kauth/autotests/TestHelper.h PRE-CREATION
staging/kauth/autotests/TestHelper.cpp PRE-CREATION
staging/kauth/src/AuthBackend.h PRE-CREATION
staging/kauth/src/CMakeLists.txt PRE-CREATION
staging/kauth/src/HelperProxy.h PRE-CREATION
staging/kauth/src/backends/dbus/DBusHelperProxy.h PRE-CREATION
staging/kauth/src/backends/dbus/DBusHelperProxy.cpp PRE-CREATION
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 18, 2012, 11:04 p.m., Stephen Kelly wrote: Nice, thanks and sorry for the noise, and thanks for making the branch. Dario Freddi wrote: Np, hope you'll be able to have a quick look at it as well, it would be great :) Mostly it looks fine. The enums are not named consistently though. Sometimes you make it enum nameenum value (eg StatusDenied) and sometimes you use enum valueenum name (eg HelperBusyError). The Qt way would be enum valueenum name. Also, you replied that removed APIs are used nowhere. Are the enums used nowhere too? Is it worth keeping the backward compatibility enum names? Assuming your branch builds (I didn't try it) nothing else inside of kdelibs seems to need those enum values at least, so maybe it's not a big deal. I'm also generally impressed with how the commits are written to do one thing at a time, so thanks for that. I wonder if the fixes to ExecuteJob should be squashed though as well as porting it to KJob? It's not clear to me if those commits are separate because of something in an intermediate commit? Not very important either way. I don't mind if you change them or not. Some of the files in the unit tests appear to be old. Are they copied from somewhere? Could they be moved instead? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review11596 --- On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client in the same process, in the unit test I am resorting to making the dbus service of the helper live in a separate thread, to prevent asynchronous DBus calls from failing due to QDBus' local-loop optimization
Re: Review Request: Make KAuth ready for frameworks + API Changes
On March 18, 2012, 11:04 p.m., Stephen Kelly wrote:
Nice, thanks and sorry for the noise, and thanks for making the branch.
Dario Freddi wrote:
Np, hope you'll be able to have a quick look at it as well, it would be
great :)
Stephen Kelly wrote:
Mostly it looks fine.
The enums are not named consistently though. Sometimes you make it enum
nameenum value (eg StatusDenied) and sometimes you use enum valueenum
name (eg HelperBusyError).
The Qt way would be enum valueenum name.
Also, you replied that removed APIs are used nowhere. Are the enums used
nowhere too? Is it worth keeping the backward compatibility enum names?
Assuming your branch builds (I didn't try it) nothing else inside of kdelibs
seems to need those enum values at least, so maybe it's not a big deal.
I'm also generally impressed with how the commits are written to do one
thing at a time, so thanks for that. I wonder if the fixes to ExecuteJob
should be squashed though as well as porting it to KJob? It's not clear to me
if those commits are separate because of something in an intermediate commit?
Not very important either way. I don't mind if you change them or not.
Some of the files in the unit tests appear to be old. Are they copied
from somewhere? Could they be moved instead?
Regarding what you asked about:
* Consistency of the enums. StatusInvalid vs. ExecuteMode vs.
AuthorizationDeniedError. While the semantic seems correct to me, I'd like to
have some feedback on whether consistency is valuable in the ordering of
typevalue vs. valuetype and which one should be preferred in case.
I guess I prefer the Qt style.
* Whether to deprecate static accessors such as static const ActionReply
SuccessReply(). I strongly favor this.
If you know that they are not much used or easily portable, I'd say go for it.
* Whether the new dependency of kcoreaddons for the sake of using KJob is
reasonable or I should go for a different alternative.
I think it's an ok dependency. I still hope that class will move to a different
framework at some point if we can find other classes that it would belong with
('base-asyncronous APIs'?). 'addons' is a forbidden name if the result of Randa
is followed.
* CMake sanity for the new dependency of kcoreaddons.
That's fine, yes.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/#review11596
---
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/
---
(Updated March 18, 2012, 10:25 p.m.)
Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf.
Description
---
Preamble - sorry for having to name-call people but apparently we still don't
have a frameworks way for reviewing code (which sucks). And sorry for the
long summary, but it's worth reading. However.
This huge patchsets brings KAuth in the marvelous world of Frameworks. If you
dislike ReviewBoard's way of displaying diffs or simply want to see a commit
list, please refer to the URL in Branch.
First of all, I pulled in a dependency on KJob after a chat with Kevin. This
makes KAuth tier2, but shouldn't be a big issue.
Then there's the hard part: source compatibility is reasonably broken here.
The changes I had to do were mostly for the sake of revamping the internal
workflow of the library. The main problem KAuth had was the fact it was
completely synchronous, leading to a multitude of problems. After these
changes it's fully asynchronous instead (reason for pulling in KJob), the API
was simplified, and some unused features like multiple action execution have
been removed.
The main changes at a glance:
* Some renaming to the enums
* Moving Action ActionReply to be implicitly shared
* Removing ActionWatcher (now useless due to the new semantics of execute
* Removing some useless APIs from Action, namely executeActions,
execute(helper)
* execute() now returns a KJob
* helperID() - helperId()
* Static action replies are now static accessors returning a new instance.
This was a complete mistake in the first place, but it's still there with a
different semantic to ease porting. The main use case for changing this is a
failure to handle implicitly shared classes in multithreaded environments
with that approach.
Of course, while it would be awesome to have all the code reviewed, I
understand it's a very big change so I'd like at least some feedback on the
following points:
* General sanity of the new API
* Consistency of the enums. StatusInvalid vs. ExecuteMode
Re: Review Request: Make KAuth ready for frameworks + API Changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review11594 --- Given that it does so many things, I wonder if it should be split into multiple patches. (I didn't fetch the branch - maybe you already have it in multiple patches) For examples, renaming the enums in one commit, making Action implicitly shared in another, ID -id in another etc. That would make the 'meat' of your work reviewable. Did you investigate how much the removed API is used? - Stephen Kelly On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client in the same process, in the unit test I am resorting to making the dbus service of the helper live in a separate thread, to prevent asynchronous DBus calls from failing due to QDBus' local-loop optimization. The test is also run on the session bus. Diffs - staging/kauth/CMakeLists.txt PRE-CREATION staging/kauth/autotests/BackendsManager.h PRE-CREATION staging/kauth/autotests/BackendsManager.cpp PRE-CREATION staging/kauth/autotests/CMakeLists.txt PRE-CREATION staging/kauth/autotests/HelperTest.cpp PRE-CREATION staging/kauth/autotests/SetupActionTest.cpp PRE-CREATION staging/kauth/autotests/TestBackend.h PRE-CREATION staging/kauth/autotests/TestBackend.cpp PRE-CREATION staging/kauth/autotests/TestHelper.h PRE-CREATION staging/kauth/autotests/TestHelper.cpp PRE-CREATION staging/kauth/src/AuthBackend.h PRE-CREATION staging/kauth/src/CMakeLists.txt PRE-CREATION staging/kauth/src/HelperProxy.h PRE-CREATION staging/kauth/src/backends/dbus/DBusHelperProxy.h PRE-CREATION staging/kauth/src/backends/dbus
Re: Review Request: Make KAuth ready for frameworks + API Changes
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/#review11596 --- Nice, thanks and sorry for the noise, and thanks for making the branch. - Stephen Kelly On March 18, 2012, 10:25 p.m., Dario Freddi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104337/ --- (Updated March 18, 2012, 10:25 p.m.) Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neundorf. Description --- Preamble - sorry for having to name-call people but apparently we still don't have a frameworks way for reviewing code (which sucks). And sorry for the long summary, but it's worth reading. However. This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike ReviewBoard's way of displaying diffs or simply want to see a commit list, please refer to the URL in Branch. First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes KAuth tier2, but shouldn't be a big issue. Then there's the hard part: source compatibility is reasonably broken here. The changes I had to do were mostly for the sake of revamping the internal workflow of the library. The main problem KAuth had was the fact it was completely synchronous, leading to a multitude of problems. After these changes it's fully asynchronous instead (reason for pulling in KJob), the API was simplified, and some unused features like multiple action execution have been removed. The main changes at a glance: * Some renaming to the enums * Moving Action ActionReply to be implicitly shared * Removing ActionWatcher (now useless due to the new semantics of execute * Removing some useless APIs from Action, namely executeActions, execute(helper) * execute() now returns a KJob * helperID() - helperId() * Static action replies are now static accessors returning a new instance. This was a complete mistake in the first place, but it's still there with a different semantic to ease porting. The main use case for changing this is a failure to handle implicitly shared classes in multithreaded environments with that approach. Of course, while it would be awesome to have all the code reviewed, I understand it's a very big change so I'd like at least some feedback on the following points: * General sanity of the new API * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. AuthorizationDeniedError. While the semantic seems correct to me, I'd like to have some feedback on whether consistency is valuable in the ordering of typevalue vs. valuetype and which one should be preferred in case. * Whether to deprecate static accessors such as static const ActionReply SuccessReply(). I strongly favor this. * Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable or I should go for a different alternative. * CMake sanity for the new dependency of kcoreaddons. The code is pretty much unit-tested and it should have a decent coverage, even if I had no way to check this. For unit tests, I had to create a fake authorization backend for testing purposes, whereas I managed to reuse the dbus backend for helper communication, so that I could even test that. For running the helper and the client in the same process, in the unit test I am resorting to making the dbus service of the helper live in a separate thread, to prevent asynchronous DBus calls from failing due to QDBus' local-loop optimization. The test is also run on the session bus. Diffs - staging/kauth/CMakeLists.txt PRE-CREATION staging/kauth/autotests/BackendsManager.h PRE-CREATION staging/kauth/autotests/BackendsManager.cpp PRE-CREATION staging/kauth/autotests/CMakeLists.txt PRE-CREATION staging/kauth/autotests/HelperTest.cpp PRE-CREATION staging/kauth/autotests/SetupActionTest.cpp PRE-CREATION staging/kauth/autotests/TestBackend.h PRE-CREATION staging/kauth/autotests/TestBackend.cpp PRE-CREATION staging/kauth/autotests/TestHelper.h PRE-CREATION staging/kauth/autotests/TestHelper.cpp PRE-CREATION staging/kauth/src/AuthBackend.h PRE-CREATION staging/kauth/src/CMakeLists.txt PRE-CREATION staging/kauth/src/HelperProxy.h PRE-CREATION staging/kauth/src/backends/dbus/DBusHelperProxy.h PRE-CREATION staging/kauth/src/backends/dbus/DBusHelperProxy.cpp PRE-CREATION staging/kauth/src/backends/dbus/org.kde.auth.xml PRE-CREATION staging/kauth/src/backends/fake/FakeBackend.cpp PRE-CREATION staging/kauth/src/backends/fakehelper/FakeHelperProxy.h PRE-CREATION staging/kauth/src/backends/fakehelper/FakeHelperProxy.cpp PRE-CREATION
Please avoid noisy merge commits in frameworks
Hi there, I was reviewing the changes in the frameworks branch from yesterday. Something I noticed was that there are a lot of merge commits that don't need to exist. Please use `gitk` to see them. The unneeded merge commits actually make it harder to follow frameworks for me. It breaks things like using `gitk --first-parent` which should show only the commits in frameworks. If you now try that out, you will see that the people who made the unneeded merges actually hide commits from the people that didn't. See for example that if you run `gitk --first-parent` commit 011b6115d2dd91e9104095f3a5065e80009ea1a7 from David is not shown. This is also the reason you should not cherry-pick from 4.8 into frameworks by the way. If you cherry-pick, then 4.8 commits show up in `gitk --first- parent` when trying to look at only the frameworks branch. That means they are just noise, so please keep that in mind too. To help out: * Do not use git pull when working on frameworks. Use git pull --rebase instead. * Alternatively (preffered) configure git to always add an implicit --rebase to the pull command: http://d.strelau.net/post/47338904/git-pull-rebase-by-default * Use gitk --all to see what would happen if you push. You should never have to create merge commits. If you do, then please clean it up before pushing. Thanks, Steve.
Re: Please avoid noisy merge commits in frameworks
Matt Williams wrote: * Use gitk --all to see what would happen if you push. You should never have to create merge commits. If you do, then please clean it up before pushing. Yes, I realised after the fact that I had created one of these so sorry about that. I've already now switched to using --rebase. If one does accidentally create one of these merge commits, how can they fix it before they push? Usually you can do something like * Run gitk to make sure the topmost commit is the merge and that you don't have any pending changes (if you do, then stash them) * git reset --hard HEAD # Undo the merge commit. * git rebase origin/frameworks # Move the commits to the top. * gitk # Make sure it worked as expected. * git push # push it. Thanks, Steve.
Re: Please avoid noisy merge commits in frameworks
Stephen Kelly wrote: Hi there, I was reviewing the changes in the frameworks branch from yesterday. Something I noticed was that there are a lot of merge commits that don't need to exist. Ugh. Yet more of this just appeared... Recent history in the frameworks branch looks far more complex than it is and is harder to follow. There are too many people unaware that they're doing it maybe...
Re: Please avoid noisy merge commits in frameworks
Dario Freddi wrote: 2012/2/19 Stephen Kelly steve...@gmail.com: Stephen Kelly wrote: Hi there, I was reviewing the changes in the frameworks branch from yesterday. Something I noticed was that there are a lot of merge commits that don't need to exist. Ugh. Yet more of this just appeared... Recent history in the frameworks branch looks far more complex than it is and is harder to follow. There are too many people unaware that they're doing it maybe... What about having a small volunteer day in which we draft some policies for git commits and eventually implement some hooks to avoid these (and other) things happening? There's some ideas for such hooks on the Internet already: http://stackoverflow.com/questions/2039773/have-remote-git-repository- refuse-merge-commits-on-push I don't know ruby or shell scripting well enough to write something sysadmin would accept, but I would definitely welcome such a hook. Thanks, Steve.
Re: Please avoid noisy merge commits in frameworks
Laszlo Papp wrote: Is there already something like that ? There is already something here: http://community.kde.org/Frameworks/Git_Workflow#Local_branches_are_always_rebased.2C_remote_branches_never Might be a good idea to extend it with git config branch.autosetuprebase always and the gitk advice. Do you think you could add what you learned? It might already be too ingrained in me to explain to others. Thanks, Steve.
Re: Please avoid noisy merge commits in frameworks
Ben Cooksley wrote: On Feb 20, 2012 7:12 AM, Stephen Kelly steve...@gmail.com wrote: Dario Freddi wrote: 2012/2/19 Stephen Kelly steve...@gmail.com: Stephen Kelly wrote: Hi there, I was reviewing the changes in the frameworks branch from yesterday. Something I noticed was that there are a lot of merge commits that don't need to exist. Ugh. Yet more of this just appeared... Recent history in the frameworks branch looks far more complex than it is and is harder to follow. There are too many people unaware that they're doing it maybe... What about having a small volunteer day in which we draft some policies for git commits and eventually implement some hooks to avoid these (and other) things happening? There's some ideas for such hooks on the Internet already: http://stackoverflow.com/questions/2039773/have-remote-git-repository- refuse-merge-commits-on-push I don't know ruby or shell scripting well enough to write something sysadmin would accept, but I would definitely welcome such a hook. First, our hooks are in python - so any changes would need to be in Python as well. Second, there is a legitimate use for pushing merge commits - namely integrating a seperate remote branch. I have no idea if it would be possible to determine if this is a local only branch merge or not. According to the question, it should be possible : '... The only exception being if the merge is between branches that exist in the central repository ...' Third, please ensure that you disable the previously mentioned auto-rebase on git pull if you are merging a reemote branch, otherwise you will duplicate many commits, in addition to triggering the hooks for all those commits (which will not happen if you just merge). The hooks could even decide to reject your push, as it will contain too many new commits. In short, if you want to merge, make sure you know what you're doing, and check the result in gitk (and make sure you understand what you see) before pushing :). Regards, Ben Cooksley KDE Sysadmin.
Re: KDE Frameworks 5: Rhythm
Thiago Macieira wrote: On Sunday, 22 de January de 2012 12.08.57, Stephen Kelly wrote: Valentin Rusu wrote: Stephen Kelly wrote: Kevin Ottens wrote: There's three main reasons for this rhythm: * KAction/QAction stuff - Don't know what's needed. If QAction needs new virtual method that would need to be determined soon. Is anyone driving that? Again, needs subtask here if it's going to happen: https://bugreports.qt.nokia.com/browse/QTBUG-20885 Well, I volunteered for this item but real life/job got a hold on me since the last meeting. But now I'm getting more time for hacking. I wasn't aware about the QTBUG you linked us to. Thanks for that. And I can tell I'm far from having a precise plan about KAction merge. But I'll try to have one in a couple of weeks. Note that feature freeze of Qt is early February. There will be a feature window after that at some point, but it will become even harder to get anything in after that especially with no clear plan. Please note that the task is for Qt 5.0 blockers: stuff that needs to happen in 5.0 because it cannot happen in 5.1 or later releases. If this is about a few methods that need to change in QAction, it's probably fine to do them even after the feature freeze. If it's a major change, it needs to happen *now*. And by that I mean this week, starting tomorrow. Yes, this was the impression I was trying to give too. Someone who does not already have a history of contribution to Qt and is not already part of the mailing list, patch tracker, and culture can't just fly by with a non-trivial patch and expect it to be submitted. In this particular case (QAction) it probably doesn't matter. QAction is in a not-maintained (done) module (widgets). That means it is not usable by QML applications which will need a new class to represent an action. It makes more sense for whoever knows KAction to make sure that the new class satisfies the needs KDE has for actions, or to drive the effort for that new class in the first place. Thanks, Steve.
Re: KDE Frameworks 5: Rhythm
Thiago Macieira wrote: On Monday, 23 de January de 2012 09.58.46, Stephen Kelly wrote: If it does belong to the garbage bin, we should consider getting some stuff into the existing class - making toLower() built into the scheme() etc. Do you have a list of such small fixes? No, I don't. If the most glaring, major flaw doesn't get fixed, what good are the small fixes? If scheme() lower cases, there is no reason for KUrl::protocol to exist. Less difference between Qt and KDE API for no lasting reason is a good thing. Thanks, Steve.
Re: KDE Frameworks 5: Rhythm
Kevin Ottens wrote: On Saturday 21 January 2012 20:49:40 Stephen Kelly wrote: Kevin Ottens wrote: On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote: Kevin Ottens wrote: There's three main reasons for this rhythm: * Qt 5.0 feature freeze is upon us now; * CMake 2.8.8 will be released in April; * it'd be nice to release KDE Frameworks 5.0 at Akademy[*]. You mean 'some of the frameworks'? They won't all be done by then. More stuff will need to get into Qt before that's possible. Yeah, I know a couple of them will need some merging scheduled for Qt 5.1 already (like equivalent to KSaveFile for instance). But if I reintroduce the few words I forgot to type which were a technology preview of I think it's doable. It means it'd build against qt master likely earmarked to become 5.1[*]. Honestly I don't see a point in aiming so early. Give no aim, no rhythm and the effort will be on the back burner forever (in any case for way too long). Let's be honest with ourselves here: that's the biggest risk we face right now. Maybe it is the biggest risk. There are big problems that affect scheduling attempts too, such as there being a lot still to do in our upstreams, and not enough people who have enough expertise to contribute to the effort doing so. Maybe a schedule will attract them. I don't know. Having monthly check points, and a bigger one in a while where we try to see how a end-user release would look with the current state (give it the name you want I'd call that Technology Preview 1) are IMO the best way to get people motivated (sense of achievement) and to reassess your plans efficiently (early feedback). It makes mistakes and 'I thought it would behave like ABC' more risky and costly. I know you're 'only' talking about technology preview, but once a technology preview is out, some people will say things like 'We shouldn't change things significantly now that the technology preview is out' and there will be long threads on some mailing list somewhere. Honestly for a technology preview we don't necessarily need a large PR around it, and you should expect it to burn your house and to change a lot if necessary. Fair enough. If the point is to get people to try it though it will need some sort of PR and 'release'. Who talked about a freeze? Not me at least. And I honestly don't think we should take decisions based on some hypothetical people ranting and some future threads in mailing list which didn't appear yet. Fear based decision taking is the best way to derail a project or have an inadequate outcome. Ok :). Lets just agree to ignore such threads if they do appear and not respond. That doesn't affect anything about what tech news outlets will write though :). Come on, it's just *almost* impossible? So still deserves to be attempted. :-) By someone, but not me. (Apart from the timezone stuff which I am willing to do, but it's likely that if I try to submit it to Qt it will be blocked with 'What does John Layt say', which I can't answer because I can't get a hold of him). On that topic John apparently reappeared recently so I'd expect some improvement. If not we should act soon indeed. Yes, I have been attempting to discuss it for a while. I'll just try to move on without his input I guess. David Jarvie did see the sense in the proposal, so that's a good start (though I think John might officially be the maintainer of the stuff in Qt). Thanks, Steve.
Re: KDE Frameworks 5: Rhythm
Kevin Ottens wrote: There's three main reasons for this rhythm: * Qt 5.0 feature freeze is upon us now; * CMake 2.8.8 will be released in April; * it'd be nice to release KDE Frameworks 5.0 at Akademy[*]. You mean 'some of the frameworks'? They won't all be done by then. More stuff will need to get into Qt before that's possible. To that effect we did some modifications to the active wiki pages: * Now we have one page per Qt version we want to target for pushing features in Qt, the Qt 5.0 page contains the really critical stuff we want to see achieved: http://community.kde.org/Frameworks/Epics/Qt_5.0_Merging Some of the stuff on that page that isn't close to done is almost impossible at this point. * command line arguments - potential bikeshed. Discussion would have been needed weeks ago on the Qt5 list for it to be possible. Is anyone driving it? If it really can't wait until Qt 5.1 there needs to at least be a subtask for it here: https://bugreports.qt.nokia.com/browse/QTBUG-20885 * KAction/QAction stuff - Don't know what's needed. If QAction needs new virtual method that would need to be determined soon. Is anyone driving that? Again, needs subtask here if it's going to happen: https://bugreports.qt.nokia.com/browse/QTBUG-20885 * Ssl stuff - I don't know. * i18n - AFAIU nothing is going to happen in that area. * refcounted quit - might happen. * locale stuff - Don't know. Depends on John. * timezone - I want to take ownership and 'do what python does' https://bugreports.qt.nokia.com/browse/QTBUG-23509, which David confirmed the sense in, but waiting on response from John. * Thiagos stuff - I don't know. If all of that stuff is going to move along, the actions need to happen on Qt lists and review trackers basically within 2 weeks or sooner. Thanks for the update, Steve.
Re: KDE Frameworks 5: Rhythm
Kevin Ottens wrote: On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote: Kevin Ottens wrote: There's three main reasons for this rhythm: * Qt 5.0 feature freeze is upon us now; * CMake 2.8.8 will be released in April; * it'd be nice to release KDE Frameworks 5.0 at Akademy[*]. You mean 'some of the frameworks'? They won't all be done by then. More stuff will need to get into Qt before that's possible. Yeah, I know a couple of them will need some merging scheduled for Qt 5.1 already (like equivalent to KSaveFile for instance). But if I reintroduce the few words I forgot to type which were a technology preview of I think it's doable. It means it'd build against qt master likely earmarked to become 5.1[*]. Honestly I don't see a point in aiming so early. It makes mistakes and 'I thought it would behave like ABC' more risky and costly. I know you're 'only' talking about technology preview, but once a technology preview is out, some people will say things like 'We shouldn't change things significantly now that the technology preview is out' and there will be long threads on some mailing list somewhere. To that effect we did some modifications to the active wiki pages: * Now we have one page per Qt version we want to target for pushing features in Qt, the Qt 5.0 page contains the really critical stuff we want to see achieved: http://community.kde.org/Frameworks/Epics/Qt_5.0_Merging Some of the stuff on that page that isn't close to done is almost impossible at this point. Come on, it's just *almost* impossible? So still deserves to be attempted. :-) By someone, but not me. (Apart from the timezone stuff which I am willing to do, but it's likely that if I try to submit it to Qt it will be blocked with 'What does John Layt say', which I can't answer because I can't get a hold of him). * command line arguments - potential bikeshed. Discussion would have been needed weeks ago on the Qt5 list for it to be possible. Is anyone driving it? If it really can't wait until Qt 5.1 there needs to at least be a subtask for it here: https://bugreports.qt.nokia.com/browse/QTBUG-20885 * KAction/QAction stuff - Don't know what's needed. If QAction needs new virtual method that would need to be determined soon. Is anyone driving that? Again, needs subtask here if it's going to happen: https://bugreports.qt.nokia.com/browse/QTBUG-20885 * Ssl stuff - I don't know. * i18n - AFAIU nothing is going to happen in that area. Yep, that one we can do without. * refcounted quit - might happen. I actually wanted to talk to you about that one. Didn't you have a patch aeons ago? What happened to it. It spent a long time in limbo because some people didn't want it the feature in Qt at all, then it was a question of how to prevent bugs in applications, but now that might have turned. There's still a long way to go for the patch though (at least several days I'd guess), even after more than 5 weeks in gerrit: http://codereview.qt-project.org/#change,10408 Regards. [*] That said this mistake of mine in the previous email could have been a lapsus in the true sense. Now that we pointed it out (and no it definitely wasn't in my plans), it makes me wonder if around that time we wouldn't end up in a situation where we'd only miss a handful of class which aren't used in API... the list we have targetted for 5.1 seems to indicate that. So a small statically linked library Which everything depends on ? :) with those class would allow us to release against Qt 5.0. Again, not making plans, but to keep in mind maybe once we get closer to a splitted kdelibs world. Again, I don't see the point. I'd prefer to keep full license to change things without complaint until we know it works and have started porting some applications to it, and have some idea of what the impact on applications actually is. Thanks, Steve.
Re: Review Request: Crash guard for KSelectionProxyModelPrivate::removeRangeFromProxy()
Aaron J. Seigo wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103421/#review8997
---
Ship it!
other than the style issue, this looks good :)
Apparently I can't review it after someone else has said shipit.
Please do not ship it.
What is the backtrace of the crash you are trying to prevent?
removeRangeFromProxy is only called when the selection changes, and
KSelectionProxyModelPrivate::selectionChanged
already contains
if (!q-sourceModel())
return;
So at least that part of the patch is questionable.
Why would the m_rootIndexList be empty at that point? If there's something
to remove then that list should not be empty.
Both should be asserted really.
The patch hides the bug, it doesn't fix it.
Thanks,
Steve.
kdeui/itemviews/kselectionproxymodel.cpp
http://git.reviewboard.kde.org/r/103421/#comment7467
this should be in kdelibs style:
if (!q-sourceModel() || m_rootIndexList.isEmpty()) {
return;
}
- Aaron J. Seigo
On Dec. 15, 2011, 8:54 p.m., Allen Winter wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103421/
---
(Updated Dec. 15, 2011, 8:54 p.m.)
Review request for kdelibs and Stephen Kelly.
Description
---
Crash guard for KSelectionProxyModelPrivate::removeRangeFromProxy()
occassionally I am encountering asserts or crashes in this method, so
this little crash guard avoids those situations
Diffs
-
kdeui/itemviews/kselectionproxymodel.cpp eca2d78
Diff: http://git.reviewboard.kde.org/r/103421/diff/diff
Testing
---
used locally for about a week and haven't seen crashes in
KSelectionProxyModel
Thanks,
Allen Winter
Re: frameworks branch now requires CMake 2.8.6 RC 2
Alexander Neundorf wrote: That leaves enable_final and setting LINK_INTERFACE_LIBRARIES to empty. I'm Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted. By default, all libraries a target is linked agaonst are in the LINK_INTERFACE, which leads to unnecessary dependencies and increased load time. The alternative would be not to set it to empty, and expect our developers to take care of it. I think this is not realistic. So I'm quite sure we still want that I was thinking about this again, and I thought that it might be changable in CMake. What would you think of making set(CMAKE_SET_LINK_INTERFACE_EMPTY ON) be the equivalent of setting it empty for each target? I'd be willing to write the patch to CMake. Do you think it's an acceptable way to do this if CMake accepts it?
Re: Where does KAuth belong?
Alexander Neundorf wrote:
On Thursday, September 15, 2011 12:04:24 AM Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday, September 13, 2011 09:41:31 PM Stephen Kelly wrote:
Forwarding to kcd which is probably more appropriate.
Stephen Kelly wrote:
Hi,
KAuth became a tier1 library in the last week. It's nice to see it
separated out.
However, it depends on Polkit-Qt, which is in `kdesupport` in the
KDE 4 world currently.
Polkit-Qt seems like something that would become a tier1 library if
that's what its developers go for.
That would make libkauth tier2, right? I'll move it to the tier2
directory soonish unless someone else does, though that in itself
doesn't mean much.
The tier1/2 subdirectories will likely go away when each library
becomes its own git repo I guess.
Then tier1/2 distinction will only be a matter of documentation
(possibly -- Actually I don't think it's a distinction that should
be
Yes, I think we will not really have three levels of dependencies, but
basically a full dependency tree between the libs.
Should there still be something which makes some library/application a
KDE application ?
Right now it is linking against kdecore basically (which includes using
the KDE cmake macros).
I'm not sure. I'm sure something obvious will fall out of the refactoring
work. There will be some kind of integration library at some (high up)
level which depends on the stuff that today is kdelibs. Presumably
applications using that will be KDE applications.
Which is related to the question where the macros and settings from
FindKDE4Internal.cmake and KDE4Macros.cmake will go.
Stuff like kde4_add_executable and kde4_add_library should get kde5
equivalents I think, even if it's as simple as
macro(kde5_add_library)
add_library(${ARGN})
generate_export_header(${ARG1})
endmacro()
But I wouldn't use the prefix kde5.
Since there is no KDE5.
The prefix should be kdelibs5 or kf5 or kf1 I think (I still think since
this will be the first version of the frameworks it should be kf1, and it
would keep people from talking about KDE5, maybe).
I'd be ok with kdelibs5_add_library.
The stuff in there is really KDE-specific (e.g. the way we install
icons, and how we figure out compiler flags, etc.).
Will there be a KDEStuff.cmake in extra-cmake-modules ?
But it doesn't really belong there, it belongs to the basic KDE
component. Will there be something like that ?
A libkcore ?
How about a KDEBuildsystem module in frameworks, which contains the KDE5
equivalents of kde4Defaults, KDE4Macros etc? KDE5 applications will want
to use those things and maybe some frameworks will too.
You mean a separate git repository ?
Yes.
I had that idea too, but it seemed to me a bit too much for just a handful
of cmake files.
Maybe true.
Beside that, it really seems like the right thing.
Or put them together with what makes up a KDE application.
Maybe the basic tier2 module.
Or higher up. I always thought that on top of frameworks (which is for
everyone) there would be an integration level for 'KDE applications' which
uses 'KDE stuff' and 'KDE integration built in' - KApplication, kde
convenience cmake macros, make sure ksycoca is run, KIcon, KUrl etc.
That's what 'KDE applications' would port to and the 'total interface' to it
would be very similar to what the KDE4 kdelibs provides currently.
Are you aware that we have in kdesupport also projects which depend on
each other (all depend on automoc, ok not anymore), then the strigi stuff,
and the different phonon repositories. But this doesn't make those
depending projects tier2 projects yet.
Yes, the tier1/2 stuff is useful for classification getting started and
identifying useful stuff, but it remains to be seen what it will really
mean.
How is the way we figure out compiler flags different to how others do
it?
One thing is that FindKDE4Internal.cmake does something which is not
recommended by CMake: if you do
find_package(KDE4)
it sets your compiler flags automatically.
A cmake-conform cmake-module should not change any settings, it should
only fill variables with contents (e.g. KF5_CXX_COMPILE_FLAGS), and then
the using application can decide whether it uses them or not.
But, to make development easier for KDE developers, we do that
automatically. This is also part of what makes an application a KDE
application.
We shouldn't expect from all our developers that they suddenly take care
of all that themselves.
Every KDE application I have seen has this boilerplate:
find_package(KDE4 REQUIRED)
include(KDE4Defaults)
include(MacroLibrary)
include(CheckIncludeFiles)
Why don't we set the flags in KDE4Defaults?
Are you recommending that if I do this (kitemmodels is a separately
buildable and installable framework in the frameworks branch. Find it in
tier1):
find_package(kitemmodels
Re: Where does KAuth belong?
Alexander Neundorf wrote:
We shouldn't expect from all our developers that they suddenly take
care of all that themselves.
Every KDE application I have seen has this boilerplate:
find_package(KDE4 REQUIRED)
include(KDE4Defaults)
include(MacroLibrary)
include(CheckIncludeFiles)
Why don't we set the flags in KDE4Defaults?
...so you would do
find_package(kitemmodels REQUIRED)
which sets a bunch of include dir and libs variables, and then
include(KDE4Defaults)
which sets compilers flags etc.
Yes, 'KDE Applications' can do that. They will likely use find_package a
bunch of more times too, or they would use find_package(kdelibs 5.0)[1]
which internally calls find_package for all frameworks, or whatever.
Then they could use include(KDE4Defaults).
However, a 'non-kde consumer of the frameworks' would do
find_package(kitemmodels REQUIRED)
include(${kitemmodels_USE_FILE})
kitemmodels_USE_FILE is generated by ECMQtFramework and currently does very
little. Currently it can't be modified, but we could make it so by renaming
it to kitemmodelsUSE_internal.cmake, and then create a kitemmodelsUSE.cmake
which looks like:
include(kitemmodelsUSE_internal)
set(CMAKE_CXX_FLAGS ...)
in cases where the library requires that. In the case of kitemmodels I don't
think we need to set any compiler flags.
As a frameworks user I would be surprised if the framework set compiler
flags automatically for me.
As a 'KDE application' developer I can of course see the reasoning, and of
course agree that it should do that.
I think this sounds quite good.
Yes, I agree.
We could also rename that file to UseKDE4.cmake, so it is similar to
UseQt4.cmake.
Yes, I agree.
Still, where will the file KDE4Defaults.cmake (or UseKDE4.cmake) be
located ?
I'd put it wherever KApplication goes and install it from there.
I'd also recommend creating and installing a kdelibsTargets file which
includes the targets for all relevant frameworks.
All the best,
Steve.
Re: Where does KAuth belong?
Stephen Kelly wrote: bunch of more times too, or they would use find_package(kdelibs 5.0)[1] Ignore the [1]. I was going to put the note about targets below in a footnote, but reconsidered.
Re: Nepomuk code moved to nepomuk-core
Sebastian Trüg wrote: With the currently ongoing split of kdelibs and kde-runtime according to KDE 5.0 frameworks Nepomuk has already partly been reorganized: kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved into the new repository nepomuk-core. kdelibs master has already been frozen for some time. kde-runtime/nepomuk master is now effectively frozen as development has moved to the new nepomuk-core repository. Hi, Does that mean that nepomuk should be removed from the frameworks branch? I had a look, and I'm not sure if the history is kept etc. Removing it from frameworks would mean that it doesn't get updated as things change, but changing nepomuk things in the frameworks branch wouldn't be mergable anyway. Shortly new repositories as outlined in [1] will be created to contain the rest of kde-runtime/nepomuk. Cheers, Sebastian [1] [http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks
Replacing the KIcon type with a factory method and is frameworks a good idea at all?
We've just had a long discussion about the future of KIcon in APIs,
which led into a discussion about what we're doing in frameworks at
all and why.
Several people don't think refactoring kdelibs into independent
frameworks is a good thing. Do we need to decide if it's worth it?
I'm posting the log for archival reasons mostly. There are several
misunderstandings in it, but those are mostly untangled later on.
The content of http://paste.kde.org/118765/ is:
namespace KIcon
{
QIcon fromTheme(const QString name)
{
return QIcon(new KIconEngine(...));
}
}
Where the content of the function is intended to be 'what KIcon ctor does'
[13:08:26] steveire ogoffart: KIcon(foo) should be replaced with
QIcon::fromTheme(foo), right?
[13:08:37] steveire How does QIcon::fromTheme work?
[13:08:45] ogoffart steveire: yes.
[13:08:48] steveire Does it use a kde pluing?
[13:08:54] steveire plugin*
[13:09:01] ogoffart steveire: it has its own implementation of the
xdg icon spec
[13:09:15] ogoffart steveire: it uses a plugin only to know which
theme to load.
[13:09:27] ogoffart that is, to read kde settings.
[13:10:06] steveire So is KIconEngine also obsolete?
[13:10:24] steveire I guess this stuff might be in the spreadsheet from randa
[13:11:37] ogoffart steveire: yes.
[13:11:43] steveire The spreadsheet is mostly silent on that topic.
[13:11:54] steveire It just says Qt needs overlay support to replace KIcon.
[13:13:34] ogoffart steveire: but we discussed at the contributor
summit, and aseigo and dfaure said that nothing really use the
overlay. (Or if they use overlay, it is not something that is in the
tier1, 2 or 3, so this could go into a kde specific library of even in
the application itself)
[13:13:47] steveire Right.
[13:13:55] dfaure nothing uses overlays is not true, kfileitem.cpp does
[13:14:16] dfaure but I suppose we could develop something that uses
QIcon::fromTheme twice and combines the results
[13:14:22] ogoffart yes
[13:15:17] - 45PAALFRM is now known as miroslav
[13:17:35] steveire Why does mpyne recommend not using the official Qt?
[13:17:58] DxSadEagle does QIcon::fromTheme implement appropriate
appropriate caching lazy loading?
[13:20:23] pinotree does QIcon::fromTheme() read also in the icon
theme of the component data?
[13:22:24] pinotree can QIcon::fromTheme() take a different
component data and/or icon loader to read icons from?
[13:23:16] dfaure the icon theme of the component data? a plugin
coming with its own icon theme?
[13:23:49] pinotree with own icons in a icon-theme tree under its
$datadir/icons
[13:24:15] pinotree this greatly avoids polluting the global icon
theme with app- or plugin-specific icons
[13:24:42] dfaure ah, own icons, not a replacement icon theme.
[13:25:05] pinotree well, nothing forbids you to put a whole icon
theme there :)
[13:25:20] dfaure a feature actually used by ?
[13:25:37] pinotree ls -d /usr/share/kde4/apps/*/icons
[13:28:42] - atomo_yawn is now known as atomopawn
[13:29:56] dfaure ah I see, even if you don't have a full icon
theme, it's still organized like one
[13:30:31] dfaure ogoffart: should QIcon::fromTheme take an
additional optional argument with a base directory for the
app-specific icon theme?
[13:30:58] steveire I presume that stuff is built into the KIconEngine?
[13:31:20] steveire I could create KIcon::fromTheme which uses that,
but still use QIcon in the API
[13:31:43] ogoffart dfaure: you can only set the theme globaly with
QIcon::setThemeName or something
[13:32:02] ogoffart dfaure: then again, the default theme name is
fetch from the KDE config while running on KDE
[13:32:20] dfaure steveire: you wouldn't have access to the icon
theme loader in qt to add paths to it
[13:32:41] dfaure ogoffart: you didn't read the above discussion it
seems ;) This is about /usr/share/kde4/apps/kgpg/icons/hicolor/
[13:33:02] dfaure the icon theme name is hicolor just fine, the
issue is for this specific icon, I want to also look into
/usr/share/kde4/apps/kgpg/icons
[13:33:37] ogoffart DxSadEagle: it has per-application cache
[13:36:13] ogoffart ah
[13:36:18] ogoffart dfaure: there is QIcon::setThemeSearchPaths
[13:36:44] dfaure ah.
[13:36:48] ogoffart again this is application global, but one can
add /usr/share/kde4/apps/kgpg there
[13:36:55] ogoffart in kgpg
[13:37:04] dfaure indeed.
[13:37:25] steveire 'dfaure steveire: you wouldn't have access to
the icon theme loader in qt to add paths to it' I don't understand
this I think
[13:37:27] ogoffart the default is also fetch from the plugin
[13:38:00] steveire Looking at the implementation of KIcon it looks
like an empty class with a magic constructor
[13:38:01] DxSadEagle that's too global...
[13:38:05] dfaure steveire: QIcon::fromTheme uses a qt-internal-iconloader
[13:38:30] steveire Let me look at the code again :)
[13:38:36] dfaure steveire: KIcon uses KIconEngine uses KIconLoader,
but the discussion here is about porting that to QIcon::fromTheme
[13:39:08] dfaure DxSadEagle: yeah it's too
Proposal to use QIcon in APIs in KF5.
Hi, I re-read the IRC log from the last email and noticed the recommendation of and API review instead of meta-discussion, which I missed at the time. That is probably a good recommendation. Posting the log was probably a bad call on my part, and we can hopefully have a more useful discussion if we leave the other thread and discuss an API instead. So here's my concrete technical proposal for icons in KDE Frameworks 5. Let me know what you think: I would like to replace the use of KIcon in apis like this: void someMethod(const KIcon icon); KIcon getIcon() const; with this: void someMethod(const QIcon icon); QIcon getIcon() const; Because KIcon does not have any data members, and all functionality comes from other classes (KIconEngine and KIconLoader), no functionality is lost by using Qt classes in the API. Because KIcon will remain somewhere in its current form porting should be a no-op or trivial, even optional. People using such an API would create KIcons as is normally done now. KIcon fooIcon(foo); someClass-someMethod(fooIcon); // up cast to QIcon KIcon barIcon = someClass-getIcon(); // Use KIcon(const QIcon ) I do not (anymore) recommend any other changes at this time, such as removing, changing or deprecating KIcon, because it seems to be (surprisingly to me I must admit) a contentious issue. Please don't be silent if you think this is a bad idea. I was surprised at the opposition to changes in the name of modular frameworks earlier. I want to know there is opposition to it if there is. I don't want to find out in 3 months time. I want to know what people expect in terms of source compatibility and what people are willing to accept. At the moment I don't know those things. Thanks, Steve.
Re: Re: QML support in kde.org services
Albert Astals Cid wrote: A Diumenge, 4 de setembre de 2011, Stephen Kelly vàreu escriure: Harald Sitter wrote: On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: 2. api.kde.org doesn't show QML elements. Problem with this is that Doxygen does not support QML (yet anyway), actually I would not know how to make this work in a sane manner considering that plenty of QML elements will be directly based of a CPP object... (in phonon we actually have the documentation in the cpp object which implements the element). So, doing this in a meaningful way would likely require using qdoc for QML element documentation. I think that's something we should consider for kf5 anyway, for the same reason. qdoc is more free now than when doxygen was created, though it might not have all useful features of doxygen. Those might need to be added. What is the point of trying to improve the worse of the two options? Albert I have no idea which is worse. I don't know what qdoc is missing. However, Doxygen doesn't support QML. So we can do one of the following: * Investigate, then add QML support to doxygen. * Don't investigate. Add QML support to doxygen or file a bug report about it. * Investigate, see what is missing/different in qdoc (which already has QML handling), add it and use that. * Ignore the issue, not investigate it, and maybe write a blog post about how doxygen sucks because it doesn't support QML. Then maybe Dimitry will add it. My searches here didn't show up anything about QML: https://bugzilla.gnome.org/query.cgi?format=advanced;product=doxygen Nokia is eventually going to realize that their customers want to document QML stuff, and will need to either add the feature to doxygen and continue recommending doxygen as they currently do, or they will make qdoc more useful. Yes, there are many reasons to stick with doxygen (we have the scripts and infrastructure using it etc). I'm saying we have an opportunity to see what else there is and we can choose to use that opportunity. Thanks, Steve.
Re: Re: QML support in kde.org services
todd rme wrote: What about adding qdoc support to doxygen? -Todd You would have to investigate if that's possible? Are you volunteering? :)
Re: QML support in kde.org services
Harald Sitter wrote: On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: 2. api.kde.org doesn't show QML elements. Problem with this is that Doxygen does not support QML (yet anyway), actually I would not know how to make this work in a sane manner considering that plenty of QML elements will be directly based of a CPP object... (in phonon we actually have the documentation in the cpp object which implements the element). So, doing this in a meaningful way would likely require using qdoc for QML element documentation. I think that's something we should consider for kf5 anyway, for the same reason. qdoc is more free now than when doxygen was created, though it might not have all useful features of doxygen. Those might need to be added.
Bro tip: gitk --first-parent
Hi, If you use gitk and are working in a git repo with lots of merges between branches, it can be overwhelming to see all the commits in branches which have been merged in (eg, the commits in the 4.7 and active branches when trying to look at the frameworks branch). The way to see commits that were actually made on the frameworks branch, and not commits that were merged in, is to use gitk --first-parent. It is documented in the git-log man page, because gitk accepts most standard git commands for dealing with refs. If you don't use gitk and don't understand git see: http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand-git/
Re: Bro tip: gitk --first-parent
Sent this too early. Meant to supply a link. Stephen Kelly wrote: Hi, If you use gitk and are working in a git repo with lots of merges between branches, it can be overwhelming to see all the commits in branches which have been merged in (eg, the commits in the 4.7 and active branches when trying to look at the frameworks branch). The way to see commits that were actually made on the frameworks branch, and not commits that were merged in, is to use gitk --first-parent. It is documented in the git-log man page, because gitk accepts most standard git commands for dealing with refs. http://www.kernel.org/pub/software/scm/git/docs/git-log.html If you don't use gitk and don't understand git see: http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand- git/ All the best, Steve.
Re: 4.7 mergable into frameworks. No need to cherry-pick
Chusslove Illich wrote: [: Stephen Kelly :] We don't have to make one commit on 4.7 == one merge into frameworks. We can just delay the merge and do it once a day or week. No one is using frameworks, so we just need to make sure the commits get in eventually or before it becomes hard to merge. Who exactly is we? If I make a trivial change in 4.7, can I forget about it and expect someone to merge it in bulk with other changes? Yes. The next time anyone working on frameworks merges, your change will be included in the merge. However, this will not work forever. As things move around and change in frameworks, the 4.7 patch will not necessarily apply to frameworks. That problem comes up independent of merging vs cherry-pick though, and we're not at that point yet. Also, if you make a change which is likely not to apply cleanly to frameworks, it's probably best for you to merge it sooner rather than wait for someone else to do it wrongly. I also find it interesting that because most KDE people are working on 4.7 rather than frameworks now, we finally have a forward-porting workflow and mindset for the first time in a long time :). All the best, Steve.
