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 indefinitely. 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 abandoned. > 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 itself. > 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. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community