[Interest] query about QT textbooks

[Peter M. Groen]

Atlant Schmidt wrote:
> All:
>
>   When the world made the change to mostly Free and
>   Open-Sourced Software (FOSS), one of the things that
>   got discarded was good documentation.

Where do you get the impression that "Free" means "Free Of Charge"? I
suggest you read the GNU License and Manifest more careful before making
such claims.

http://www.gnu.org/philosophy/free-sw.html

To help you understand quicker : a little quote :

[Quote]
“Free software” means software that respects users' freedom and community.
Roughly, the users have the freedom to run, copy, distribute, study,
change and improve the software. With these freedoms, the users (both
individually and collectively) control the program and what it does for
them.
[/Quote]

>   Back in The
>   Old Days(tm), when software packages cost thousands
>   of dollars, there was money available to pay for a
>   good staff of tech writers, tech editors, and testers
>   to spend the time necessary to create good documentation.
>
>   But nowadays, the situation is that:
>
>     1. A FOSS software project has no money flowing
>        in to pay anyone
>
>     2. So the package's developers work on what
>        they're interested in which is the code.

Ever heard of RedHat? Or Trolltech? (Pun intended) RedHat employs kernel
developers and Trolltech had a lot of KDE developers on their payroll.
And don't forget some (smaller) companies like Philips, IBM, MonteVista etc.
(And before you start ranting again : I was sarcastic...)

>
>   And *THE DEVELOPERS* already know how the software works
>   so *THEY* don't need documentation (or at least not the
>   sort of documentation that a newbie would need to learn
>   how to use the package well and productively).

By now, a lot of developers use doxygen to document their software. And
yes, It is not a book, not a separate file but comment *in* the sources.
by running doxygen or even better "gmake documentation" or some derivate,
the documentation is generated. Ok. Not every developer is nice enough to
document extensively, but doxygen also generates class-diagrams,
call-diagrams which is basically all you need to start fiddling with the
software.

Normally these procedures (on how to build the software and the
documentation) are described in the README or INSTALL files in the source
directory. If you've missed them I suggest to read those also..

>   And for
>   the obscure questions that the package developers will
>   have, the documentation probably would never have answered
>   their questions anyway so they look for their answers in
>   the code.

Are you a packager? Do you know how these guys do their work? Are you
their spokesmen? If not, don't draw any conclusions based on your guesses
or frustrations.

>
>   This is why you'll *NEVER* see good documentation
>   emerging from a FOSS project.

Your experience may vary, but in my experience the documentation mentioned
above, is always sufficient to get started. And then there is always the
emailadres of the developer inside the source code to get in contact.

[Snippet rest of Rant]

>   So FOSS documentation will continue to suck.
>
>                         Atlant
>
>
> * As evidenced by the now-infamous "You're doing it wrong"
>   discussion threads. See especially the comments:
>
>     http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/
>
>
> ** Try to write a Linux device driver using the 3rd
>    (and latest) edition of the O'Reilly book "Linux
>    Device Drivers" by Jonathan Corbett and you'll
>    quickly both realize what I mean and be poring
>    through tons of Linux sources.
>

Basically you judge 4 million FOSS projects, based on two examples? Nice!
I'll admit that there is a *lot* of OSS out there that is badly documented
but on the other hand there is a *lot* of OSS out there that comes with
proper documentation (generated or not) and plenty of examples.

As for the book you mentioned "Linux Device Drivers", I think it is a
great book. It explains in detail the *structure* of the 2.0 kernel and
where drivers fit in. And that is all they *can* give as the code is
changing by the hour. If you need a guided tour on how to write a device
driver, than I think you lack the basic knowledge of Operating Systems and
C to figure out how to do it. (The examples given by Jonathan work, by the
way, although you have to adapt the calls here and there because the
parameter-list changed. But after all, agina, that is Basic C-knowledge).
Instead of just using a book, try the documentation supplied with your
kernel. (Hint : It is a directory called "Documentation" and sits inside
your Linux Kernel).

Just my EUR 0,0025ct

Kind Regards,

Peter Groen
(Open Source Developer since 1993)