On Wednesday 26 of March 2014 07:58:16 Burkhard L?ck wrote: > Hi, > > kdelibs was already splitted into different frameworks repos, the same will > happen with kde-runtime and kde-workspace soon. > > The documentation has to be splitted accordingly into the different repos. > > We need to keep an eye on kde-runtime and kde-workspace and check that this > is done properly, especially for the kcontrol docbooks. > You can grep for X-DocPath, then you know the location of the code via the > desktop file and can check, if the documentation in the X-DocPath string is > in the correct repo. Right, this is something to check.
We also need to recheck the man pages and the documentation shipped with Frameworks and cleanup the terminology and the content. T.C., if you read this, please remember to fix this: https://git.reviewboard.kde.org/r/116037/ > But we still have decide how to handle some additional docbooks: > > 1) frameworks/ktetxteditor > Afaik this is the editor component used in kate, kwrite, kile, kdevelop, > krusader etc. > Therefore parts of the kate docbooks should be moved into this repo as well > (keep docs together with code) > This would help to solve https://bugs.kde.org/show_bug.cgi?id=322915 > How do we use this docbook then? > A link from the application handbook using this component? > Pull in this docbook at application build time? Is that possible? A link it's more likely to work. The same pattern that we are using with Fundamentals will become a bit more used I guess. > > 2) kde-runtime > 2a) docbooks like documentationnotfound, fundamentals, onlinehelp > Move them all into khelpcenter repo? > Or should documentationnotfound go into frameworks/kio or kdoctools? I already moved documentationnotfound into frameworks/kio, because it is used by kio-help (and I'm still not sure why it ended up in kde-runtime instead of kdelibs :) Fundamentals needs some redesign (if you remember also https://git.reviewboard.kde.org/r/116038/ and the discussion): common things can go there the problem is that it's possible to use kdoctools but not some other, higher-level components. I think that the rule for the split should be: every documentation . This is a bit complicated for widgets which are spread around in higher-level frameworks, but maybe we can find a solution (links: they are transparent in khelpcenter). (that said, Mallard would solve this problem natively, but a) I'm _not_ pushing for it, b) we need a kio-mallard first (if not to display Gnome documentation), c) we need to fix what we have first!) Maybe onlinehelp is more useful into khelpcenter. > > 2b) plasmapkg - is this obsolete? I asked on #plasma, it's going to plasma-framework; developers will move the documentation. > > 2c) nepomuk? will be replaced with baloo No Nepomuk in Frameworks. Maybe part of the documentation could be used for Baloo, but right now the 4.x version of Baloo is going to be finalized, so the KF5 version is not available yet. References for people not following kde-frameworks-devel/kde-core-devel: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization http://community.kde.org/Plasma/PW2Todo Ciao -- Luigi
