Re: Say NO! to Qt-based Maemo!
 

Bling isn't everything. Me being able to change the theme is not worth anything if the system isn't stable on account of poor quality applications. Sad but true.

And when it comes to C being outdated, I'm sure them 100+ lines of C code commited into the main Linux kernel source tree every day is just 1995 all over again. Not to mention all the applications that form the base of everything you do on your N900 and on almost all other Linux based systems.

Ease of use is progress, bling is not.

Re: Say NO! to Qt-based Maemo!
 

Well, I disagree with the part of "learning everything again". Some basic concepts in software engineering don't change all that much from language to language.

As for learning, that's part of being a software engineer: There are always new languages and new libraries to learn. If you don't continually learn, you might be left behind eventually.

Re: Say NO! to Qt-based Maemo!
 

I'm amazed that people here think the language defines how well a piece of software is written.

I thought things like principles of good design, problem solving, you know stuff like that is what makes you a good programmer.

I must be naive.

Re: Say NO! to Qt-based Maemo!
 

I see you're new to this whole "let's flame things we know nothing about" thing.

Re: Say NO! to Qt-based Maemo!
 

I'm fine as long as there's both GTK and Qt options. Among others. I prefer to write in C or Vala, but I see nothing wrong with hacking occasionally on C++ and Qt (got to learn it bit by bit), and I'm looking forward to nice Qt apps written by other folks (as well as any GTK apps they can churn out).

I for one don't agree with the 'written KDE looks bad in Gnome and vice versa' claim. I've always been using a mix of applications (on my desktop) written in everything under the sun (Motif, GTK, Qt, WxWorks, heck, even OpenLook, and more). Me happy still.

Re: Say NO! to Qt-based Maemo!
 

Qt will be fine and happy under Gnome. If you're using the right style plugin (QGtkStyle or QCleanlooksStyle), widgets are actually drawn using Gtk - you can't get much more native than that.

(Qt on Maemo works the same: widgets are drawn using Hildon/Gtk.)

As for other platorms inside KDE (for instance), it depends on the capabilities of that toolkit. If you've set up a Gtk theme, you might be able to get close - but it's not fully native like the QStyles.

Re: Say NO! to Qt-based Maemo!
 

The problem is that too many put "It's ugly!" (which is purely subjective) against "It doesn't crash very often." (which is way more objective and you can actually count the times it happens) and prefer things that are pretty over things that are easy to develop, debug and maintain. And that's not even taking into account the difference in what code actually is run on the device.

Picking the right tool for something is usually the first step towards solving the problem in a good way. A great programmer can perform miracles even with a not so good tool but great programmers are scarce. This makes it important to pick the tool that gives the most programmers the best chances of at least not failing miserably given some time to practice.

Qt has very good documentation. The toolkit is versatile and is very actively developed and refined. This is all good. But, the easiest way[1] to harness the power of Qt is to write the business code in C++ too. With this you leave the comfy Qt corner and have to make your own design decisions and solve your own problems in a language that I find sub par for just that. Following the link posted by OP is a good introduction to at least thinking about this.

So, I'd say it's not you being naïve, since this is not a question of what makes someone a good programmer, but it's about you and many others asking, in my opinion, the wrong questions.

---
[1] Yes, there are things like PyQt but I haven't tried this out and approach this from a pure C/C++ angle.

Re: Say NO! to Qt-based Maemo!
 

As I outline above, if you're calling Qt on any of today's platforms ugly, then you've the parent toolkit to blame. Qt isn't actually defining that style, it uses existing APIs to render the widgets.

I question this. Are you saying Qt itself has these crashes? Because in some years of using it now (often pre-release, I've been using 4.7 on my desktop for well over three months now) and I'm still yet to experience many crashes caused by *Qt*. I thought I found one the other day, and it ended out (after a few days of investigation) to be my fault, not Qt's.

While this is just as subjective a statement as someone saying 'Qt is buggy', I don't think that's a statement that you can claim to *objectively* make without measurement and statistics.

I don't see your logic here.

Your point implies that the easiest way to use the power of Qt, is to not use Qt, and go back to all the headaches of C++ that Qt helps relieve you of? (QObject signal/events, most of the details of memory management - unless you want to deal with it, etc).

This doesn't really make sense to me.

It's worth noting at this point that the link of the flaws of C++, while a good read, is actually addressed to some extents *by* Qt.

It's not even that, so much as people not asking questions, and using knee-jerk reactions based on misinformed opinions.

Really, the best way to get involved in this discussion is to find someone *knowledgable* on both sides of the debate, learn from them, ask them questions, and then you'll have a balanced opinion.

For the record, at least in my experience, PyQt/PySide are pretty useful. I've used them for prototyping a few times.

Re: Say NO! to Qt-based Maemo!
 

You must have missed:
Recommended read:
Five Little Languages and How They Grew

Small languages that are yet expressive make all of your mentioned principles easier to follow.

Re: Say NO! to Qt-based Maemo!
 

You must have never used a filechooser dialog on GNOME then, from a Qt app. Or try KDevelop on GNOME ... UI is look&*feel*, with *feel* relating to the app's behaviour, and whether its surprising to the user or not. The style plugins still have a long way to go, IMO.