<div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">in any case, maybe the discussed points should go to the KF6 workboard?</div><div dir="auto"><a href="https://phabricator.kde.org/project/view/310/">https://phabricator.kde.org/project/view/310/</a><br></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Whatever decision is made here, imho there should/must be the objective to get it fixed for KF6.</div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Dominik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>> schrieb am So., 22. Dez. 2019, 00:55:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly:<br>
> On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:<br>
> > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:<br>
> >> Great, Grantlee is now available at git@git.kde.org:grantlee.git.<br>
> >> <br>
> >> I've pushed a few commits to make it depend on ECM etc.<br>
> >> <br>
> >> Once the review period is finished it can be part of KF5 releases.<br>
> > <br>
> > There are quite some things which yet need to be done for now:<br>
> > to be a true KF module there is a set of policies which needs to be met,<br>
> > see <a href="https://community.kde.org/Frameworks/Policies" rel="noreferrer noreferrer" target="_blank">https://community.kde.org/Frameworks/Policies</a><br>
> > <br>
> > 1) Framework directory structure:<br>
> >     moving stuff into src/, autotests/ & docs/<br>
> > <br>
> > 2) Framework documentation:<br>
> >     current system needs adaption to both online (KApiDox) and<br>
> >     offline (ECMAddQCH) systems<br>
> <br>
> Cool, I wonder if there's another multi-library framework for comparison?<br>
<br>
With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their <br>
multiple libs.<br>
<br>
With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit <br>
(not involved there),<br>
Olivier (cc:ed) should be able to hint you what is possible.<br>
<br>
> > Another challenge would be moving into the KF5 namespace for the library<br>
> > artifacts (at least I would expect/recommend this to happen, for<br>
> > consistent<br>
> > user experience)<br>
> > a) include dirs below subdir KF5/<br>
> > b) CMake modules with KF5 prefix<br>
> > c) CMake imported target in KF5 namespace<br>
> <br>
> I don't support changing things like this in the KF5 timeframe.<br>
<br>
IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, where <br>
the namespace gives consistent developer experience and product messaging.<br>
<br>
Having Grantlee being a special kid, with unregular CMake modules names and <br>
differently namespace imported CMake targets, makes things more complex.<br>
<br>
Being consistent is what we so like about Qt, and KF should not stay behind, <br>
no?<br>
<br>
Perhaps joining the "Release Service" (formerly known as "KDE Applications") <br>
is a better place then, it also contains a set of libraries already.<br>
That would serve the purpose of having releases happening regularly.<br>
<br>
Cheers<br>
Friedrich<br>
<br>
<br>
</blockquote></div>