KDE 4 Development book
frans.englich at telia.com
Fri Nov 12 14:36:29 GMT 2004
On Friday 12 November 2004 08:23, Frerich Raabe wrote:
> did anybody here meditate about a KDE 4 development book yet? IMHO there is
> plenty of stuff to write about; besides the usual chapters on getting
> started, and a chapter on porting, there are certain new technologies which
> are worth a chapter or two of their own, such as KConfigXT and the Kiosk
> framework. In general, an update of the KDE 2.0 book plus chapters on major
> infrastructural changes should be enough to get away with, I think.
> So, any input on this? What topics should be covered? Who wants to
> contribute? How does the whole book-writing business work anyway (maybe
> some of the folks who contributes to the andamooka(sp?) book can say
The problem of writing a "KDE X Development Book" is that it's a _huge_
project, and requires continued man power, time, and lots of work. The result
is a book which relatively quickly becomes outdated.
That organizational problem is what I think needs to solved first: a
distributed, community process must do the writing, and a technical backbone
must allow updating, such that it can adapt proportionally to KDE's
Let me introduce the solution I for long have had for this.
The ambitious plans the guidelines group have, to write high quality
guidelines for usability, accessibility, and graphics/promo, encounters
practical problem such as; where should the guidelines be located? What
website? How are they best integrated into the KDE community, and exposed for
Combined with the noticeable absence of a much needed new KDE Development
Book(as in paper), a dead obvious lack of documentation for KDE technologies,
and a poorly organized developer site, leads to the thought that perhaps all
problems can be solved in one go...
The current plans of the guidelines group is a new site, to replace
developer.kde.org. Written in Docbook, the site would house all the so far
known guidelines, and a new one called "KDE Developer Reference", largely
consisting of the current developer.kde.org's materials.
The first striking advantage of this formation is the markup power; be it PDF
or XHTML, would references, footnotes, semantical markups, and so forth, be
laid out perfectly across all documents. Look&feel -- consistency -- would
also be achieved, largely because it's centrally controlled. The usefulness
and information density this site would have, would be high.
The value of a good developer site shouldn't be underestimated. There's a
reason to why KDE have a large threshold for contribution/infiltration, and
that common mistakes are done.
I've done research for this exciting project, and with the help of the authors
of Doxygen(Dimitre) and Docbook XSL(Bob, Smith), all technical issues are
resolved, AFAICT. The API reference generation would output Docbook, instead
of XHTML, such that it integrates smoothly, and that classes, functions, and
so forth, in texts have resolving references. Code examples would be syntax
There are much more to say about this, thoughts are sprinkled over the
kde-guidelines archive(along with cute discussions). It also redefines the
role of developer.kde.org, and opens up the question of what can emphasize
it, except the documentation..
What does this have to do with a KDE Development Book? A PDF for going to
print, would only be one of output formats that framework produces. If the
content needed modifying, Docbook's profiling would easily handle it. Any
proof-reading and work to bring that book to copy quality, would be pushed
back to the "website". The book wouldn't wither away in a repository, but
continue to grow and adapt, as the website.
Regarding publishing of a book, if that's now of largest interest, I think is
of no problem, considering what for example O'Reilly usually ships -- KDE is
a big, popular project. Also, since it would be produced with no
costs(well..) and already be markup'ed, that makes it even more attractive.
It can all be seen from another perspective: We're building a top-notch
developer site, but beneath is a book slowly but steadily growing, and one
day...Voila! Perhaps post-4.0/4.1 have such a book matured.
I have notes and much preliminary work done for this, but I need financial
stability before I start on it and have a time scale. I see no real
obstacles, except the bureaucratic maze.
I have mentioned this idea before, but the first time the guidelines group
payed attention is here(more detailed discussion):
PS. Feel free to join the kde-guidelines list. It's low traffic, and we need
clever people. https://mail.kde.org/mailman/listinfo/kde-guidelines
The kde-guidelines group think it's a good idea, what other people thinks,
needs to be asked for.
More information about the kde-core-devel