@Soeren A: Doesn’t “tool doesn’t fit requirement” fit into “Bad tools”? And partly into “Bad workmen” (for choosing that tool)?

@gpoo: I think you’re asking the right questions, and the answers probably aren’t obvious. We need a list of changes we can make to improve things, rather than “it’s not fun” or “it’s too hard”, but that list isn’t easy to come by.

________________
http://www.FreeOpenMoko.com

How about “GTK just didn’t fit the requirements”? GTK’s tools are fine in my opinion and Openmoko’s project management wasn’t all that bad either. However, GTK’s utterly limited theming abilities along with bad performance on embedded hardware are the culprits in my opinion.
Mobile interfaces *need* to be snappy and have almost instantenous responses, which GTK didn’t provide for Openmoko – unfortunately.

Thus, instead of making things even slower by promoting Java, I’d suggest focusing on making GTK truly themeable and be faster overall. Example: no one I talked to could tell me how to prevent GTK from redrawing all visible UI elements while I was adding UI elements in code. The result was that the entire UI was dynamically adapted and redrawn for every single UI element I added, making the entire app take ages to load.

IMVHO, it is not a matter of language. It is a matter of what we offer to develop applications.

Do we really have a (complete) development platform for any interested developer?

How many new cool applications are being developed lately?

How many developers are excited about “Gnome tecnologies”?

How much time takes to start a very simple application? Even if written in a dynamic language like Python.

How much time the developer must waste connecting signals, adding UI Manager, figure out how to connect its custom widgets and so on?

For instance, we have Gtk UI Manager. But, it must be written in code because the UI designer doesn’t support UI Manager. Also, libglade doesn’t support UI Manager.

Gazpacho has some support for UI Manager, but it has its problems and doesn’t have the same support for the same things as Glade.

So, we can say “we offer to developers different choices”. But, more accurate will be “we offer to developers different incomplete choices”.

We stopped to offer high level widgets that allow to developers to say “To start just I can plug this and this and its done”.

Developing applications with Gnome must be fun!

So, I wonder: How fun is start and Gnome application from scratch?

We have a plaftorm good enough for ourselves, but it is not ready for conquest the world.

(ok, we have limited man/hour resources. But that’s not the point).

It is easy to get confused with so many myths and simple misinformations, but that’s why fact checking is a must with these days internet information stream

I’m not sure language/platform is the answer, but better developer tools surely is. It comes down to the apps, and how quickly they can be created and advanced.

It does seem to me like the “problem” with mobile isn’t a mobile only thing; it’s a general thing about getting up to speed on the GNOME/Gtk+ platform in general.

I also noticed Nokia committing to a Hildon/GTK+ interface for the next version of their tablet software, and keeping the Hildon/GTK+ platform through the following version of the software – that means that GTK+ is still present for at least 2 years in Nokia’s product roadmap.

So to answer your question, yes, I think that Nokia will continue to use GTK+ for at least another 2 years.

“Are you really expecting Nokia to use anything else than Qt ?”
Yes … Maemo will still use mainly GTK+.

Look at what zaurus application look like … this is what u want in your mobile … ? (Zaurus use qtopia).