Microsoft is always well documented. Google is too most of the time.

Uh, can I see the code to their TCP stack (picking out one thing amongst thousands)? No "documentation" is better than the source code itself. Your statement is ridiculous.

-Jeff

Sorry, I don't want to offend and I don't want to get into a flame war, but the WHOLE reason other forms of documentation exist is because source code is the WORST form of documentation.

Most of the time its unreadable, and even when it isn't the parts you care about are hidden in with other parts that you don't.

To top it all off, any time you actually NEED to look at the source code itself you probably just want to see the implementation, not decipher how to build off it.

One thing that bothers me about PyQt right now is that by if one creates a program with it, users need to enable the extras-devel repository in order to use it. Hopefully this changes soon.

It's not clear to me if it will or not -- there is also the Pyside project, which is doing almost the same thing as PyQt, but allowing different licensing (as far as I know). It seemed like Pyside, once it is farther along, will be the preferred method for Python+Qt.

Currently, they're both in -devel, so you're stuck either way.

-jkq

PS. Thus, I started to port my code written for Python/Qt to C++/Qt, and boy, am I missing Python.

Ah yes, pyside is the Nokia project, PyQT is a separate project:

http://www.pyside.org/

Too bad there's two of them, oh well.

The recommended path is to use PyQt for now, unless licensing issues impede you. PySide is keeping API compatibility with PyQt, so once PySide is stable and mature, switching over will be very easy.

Guess I'll start here too... I have very little knowledge of C and C++ (or Qt), so I might as well start with Qt/C++ since that's my new year resolution...

So far I've installed QtCreator and MADDE and tried the qthello "prog"...

EDIT -> I think I'll be going for the whole QT SDK instead -> http://qt.nokia.com/downloads...

BTW -> I use Linux only (home/work)... Ubuntu for my desktop+laptop, Gentoo for my private server.

Having done some development for maemo now I would have to echo some of the comments here that it is very hard to do useful things.
By which I mean there is plenty of doc that get you as far as hello world. But that's about it.
For Witter I've had to write a customer cell renderer to make things look 'nice' trying to get any information on how to do that was a nightmare.

Also there is no focus on development tooling. as a professional software engineer, I expect to be able to code and develop in a good IDE which helps me.
I've never tried developing for apple, but given the number of apps I'm guessing they make it a whole lot easier to do than Nokia is making it for the N900.

I started using esbox, which is pretty good...but I couldn't get svn to integrate, so to use garage I found myself having to leave esbox to use less useful tools.

the api documentation does suck. I've found myself looking at the doc for certain hildon types asking 'what does this actually DO' no pictures, no description of what it's for, just the contructor and some method names.

Personally I'm trying to help by writing blog posts as I figure stuff out, in the hopes that maybe I'll make life easier for the next person.
One interesting sign. These days I find that a good portion of my google searches for stuff I'm trying to figure out, gets hits on my blog where I've mentioned that I want to figure it out ;-(

writing core logic is normally fine. writing a GUI that is anything like 'nice' or even fitting with hildon standards is a nightmare.
People say 'hildonise' this and that without any sensible doc to show how.

And some of the hildonising process is needlessly expensive. I'm thinking specifically of hildon.appMenu which is, in fact, not a menu. And cannot be used with menuitems. Which means you have to re-write menu code to create buttons instead. And if you wanted to have any hope of keeping diablo code base in step, you just got another big wadge of different code.

Particularly when it comes to trying to make an app look'n'feel like existing apps it would be nice if there was more documentation of using icons etc. or maybe the documentation just need to be put in a more consumable form.

EDIT: and whilst I think about it, the whole process of submitting things to be built can be quite frustrating. there are parts of the process with zero feedback as to what it's doing or whether your submission has even worked. frequently I've submitted to the auto builder, then had an hour or so without it appearing anywhere I can see, eg not on the builder queue even. You just have to learn to wait a couple of hours and assume it's going to show up at some point.
Then when it does show up, it only makes it ot rhe repository after it's built the 386 version, and I can only assume that's a much slower machine because it takes ages longer to do that build than it takes to do the armel build. Even though for python there is no 'build' I've frequently waited hours more for the 386 build to happen before my package appeared in extras-devel

Just to follow up on this - it has actually very little to do with PyQt itself, it's in -devel because the Nokia packages it depends on are not optified. Thus, a PyQt application in Extras would mean an avalanche of several dozen non-optified megabytes in dependecies for the user. PySide, in it's current iteration being less compact than PyQt, suffers from this problem even more heavily. We're basically waiting for PR1.1 to resolve this problem. If it does, I'm pushing PyQt in Extras(-testing) the very next day.