Review Request 111686: KPluginFactory macros port
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111686/ --- Review request for kdelibs and David Faure. Description --- Make K_EXPORT_PLUGIN work with Qt's new plugin system This patch changes the K_EXPORT_MACRO and the class it generates to be compatible with Qt's new plugin / metadata system. It basically replaces the old macros around q_plugin_instance with the new ones, using Q_INTERFACES. There's also a setter for the args, which are used to pass metadata into the plugin. Otherwise, this is the minimal change, to make old plugin factories work atop the new framework. This change is source-compatible, but the right .moc file when this macro is used from the .cpp file. Diffs - staging/kservice/src/plugin/kexportplugin.h cc5d58b staging/kservice/src/plugin/kpluginfactory.h a5ea21b staging/kservice/src/plugin/kpluginfactory.cpp 6bd2350 staging/kservice/src/plugin/kpluginfactory_p.h 09fcfe4 staging/kservice/src/plugin/kpluginloader.cpp 945c75b Diff: http://git.reviewboard.kde.org/r/111686/diff/ Testing --- Loaded plugins using KService, KPluginLoader, QPluginLoader and Plasma::PluginLoader, all work as expected. Thanks, Sebastian Kügler
Review Request 111688: QVariantList-based ctor for KPluginInfo
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111688/ --- Review request for kdelibs and David Faure. Description --- This patch allows KPluginInfo to be created from a QVariantList, as it is typically passed in from KPluginFactory (using the patch which changes the macro there). Diffs - staging/kservice/src/services/kplugininfo.h c08 staging/kservice/src/services/kplugininfo.cpp bd1eaec Diff: http://git.reviewboard.kde.org/r/111688/diff/ Testing --- Works with plugins built in the right way: A valid KPluginInfo is created from the plugin's metadata. Thanks, Sebastian Kügler
Re: Proposal for branching policy towards KF5
On Wednesday 24 July 2013 10:23:46 Michael Pyne wrote: On Tue, July 23, 2013 14:20:39 David Faure wrote: On Saturday 20 July 2013 23:04:10 Michael Pyne wrote: This is a labor-intensive task, but it's easy to centrally-manage without having to rely on many different module maintainers or core developers for each git repository to update their own metadata in projects.kde.org I volunteer to help. (assuming we can get the sysadmins to add that). I didn't understand that. To add what? To add a scheme within the projects.kde.org repository administration interface for each individual repo administrator to fill out which branch is appropriate for each of our 3 overarching development tracks. They would then need to add something to export that information back into the XML database. Similar concerns about how this could even realistically work were what lead me to making the kde-build-metadata repository in the first place; it's a lot easier just to have a single spot for that metadata which anyone can update, not just a repo admin or sysadmin. Yes, definitely. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. First note: There's a lot of different mailing lists with at least some interest in this discussion, so I've mailed them all for informational purposes... but let's keep the discussion limited to the kde-core-devel mailing list! Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). For those with no clue what I'm talking about, the original thread from kde- core-devel is available from [2]. A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? Cheers, Albert I put the effort into doing this as it would also help make the implementation of some kdesrc-build misfeatures relating to dependency-data additions a bit easier, as there's no need to construct an AST and a parser. Additionally it would permit 'soft' dependencies, which are useful for modules that can utilize optional features but don't have required dependencies on other git modules. However that can, and probably should, be considered separately (though I'll take comments now, if you have them). [1]: http://community.kde.org/Infrastructure/Project_Metadata [2]: http://markmail.org/message/4l3yqerga7mfiit5 Anyways, thanks for your interest and please let me know if this will work to solve the problem at hand. If so I will start on integrating within kdesrc- build, and working with the sysadmins to support within the continuous integration infrastructure. Regards, - Michael Pyne
Re: Proposal for branching policy towards KF5
On Thu, July 25, 2013 22:44:47 Albert Astals Cid wrote: El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. snip A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] Well it would certainly be possible to *keep* support for whatever you're doing now with projects.kde.org, that isn't going away at this point. But since the concept is complementary, it would make sense to try to end up on one solution. At least this way it should be easier to fixup the branches for groups of modules at a time! ;) I'm not familiar with the i18n scripts at this point but I would volunteer to help with any needed porting. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Kind of (dependency data is one part of kde-build-metadata). It is true that neither requires dependency info. In the event, some prototyping of the result of making *all* of our deps go in the file is rather unsatisfactory so I'll be dropping that for now (the hard work is already done in case we decide to investigate later though). Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? dependency-data would not affect you at all. The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
