<table><tr><td style="">kossebau added a comment.
</td></tr></table><br /><div><div><p>For one, Kexi is currently covered by api.kde.org, just not explicitely listed on <a href="https://api.kde.org/other.php" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/other.php</a> (similar to krita).<br />
<a href="https://phabricator.kde.org/p/ochurlaud/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@ochurlaud</a>  Do you have access to that page and could add Kexi & Krita there?</p>

<p>Kexi: <a href="https://api.kde.org/bundled-apps-api/kexi-apidocs/" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/bundled-apps-api/kexi-apidocs/</a><br />
Krita: <a href="https://api.kde.org/bundled-apps-api/krita-apidocs/" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/bundled-apps-api/krita-apidocs/</a></p>

<p>Now, there is not much content right now on the kexi pages. That is, because AFAIK those api dox pages are still generated by the old kdelibs doxygen scripts. Which organize things by the Mainpage.dox files they find in the repo. And do that in a way, that if they find a Mainpage.dox file in a folder, they will ignore content in any sibling folders below the next Mainpage.dox file at a higher level, unless there is a Mainpage.dox file in the sibling as well, which then would span a group of api dox for that section (image a tree of with Mainpage.dox files as nodes, and for the leaf nodes there is a separate api dox  section generated for any code in the folder starting at that leaf Mainpage.dox).<br />
So the file src/widget/undo/Mainpage.dox is masking any other dirs with code right now, resulting in the content visible on the linked pages.<br />
A fix would be to remove widget/undo/Mainpage.dox. That should result in apidox coverage for everything in src/ again (and that is not in EXCLUDE in src/Mainpage.dox).<br />
If you would like grouping per subfolder of src, add Mainpage.dox files into each of those direct subfolders, as new leafs to the Mainpage.dox tree :)</p>

<p>All this is for complete API dox of the complete sources code, targetted at contributors. Which is a separate purpose to what the current redesign of api.kde.org targets on, which is documenting the public API of KDE products, so targetting 3rd-party developers of libraries with published API (which of course can also be KDE 3rd-parties, when using other KDE products in own projects).<br />
Where to put the "old style" content of api.kde.org (so anything e.g. at <a href="https://api.kde.org/other.php" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/other.php</a> but also <a href="https://api.kde.org/history4.php" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/history4.php</a>), so the documentation targettted at project contributors, that is still open to discussion.</p>

<p>For the libs in the "calligra" repo since the port there is no published API yet again, noone has looked into making the installed headers usable (and thus they are not even installed ATM). So no use to be on "new" api.kde.org right now.</p>

<p>No idea about Kexi, does kexi itself install libs with a public API?</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T3755" rel="noreferrer">https://phabricator.kde.org/T3755</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>kossebau<br /><strong>Cc: </strong>kossebau, Calligra-Devel-list, bcooksley, ochurlaud, sysadmin, staniek, blazquez<br /></div>