2011/5/7 Joif <fdvj...@vodafone.it>:
> But to date, I have not a clear vision about the current situation and the
> future of QtMoko, so I want to ask some questions to developers.

I'm a Debian developer, but not QtMoko developer. I feel though that I
can answer some of the questions from my perspective.

> 1) QtMoko is based on Qt Extended, is this "Qt base" still in development or
> is it an ended project? I mean, the main work on QtMoko is about bringing
> new and improved code or about solving bugs?
> 2) Is there a new environment, "in step with the times", that could be
> convenient to use as a base for a new QtMoko?

Qt Extended was a project formerly known as Qtopia, and created by
Nokia (Trolltech), and abandoned in 2009. Qt Extended Improved
(http://wiki.openmoko.org/wiki/Qt_Extended_Improved) was found by the
community to continue from there. AFAIK there has not been much
development besides bug fixes, although well the amount of also new
things radek and the people helping him have put to QtMoko is
impressive to say at least.

When talking about a base, the Debian 6.0 is a really good base for
QtMoko. When talking about the Qt Extended Improved put on top of it,
it's relatively easy to say that it's not the future proof way - at
least there will not be much incentive to start rewriting big parts of
it, since the actual APIs used to do those are obsoleted upstream. Qt
Extended Improved would be needed to be maintained as its own upstream

So far QtMoko is doing great and is an awesome out-of-the-box
experience, but if one wants to think about longer term future, there
is this chance: start investigating porting Qt Extended Improved /
QtMoko applications to upstream Qt, on top of the Qt Lighthouse branch
(I guess will be included in Qt 4.8 release properly). The Qt
lighthouse is essentially abstraction of the lowest graphics layer so
that like Qt Extended, Qt applications can be again directly run
directly on top of framebuffer instead of X. Maybe that way, with a
simple full screen window manager, could be a way forward?

> 3) If FSO, how many parts of the current QtMoko have to be rewritten? Will
> FSO be more difficult to use (in terms of writing new code)?

I don't have much knowledge of QtMoko, but indeed switching to FSO
would help avoiding writing multiple modem drivers for different
platforms. For FreeRunner, the current one in QtMoko is working quite
well though, and again all the connectivity code is already written in
Qt Extended. There is also oFono in addition to FSO when talking about
projects including modem drivers.

> 4) What about Qt Mobility?

Qt Mobility is an extension of various libraries to Qt, and might
include some of the stuff that was abandoned when Qt Extended was

> 5) Will QtMoko still remain Debian-based? (I hope so! :) )

I guess it has shown to be worthy base :) It also helps to concentrate
on purely the Qt / applications side, which is a big enough area by

> 6) Is (or will be) there a way to write new apps (or modify extisting ones)
> in a relative easy way such as using Qt Creator?

Well indeed yes, if the porting from Qt Extended to Qt 4.8 / Qt
Mobility would be evaluated (is it any semi sensible amount of work to
get it started) and done. Qt Creator also allows plugins, like "QtMoko
plugin" to automate application deployment et cetera.


Openmoko community mailing list

Reply via email to