Create Task
Maniphest T3814

Add dox of public API of kdb, kreport & kproperty to api.kde.org
Open, Needs TriagePublic
Actions

Description

The mission of the new api.kde.org is to provide documentation for 3rd-party developers about the API of the libraries KDE creates. Like a manual for developers.
kdb, kreport & kproperty are some of those libraries.

The new api.kde.org (as in, the content listed under "List of our products" on the start page) is generated with kapidox, from KF5. That tool creates API dox html pages (and soon qch) based on a file metainfo.yaml which it expects in the toplevel directory.

See
https://api.kde.org/frameworks/kapidox/html/index.html and https://api.kde.org/frameworks/kapidox/html/metainfo_syntax.html

Open question: should kdb, kreport & kproperty form a group, similar to KF5? Or should they be handled as separate independent products?

So task is:

  • add metainfo.yaml to the three repos
  • ask api.kde.org maintainers (ochurlaud) to include them
staniek added a subscriber: staniek.Sep 20 2016, 2:26 PM

The libs are in Playground now.
https://api.kde.org/playground-api/libs-apidocs/

I don't what that means but if sitting there means less work for me, OK. If this means less users and contributors, that's obviously not OK. Definitely "playground" tag sounds scary when it comes to projects older than KF5, sometimes developed for 12 years.
The libs form a base for Kexi and Plan at least. And KProperty is used in a commercial project.

Open question: should kdb, kreport & kproperty form a group, similar to KF5? Or should they be handled as separate independent products?

In one way this would be a bit superficial. We have such groups. I am all for flat list of libs for now, the only dependency is kreport->kproperty so far.

staniek edited projects, added KDb, KReport, KProperty; removed KEXI.Sep 20 2016, 2:26 PM
staniek added subscribers: Kexi-Devel-list, piggz.
kossebau added a comment.Sep 20 2016, 3:08 PM

https://api.kde.org/playground-api/libs-apidocs/ is part of the "old" api,kde.org content, where the old kdelibs doxygen script generates api dox html pages for all of the source code in a repo (well, as much as guided by the Mainpage.dox settings).
All such complete-repo apidox pages are still there on api.kde.org only because there is no replacement yet.

The "new" api.kde.,org content, as currently presented directly on the start page, is only about public API. And there the repo organization tree does not matter, so the term "playground" will also not escape into the generated docs (or urls) :)
It just needs the respective metadata to be added to the repo, by the files metainfo,yaml, and ochurlaud to include those repos in the generation of the "new" content section on api.kde.org.

In the end both the kdelibs-based script for the old content and the kapidox-based script for the new content will cover those repos for now. You might ask winterz to exclude those repos from the old script, if that could confuse people.