Latest version of draft and discussion: https://mail.kde.org/pipermail/kde-community/2020q1/005944.html

FYI: I am working on a licensing policy update draft (early draft, input welcome!) that tries to split the KDE licensing requirements from the technical act and moreover introduces REUSE compatible license statements as the preferred way of stating licensing information: https://community.kde.org/Policies/Licensing_Policy/Draft_SPDX

FYI: OSI discussion https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html

@ochurlaud: I was under the impression that KApiDox is already a framework, since it is listed along the Tier 1 frameworks... Anyways, I would be great to have it providing a more general scope than just KDE specific API documentation, but I think for now it is OK to just focus on our needs and maybe during the KF6 branching phase re-evaluate if one can make it also useful for others.

In order to gain some more insights, I created a first proof of concept container (based in the OpenSuse13 CI container) to check where I will find problems in this approach. What I understood so far:

The rationale about this change is not the dependency but that we discovered a big number of unneeded uses of KLineEdit all over the KDE codebase at the KF6 Sprint. This makes it quite hard to evaluate which KLineEdit features are still relevant. Thus, the goal is to slowly start with removing unneeded KLineEdit usage.

Hi, the patch looks fine for me. Thanks for fixing this!

@bcooksley @ochurlaud actually, I would like to have a deeper look into how to make the generation of the cross-links in the scope of KF5 more reliable. Would it be a reasonable step in your opinion to try the following:

• create a Docker image that self-contained builds everything from KF5, actually being an Imagefile that lives in KApiDox
• solve the cross-linking problem in KF5 (my approach: build tier 1, build tier 2, build tier 3 in a topologically sorted list, which should be computable from the available meta-data)
• ensure that the full KF5 documentation can be built by running the image

For frameworks IMO it is quite important to have links between the individual documentations quite from the start. Due to their splitted nature, it is common that you look at the documentation of one framework and then will visit several more frameworks in the process of reading the API documentation.

Thanks Michel!

I had a chat with Michel Ludwig (the Kile maintainer): the KHTML part inside Kile is deprecated code that is currently not even used (though compiled) and just remains there for a planned rewrite of that part.

Kiten after porting:

@aacid (sorry again /o\) I read your mails in reverse-chronical order and first noticed this thread, then read your mail. Will next put the merge in the release/19.12 branch, too.

@aacid just did the manual merge for Artikulate from Applications/19.08 into master. Sorry for the problems, the problematic commit unfortunately did not land into master before some big refactoring...

I think I can make it with arrival at Friday morning.