rationale for ASU (and change from GTK to Qt)

Jisakiel jisakiel at yahoo.es
Sat Jun 28 03:32:53 CEST 2008

Whatever the environment is, IMHO it should be coherent over all. Obviously the ideal solution would be indistinguishable QT or GTK apps, somehow like the gtk-qt theme acts in kde to hide the differences from qt apps to gtk. However file selectors, for instance, keep being different, spoiling the consistence of the experience. 

As I am not sure if making qtopia and gtk functionally equal is even possible, I'm all for a dual stack, somehow similar to the new framework vision. Below dbus, a single set of apps and *most important* apis share everybody's efforts to make the phone plainly *work*. Suspend issues, gsm, etc. 

Above, however, I'd fight for consistency over development freedom. I find a usable phone quite more important than a usable desktop (perhaps for being used to windows and half-broken linuxes to be used to find quirks), and for that you need consistency among a lot of other things. It's not just that the applications look different (such as QT vs GTK), it's that they act subtly different (file selectors, but also focus policies configured in different places, cut and paste behaviour, etc etc), which drives mad the user as he can't figure out the expected result of his actions. 

To give two examples, I'd say the series 60 nokia phones are quite well designed in that respect. I've been using them since 7650, I've gone through 3 different models, and all of them acted *exactly* the same. Copy / paste through all the applications, same *keyboard shortcuts* (quite important when you get faster), for instance in the menu, same way of switching apps, same contact manager or sms (which is far from perfect BTW, as I don't get along too well with the metaphore of "everything goes to the inbox"), same integration of all the apps between theirselves ("send -> via bluetooth, via sms, via MMS", mentioned copy paste, input methods -though dictionary should be present as well in single text fields-, etc). 

And, for me, old B/W series 40 are just perfect in that regard. When you get used to one other phones seem just *clunky* and unbearably *slow* and twitchy. And the same happened to me with the ipod (3G), which I believe it's a big part of its success. 

Only way to get this kind of consistency would be having full integrated sw stacks, not mixing GTK and QT, and of course working a lot on those boring usability issues :P. That's why I'm all for a dual stack, independent: if contacts, sms, etc. are shared between them (sounds difficult though), switching would be a similar matter as booting GNOME or KDE. Just a matter of taste... And although in KDE I usually open firefox (to get my passwords and extensions), and in GNOME I burn with k3b, appart from that you can get a very consistent and predictable experience in both. I vow for the same ways in openmoko... Worst for me would be the 8-years-ago linux experience: lots of incomplete and inconsistent apps, unpredictable behaviour while mixing, etc. Let's hope it doesn't take so long for us. 

And sorry for these long emails, while studying I tend to get distracted and "--verbose" :P. 

--- El sáb, 28/6/08, Esben Stien <b0ef at esben-stien.name> escribió:
De: Esben Stien <b0ef at esben-stien.name>
Asunto: Re: rationale for ASU (and change from GTK to Qt)
Para: "List for Openmoko community discussion" <community at lists.openmoko.org>
Fecha: sábado, 28 junio, 2008 3:58

"Ron K. Jeffries" <rjeffries at gmail.com> writes:

> the rationale for the decision to switch from the original GTK based
> OpenMoko

There will be a fork here at one point. There's a good bunch of us who
wants a standard GTK+ environment as the main guis' for the
phone. There's even some that don't want any QT on the phone, at

I just hope that the existing applications has been properly
engineered, separating the core from the UI (MVC, three tier, PCMEF)
so that it's just a matter of speaking a common protocol.

Esben Stien is b0ef at e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n

Openmoko community mailing list
community at lists.openmoko.org

Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080628/d4af1a63/attachment.htm 

More information about the community mailing list