Switch from GTK to QT (was: ASU software - pre-pre-release impressions)

[Chris Wright]

2008/5/21 Nkoli <coomac at gmail.com>:
>
> On Tue, May 20, 2008 at 1:32 PM, Carlo E. Prelz <fluido at fluido.as> wrote:
>>
>>
>> My complaint is that it would be difficult for me to put my hands into
>> the default apps. They are C++, QT, and expectedly using enough of
>> those creepy C++-isms (possibly, even those yecchy templates or
>> whereabouts). I would be comfortable with tinkering with C&GTK main
>> apps. On the other hand, I would find C++&QT main apps closed boxes (I
>> perfectly know that I could very well write C/Ruby new code on the
>> OM).
>>
> From this statement, one would think that you don't use _any_ applications
> written in C++ or Qt for the simple reason that you can't tinker with the
> code. I am sure this is not the case. You use the applications written in
> C++/Qt and play with those written in the languages you're comfortable with
> or you write your own from scratch. Right now OM needs more new apps than it
> needs shipped apps taken apart (which will probably be done by a number of
> people anyway).

In this case, openmoko is still being marketed to developers and is
still alpha software. As such, I have a reasonable expectation that I
will want to hack a fair number of the applications it ships with. So
that is a valid complaint. Of course, you could simply rewrite each
application in your preferred language, but that's a waste of effort.
Or you could not mess with the applications written in a language you
do not prefer. Or you could wait until there's a more severe need and
then learn the language in question and start working on the
application.

With desktop Linux, most things are sufficiently mature that I expect
not to have to hack them. So the language they are written in is far
less important.

Of course, one person's opinion doesn't matter much, as long as there
are plenty of people familiar with the languages that are commonly
used in openmoko. I think there are far more people who can
effectively write C collaboratively than who can effectively write C++
collaboratively.

The larger issue is extending a C++ codebase in another language.