| Summary: | remove private class documentation | ||
|---|---|---|---|
| Product: | [Websites] www.kde.org | Reporter: | sacha schutz <istdasklar> |
| Component: | general | Assignee: | kde-www mailing-list <kde-www> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | kde.org, winter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
sacha schutz
2011-03-24 02:39:01 UTC
easy enough to fix. and we already exclude *_p.cpp files so I'm trying to remember why we don't also exclude *_p.h there must have been a good reason, but I can't remember might be something like this: we want _p.h files to be properly documented, so we want our tools to process them. but then again we don't necessarily need the documentation publicly available on api.kde.org. so quandry. I believe this is set up properly now. Example: This class is documented with its public parts: http://api.kde.org/4.x-api/kdelibs-apidocs/knewstuff/html/classKNS3_1_1UploadDialog.html Its private parts are documented on this page: http://api.kde.org/4.x-api/kdelibs-apidocs/knewstuff/html/classKNS3_1_1UploadDialog_1_1Private.html The example you show is unfortunate because it is a class NAMED private but which actually has public parts. That was probably unintuitive, but I'm not really in that project, not trying to talk shit. As such, recommend to close this bug. I see it as the responsibility of developers, not the web team to determine what gets documented (and thus shown on api.kde.org) in any event. |