Re: Say NO! to Qt-based Maemo!
 

I develop with Qt for years. It's a really GREAT framework and not only a GUI toolkit (dbus, xml, network, graphics, sql, and much more), all that with a well organized object hierarchy, great documentation and support available.
Trolltech guys have great experience over crossbuilds and embedded system.
You really write code once, build and run it everywhere.

Before hating, please experiment it a bit, it's has very nice surprises.

Just one example: qt works with properties, signal and slot, just adding a couple of line of code you may export those on DBUS, for that reason I'm coding daemons too with qt, linking qtcore and qtdbus, doing nice things with very little coding.

Anyway you are always free to use glib, gtk, dbus, expat, libc, stdc++, vala, and mix all the other libraries, finding documentation in several place without a great offline crossreferenced help, playing with autotools and so on if you feel better :)

In the long term I think that Nokia wants to provide for its devices an integrated IDE like XCode for apple.
The difference is that here the code is free, and you have bindings for a lot of language and not that objective-c crap.
You are always able to mix qt with other libraries c/c++ code.

So IMHO it's a nice line I'm very happy for that.

Niko

Re: Say NO! to Qt-based Maemo!
 

Why should i learn yet another language? I think anybody with basic C knowledge is able to code something in C++/Qt. Vala is a new language, C++/Qt is not a language, but an addition to C++

Re: Say NO! to Qt-based Maemo!
 

Taking into account how few of the members of the Maemo community actually are developers of any shape and kind, questions about changes in the basic workings of the system will always end up a tad frantic. To me, this thread has more of that in it (without forgetting that OP and you actually are developers) than actual technical concerns in regards to how it will affect the device.

Regarding MOC, I do wonder what the equivalent tool when developing GTK+ applications is. I develop GTK+ applications without describing the GUI of my application in some metalanguage so equating "using MOC to develop Qt applications" to "using GTK+ (the library and headers) to develop and run GTK+ applications" comes across as a tad off target. Qt brings MOC to the table together with libraries and headers.

This leads to two of my actual concerns: code size and performance. The N900 is limited as it is (without serious tinkering) and to more or less direct much of the future development along a line with bigger binaries that depend on a larger application stack might not be the best.

Of course this has to be weighed against the potential ease in developing or porting new applications but to just brush it over with "C sucks, C++ rocks" as I've seen in other threads here is to, in my opinion, overlook some of the real consequences.

Regarding armchair shed painting, I agree. Getting involved is the best thing but it's not an option but for a select few. As you yourself state later on in the thread, the quality you need to be able to produce is proportional to how important the component is.

Re: Say NO! to Qt-based Maemo!
 

The strength of Maemo/MeeGo is that you can use more than one language and toolkit, which is great for developer choice.

Qt and GTK+ are "toolkits". If you are a bad craftsman, it does not matter how good your tools are. If you are a good craftsman, you can create good results even with suboptimal tools.

It's not about Qt vs GTK+, it's about good and bad UI design.

Of course, if you want perfect platform integration (and the right widgets), you have to go with Hildon for Maemo 5 (plain GTK+ is not enough to make your UI fit in well) and if you want perfect integation into Harmattan, you have to use DUI (again, plain Qt will probably not be enough).

Say NO! to negative threads like this one. Invest your time in making apps better. You don't have to be a developer for that.

Re: Say NO! to Qt-based Maemo!
 

Weak argument. Between learning a new language and learning a new toolkit, the former should always be easier (unless it's a big language - some call it a foundation of languages - like C++). Also, the quality of your c-based C++ code would probably not be very high.

Re: Say NO! to Qt-based Maemo!
 

Yeah, I had positive experiences too, nice guys (and it's not that bad even when we disagree about something). I can understand some people preferring certain technologies, but occasionally it gets from a 'why I like XYZ' to a 'my tool is better than your tool' dispute which rarely brings good results. For the record, I like Qt better even though I used both in the past, think gobjects are a bigger hack than moc, so there, let the flame begin :) But it's not really a fight. Maemo/MeeGo is in the unique position in the embedded arena that you can have both (and more) toolkits, code for whatever you like. Dissing Nokia for not pushing your favourite tool is IMHO pointless. Qt people could have said just the same during Maemo's GTK+ phase.

Re: Say NO! to Qt-based Maemo!
 

Are you nuts?

If you've never used Qt, try it. It is truly outstanding.

My only complaint with Qt is performance, but this will become less of an issue as devices continue to mature.

Edit: Sorry; directed at OP to avoid any confusion. :)

Seriously, spend a few months working with Qt and you'll get it.

Re: Say NO! to Qt-based Maemo!
 

I agree about quality of c-based code, but it's a way to start coding and to "meet" C++.

You totally missed in the other matter. If i learn vala, i should also learn bindings for GTK, Gobject .dbus.vapi, kernel26.vapi ... .. .. .and so on.

Qt lets you use kernel headers and other libs as you like and already know.

The question is thae same. Why should i learn another language and do _everything_ in a different way rather than learn some new things and do others as i already know?

Re: Say NO! to Qt-based Maemo!
 

DEB is couple of ways technically inferior than RPM.
Let's just name the couple: RPM supports embedded GPG-signatures natively and transactions, DEB does not. Politically RPM is chosen by LSB, and compatibility between Linux-systems is never high enough.
http://wiki.openvz.org/Package_managers#Commands

What it comes to programming languages, for dynamic programs use Python or Java because GC and optimization possibilities. For device drivers and microkernel C and when needed C-embedded assembly. For other non dynamic memory applications what ever you like, but because there is Python interpreter already probably running on the machine in shared memory, why don't use Python (or same for goes for Java but not in Maemo/Meego unfortunately).

Before when QT was only GPL, GTK was the better choice. Now when QT is LGPL, I see differently and maybe like QT's OOP from the ground up better than GKTmm which is like a small kludge to make C interface to OO-one.

IMHO, Ugh

Re: Say NO! to Qt-based Maemo!
 

Okay, here is my 2 cents about the matter.

I don't like Qt. However, I like GTK and stuff even less, because there is no viable development environment for them.
Qt Creator just barely passes my requirements, and there is no IDE that supports Hildon/GTK development on Windows, sorry, so it is out of the question for me.

It makes no sense that you don't like Qt because it uses C++. You know, they actually TEACH C++ at school. If you didn't get it, it is your loss.
I would anytime prefer a C++-based environment. (However, my favourite language of choice would be C#.)

By the way, GTK+ WILL remain an official toolkit for Meego because Moblin already uses it, so no complaints there.