Hi all, in any case, maybe the discussed points should go to the KF6 workboard? https://phabricator.kde.org/project/view/310/
I indeed believe that consistency in the KF5 world is an important feature, so Friedrich does have a point here. Other framework additions had to adapt as well (what comes to my mind is renaming of KQuickCharts or KCalendarCore). Whatever decision is made here, imho there should/must be the objective to get it fixed for KF6. Best regards Dominik Friedrich W. H. Kossebau <kosse...@kde.org> schrieb am So., 22. Dez. 2019, 00:55: > Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly: > > 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? > > With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their > multiple libs. > > With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit > (not involved there), > Olivier (cc:ed) should be able to hint you what is possible. > > > > 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. > > IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, > where > the namespace gives consistent developer experience and product messaging. > > Having Grantlee being a special kid, with unregular CMake modules names > and > differently namespace imported CMake targets, makes things more complex. > > Being consistent is what we so like about Qt, and KF should not stay > behind, > no? > > 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. > > Cheers > Friedrich > > >
