Finally I've downloaded a image and installed a maemo5 SDK into it. I've thought that I'll give a try to create a software that would help my life. And while Qt installation script downloads it's own sdk, I started to think about qt. Is it allready the choice one could make and create any piece of software possible to n900? are there any limitations?

I'll need at least proximity sensor and gps for my app (proximity sensor isn't 100% necessary but it would improve the usability).

My idea in a nutshell: when conditions are met with proximity sensor, app stores gps coordinates(the gps tracking should be on at the background to shorten the delay of getting the position) and maybe possible notes linked to the location point. then one could afterwards see the distances and notes if available.

Should i pick qt? if not, will it be hard to port the app into qt afterwards? is there a point to write an app to gtk anymore?

First things first, can a moderator move this to Development.


GTK or QT can be used just as much as QT or GTK. Right now GTK is the "primary" supported development environment for Fremantle/N900. QT is the "secondary". Both are being built and supported by Nokia.

This changes drastically in Harmatten/M6 (Maemo 6), QT will be the primary, and GTK/Hildon will no longer be a Nokia project but will be a community project. The QT stuff is owned and being built on Fremantle by Nokia employees. In addition QT for S60 is being pushed also by Nokia and built by Nokia employess. Nokia long term plan is looking to bring pretty much all there stuff together using QT. And for them it could win them the bank (it really is an potential setup for a check-mate move in the mobile market.)

So right this moment, GTK has momentum because it has been used for the last 3 devices (770, N800, N810) and now the N900. However, QT has been available from Nokia developers on the N800/N810 and now also the N900. But it has not been pushed at all -- it has really been sitting on the side lines.

My personal opinion is that shortly you will see Nokia start pushing QT a lot more on Fremantle devices because Fremantle will be the "beta" QT device for Maemo 6. They will want a library of QT products available for M6 when they release the M6 devices.

So, in my "personal" opinion, QT will be in a lot stronger position in M6 then GTK is in right now.


Depend. In C++, afaik no. In Python yes, my understand is the Python-GTK bindings are REALLY good. the Python-QT bindings are not their yet.

Depends. ;-) Writting an app in GTK is a lot easier currently (I think) because most the samples are primarily geared towards GTK here.

Porting, if you keep your interface code separate from the application logic, then porting could be fairly simple. (And it is entirely possible that Nokia will do all the heavy lifting work for GTK on M6 before they give it to the community -- meaning all the GTK apps would run unchanged, but I wouldn't count on it.)

QT's advantage is that it has been used to port things from a LOT of OS's you can create an app on Windows and pretty much just recompile it on Linux or Mac and have a working app. They are working on making this work just as well in "their" mobile space.

And that is what Nokia was betting on when they purchased the Trolltech company (QT's original owners). And they have apparently not spared any expenses in doing this -- they have worked very hard at making QT as attactive as they can. And making sure the binding layers are being built (or purchased).

Nathan.

There is a long and interesting discussion going on the maemo developer list.

Care to elaborate ? If you mean PySide is not really for the masses yet, you can still use good old PyQt, which is (still) API compatible (unless you really-really want to be under LGPL).

PS. The Nokia toolkit is usually written as Qt, QT is the Apple media framework (QuickTime), just to avoid confusion

Yes, PySide is what I'm talking about, PyQt might not be what a developer can use/accept (depending on what they are doing).

As for QT vs Qt, I'm familiar with QuickTime and didn't even think about that people might get "confused" by it since QuickTime isn't even available on Linux or Maemo. But now that you mention it, I do see that Nokia uses Qt all over the place. Thanks!

Nathan.

Just to avoid mistification - the only reason not to use PyQt at the moment is if you have distribution-ready (likely) commercial software that uses Qt under the LGPL license and really don't want pay for a (not that expensive) PyQt license. There is no point stalling python-qt development 'waiting' for PySide to mature - PyQt is a quite complete and release quality binding and switching from one binding to the other is trivial. The development status of PySide should not influence the choice of going GTK or Qt.

PS. Not to mention the far from impossible event of Riverside LGPL-ing PyQt when PySide starts nearing release quality.

If you want to start programming right now AND don't plan to develop and use your program for longer than 1-2 years GTK is OK.

But if you are planning long term, Qt is better choice. Also when you start now, your application reach maturity in 6-8 months. In that time Qt solutions for Maemo 5 should be well established and preparations for Maemo 6 will go with full power.

Note however that at this time Qt is in transitional period. First release of Qt prepared fully for Nokia (with Symbian and Maemo in mind) will be 4.6 which is in Technical Release stage.

While I have no coding knowledge of the Qt, here are few things that may affect each developer's decision making process.

• The Hildon toolkit (based on Gtk) is ready to be used right now in the Maemo 5 SDK. It has full support for the widgets and UI used in Maemo 5 and N900.

• There's much more complete set of examples and tutorials on how to use Hildon/Gtk to create Maemo 5 UI. See e.g. Graphical UI Tutorial

• Maemo Qt does not currently have support for the Maemo 5 specific Hildon widgets. What you can do right now with Qt is UI which is more similar to Maemo 4 than Maemo 5. The work to update Qt to support Maemo 5 is ongoing, see Qt Hildon Widgets. Note that currently there are no promises on the schedule, when that work will be complete.

• Given that it's highly unlikely that Maemo 6 UI will be exactly like Maemo 5 UI, it is likely that UI coded with Qt widgets for Maemo 5 will have to be re-coded with different set of Qt widgets for Maemo 6. Note, not all widgets are likely to change, but several can. This is just a guess, because I don't know Maemo 6 at all.

• Whether it's more work to recode 1) Maemo 5 Hildon UI to Maemo 6 Qt, or 2) Maemo 5 Qt UI to Maemo 6 Qt... Probably nobody will be able to give comprehensive answer right now, but it's definately likely that work will be needed, no matter what you do.

• According to some public S60 blogs, the Qt widgets that will be used in Symbian will be different than Qt widgets in Maemo. So you will have to re-code the UI to use different widgets if you want to support both Symbian and Maemo platforms.

• UI's in desktop applications (Mac, Linux, Windows) are obviously totally different from mobile finger-optimized UIs, so desktop Qt applications already use the standard Qt widget set rather than mobile optimized Qt widgets.

• Hildon/Gtk will have support in Maemo 6 / Harmattan. It's community support, not "corporate support", but there are very talented people involved, maybe even some of those who coded the Hildon in Maemo 5.

Just a small note. Switching a toolkit is a HUGE effort, as it's not just about widgets. Compared to that, updating widgets or dialogs is a walk in the park. Thus, IMHO, 1) is very predictably the larger effort (unless you meant Maemo 6 Hildon in 1) ).

You can't really compare Gtk to QT and say 'one is better/worse than the other', or 'you should switch'. The Gtk toolkit has a C interface, QT is C++.

If you want to program in C, or Vala, use Gtk, if you want to program QT you'll have to use C++. (If there's a wrapper for C -- sounds unlikely -- I'm unaware of it).

I for one will never program in C++, so an UI based around QT isn't as attractive to me as a Gtk UI.