[Interest] query about QT textbooks

[Mark Summerfield]

Hi Mark,

On Wed, 11 Apr 2012 04:55:20 -0700 (PDT)
Mark Griffith <markgriffith at yahoo.com> wrote:
> .
> 
> I'd like to ask about books anyone can recommend for beginner
> developers using QT. The tutorials on the site have some value, but
> they really aren't good enough, as I explain below. If you're bored
> easily, don't read on. 
> 
> --  --  --  --  --
> 
> I'm a bit wearied by the constant use of undefined special words like
> 'binaries', 'declarative', 'parent', and sentences like "To use the
> states.png image in your application, you must copy it to the project
> directory (same subdirectory as the QML file) from the examples
> directory in the Qt installation directory." where this is the first
> time 'states.png' gets mentioned. 

It seems to me that the Qt documentation (esp. for Qt 5) is somewhat
behind the actual implementation---this will undoubtedly improve.
 
> I'm not totally computer-illiterate - I have reasonable maths skills
> as an ex-economist, and have built several websites unaided in
> straight HTML without using an editing package or code editor. I have
> written simple programs. But I do have a life outside this world, and
> would like to see software documentation conform to the same
> standards of clarity we expect from (say) people who write company
> annual reports to shareholders - which is about the same level of
> inherent complexity that needs to be cleaned up. 

Unfortunately your analogy is false. Computer programs are the most
complex pieces of engineering human beings have ever created. You and I
might write a small Qt-based application---but that application is built
on top of the Qt library (~750,000 lines of code) which itself depends
on other libraries plus the underlying operating system. Of course, by
the use of abstraction and libraries most of this complexity is hidden---
but it is still there.

> Also, I must concede that software writing has improved hugely in
> twenty years. It's gone from about 10% comprehensible to about 40%
> comprehensible, which is of course a massive achievement, though
> nowhere near good enough. 
> 
> Nonetheless, software documentation, QT included, still has a long
> long way to go before it is as lucid as it could be and should be. 

I think this depends on the intended audience. When I was responsible
for the Qt documentation (many years ago) I aimed at "at least average
C++ programmers and smart engineers and scientists with some GUI
knowledge and an awareness of how Qt worked". Furthermore, since Qt was
(and is) open source, it was possible to keep the documentation fairly
lean despite Qt's size because we didn't have to mention obscure corner
cases (since programmers could read the source if they needed to).

Nowadays I suspect that the documentation should cater for a broader and
less-experienced audience, but doing so takes time (esp. to avoid
bloating the documentation for those who already know Qt).

As for general programming there tend to be "learning" books aimed at
people with limited programming experience, and other books (such as
those I write) aimed at people with more experience.

> It could all be hugely better if software firms forgot technical
> writers and employed real commercial writers (like the writers who
> work at ad agencies and magazines) to rewrite and re-edit all these
> tutorials. That and proper footnotes _on the same page_ defining each
> term and offering extra clarity would transform computing overnight. 

I think that's a bit insulting to technical writers, as well as being
quite wrong.

I won't bore you or this list by explaining just how much time and work
is involved in writing a decent computer textbook, nor harp on about how
little the rewards are!

I've worked with writers who have the kind of background you describe:
they can be fine at documenting simple end-user applications, but I've
not yet worked with a non-programmer writer who could explain
programming in a particular language or with a particular library
because they just don't understand how things work. (And even for a
beginners book where the writer doesn't necessarily explain how things
work under the hood, the writer must still understand the inner workings
themselves so that what they do explain goes _with_ the grain of the
language of library.)

I can't say that I'd recommend C++ as the right language for a beginner
or casual programmer to learn (even with the conveniences of C++11 and
Qt, both of which make it easier and nicer).

One day, perhaps, the Qt/QML combination might be a good choice, but
right now it seems a bit under-documented, and requires C++ programming
which makes it too difficult.

So I think that the easiest route into cross-platform GUI programming is
to learn Python (ideally Python 3), and then learn PyQt or PySide for
GUI programming. (Disclosure: I've written books on Python 3 and PyQt.)

Good luck!

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Go" - ISBN 0321774639
            http://www.qtrac.eu/gobook.html