KDE 4 Development book

[Frans Englich]

On Friday 12 November 2004 08:23, Frerich Raabe wrote:
> Moin,
>
> 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
> something)?

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 
developments. 

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 
the developers?

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.[1] 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 
colored.

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):

http://mail.kde.org/pipermail/kde-guidelines/2004-September/000025.html


		Frans


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

1.
The kde-guidelines group think it's a good idea, what other people thinks, 
needs to be asked for.