Maemo moving to Qt [LWN.net]

Maemo moving to Qt

Posted Jul 16, 2009 18:31 UTC (Thu) by tstover (subscriber, #56283) [Link]

I, as well as many others, would adamantly disagree. For many, many, developers then principle reason to use Gtk+ is that it is all C. Besides the preference of language styles, C instead of C++ for libraries has countless advantages from a software engineering standpoint from compiler binary compatibility, to the techniques used build wrapper interfaces for higher level languages. Many get this point, yet still want a GUI library in C++, not thinking about times when you want to create a library that itself uses a gui toolkit.

I also would not recommend libglade or gtkbuilder.

Qt is not really C++ anyway, it's c++ and a macro language. (which in and of itself illustrates some of the limitation of C++ in the first place)

...and yes I am a C fanboy

Maemo moving to Qt

Posted Jul 22, 2009 0:44 UTC (Wed) by Tronic (guest, #59702) [Link]

While Qt not being C++ cannot be denied, I have to correct you on the
reason. Trolltech deliberately chose not to use many C++ features in favor
of better portability and I have to agree: that did make sense in the late
90's when C++ was just being standardized and when the compilers were
nowhere near supporting it properly.

Today it is a different situation. With some magic of templates one can
implement really nice signal handling that is safer and a lot less
intrusive than Qt's MOC/QObject-based system. SigC++ of GLibmm and
Boost.Signals are the best known implementations and both have very similar
features. Both can use each-other's "signals" just fine because any regular
function or functor of the right form works.

From a developer point of view, GTKmm is by far the nicest GUI library to
work with. It is elegant, it gets the job done with no extra boilerplate
and it doesn't leak memory or segfault (nor use pointers, what a
coincidence) in your everyday GUI stuff. It's a shame really that it
doesn't offer native UI on Windows or Mac and thus using it is really not
an option for cross-platform software.

Maemo moving to Qt

Posted Jul 22, 2009 8:17 UTC (Wed) by boudewijn (subscriber, #14185) [Link]

Er, no. GTKmm is merely is the nicest gui library from your personal point of view, not from the developer point of view. It is only your opinion, not a general truth. Other people find Qt much, much nicer -- and that is their opinion. Some people express that opinion rather well, like Guillaume does in http://www.telegraph-road.org/writings/gtkmm_vs_qt.html.

Personally, I think that that the Qt-is-not-C++ meme is pure nonsense caused by prejudice. If it weren't C++, my C++ compiler couldn't compile it. It can, so it is. Whether or not you like its use of generated macros and generated C++ is your opinion, but it doesn't change the language at all. They are convenient, and in about ten years of Qt coding, they haven't hindered me when debugging at all. The introspection and runtime flexibility it gives me is very valuable.

And one real fact is that people using Qt are very productive. That's easily proven by seeing all the things that are produced using Qt.

Maemo moving to Qt

Posted Jul 23, 2009 15:38 UTC (Thu) by robert_s (subscriber, #42402) [Link]

"While Qt not being C++ cannot be denied"

This is total nonsense. It is fully compliant C++. It just has a class autogenerator. Similar to how you can get glade etc. to autogenerate code for you.

"With some magic of templates one can implement really nice signal handling that is safer and a lot less intrusive than Qt's MOC/QObject-based system."

I would like to see something other than fanboyism here.

Maemo moving to Qt

Posted Jul 24, 2009 8:25 UTC (Fri) by amigadave (guest, #59782) [Link]

"Similar to how you can get glade etc. to autogenerate code for you."

Glade 3 does not autogenerate code, but Glade 2 did (I do not know about Glade 1). Glade 3 will only generate an XML description of your user interface, which you can load with either libglade or GtkBuilder.

With regards to your other comments (and similar ones, in this thread), I think that when most people say "Qt is not C++" they intend to say "Qt without moc is not C++", which is valid -- one cannot compile the majority of Qt-using code without moc. The moc-generated code is nothing to be particularly worried about, except that some people do not like the dependence on a second preprocessor. It is also true that with some "clever" C++, nearly everything that moc accomplishes can be done without the use of macros or a second preprocessor.

I use both Gtkmm and Qt at work, and find that both have their advantages and disadvantages -- there is no clear winner. Currently, the support of Qt on Maemo is not that great, in my experience, so it will be interesting to see the new APIs that become available with the Harmattan release. I look forward to an improvement over the Hildon C APIs, but time will tell.