Re: About QtMoko future
On Mon, 16 May 2011 13:08:36 +0200, Alfa21-mobile wrote: Then we need debian packages for FSO stack (anyone know if they exists and what is the current status?) and we can start using it. you can look here: http://packages.debian.org/search?keywords=fso&searchon=names&suite=all§ion=all and here: http://wiki.debian.org/Teams/DebianFSO Regards, -- Tiago Bortoletto Vaz http://tiagovaz.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
2011/5/16 Alfa21-mobile : >> Then we need debian packages for FSO stack (anyone know if they exists and >> what is the current status?) and we can start using it. > > you can look here: > > http://packages.debian.org/search?keywords=fso&searchon=names&suite=all§ion=all + a few newer versions of the packages and fso-deviced at http://pkg-fso.nomeata.de/sid/allpackages (those should be moved to Debian proper where applicable) - and a graph explaining the relations between packages and FSO1 vs. FSO2 at http://wiki.debian.org/Teams/DebianFSO?action=AttachFile&do=view&target=pkgdeps.png In practice most of the basic packaging work is there, but packages have been now untouched for a year. All packagings should be at http://git.debian.org/ (repositories pkg-fso/*). More information at the pkg-fso group's page http://wiki.debian.org/Teams/DebianFSO -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
> Then we need debian packages for FSO stack (anyone know if they exists and > what is the current status?) and we can start using it. you can look here: http://packages.debian.org/search?keywords=fso&searchon=names&suite=all§ion=all ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
On Monday 16 May 2011 10:47:56 Philip Rhoades wrote: > > I try to add QtCreator projects for all new projects and i try to make > > sure the apps work also on PC where you can debug them easily. I havent > > looked for more integration like automatic deploy and debugging on the > > device, but on the other hand scp& gdb good enough for me. > > Thanks for this detail - excuse my ignorance but how does the above fit > into your comment about qtopiamail for SMS and getting a CLI going for > SMSs in a future development? I will try to explain it. If you want to send SMS from command line it's probably not possible right now. If you want to implement it, there are two ways. One is to implement some kind of RPC call to qtopiamail application - it's the QtMoko's GUI for sending SMS. You could learn it to send SMS without the GUI. Another way is to wait until QtMoko can use FSO (freesmartphone.org) stack for telephony. Then you will be able to send SMS from command line with simple dbus call. Current status for the FSO integration is that i have C++/Qt bindings and test program [1][2] for GSM calls, SMS should follow very soon. The test program can now make and receive calls and do other useful stuff like measuring signal, register to network etc... Next step is to learn QtMoko dialer and qtopiamail to use these FSO bindings. Then we need debian packages for FSO stack (anyone know if they exists and what is the current status?) and we can start using it. Regards Radek [1] https://github.com/radekp/qtmoko/tree/master/src/libraries/qfso [2] http://activationrecord.net/radekp/pub/fso-test.png ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
Radek, On 2011-05-09 21:08, Radek Polak wrote: On Saturday 07 May 2011 17:20:50 Joif wrote: Hi list In the announcement of QtMoko v33 there were some discussions about the future of QtMoko. 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. 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? Hi, much of the questions were already answered by Timo (thanks), i will try to add some more info. To avoid confusion i will try to explain what QtMoko is. From historical point of view its: qtopia => qt extended => qt extended improved => QtMoko Please note that you cant use first three names for your projects, because they are trademarks of Nokia, so that's why QtMoko. From technical point of view QtMoko is using regular Qt as framework for GUI, networking and other nice features that Qt supports. Qt is just compiled with custom configure switches. We can upgrade Qt from upstream and receive new Qt features quite easily. On top of Qt there are additional libraries for modem, bluetooth, wireless... and programs like homescreen, dialer, bluetooth gui, media player. QtMoko is upstream of these programs and libs. They can look like dead from the GIT commit history, but they compile ok and are working well, so there is not much reason to touch them. From my point of view there is nothing rotten in QtMoko except the build system which is no longer working with newer Qt because QtScript has been rewritten in upstream Qt and is no longer working in qbuild (qtmoko build system). There are two ways to solve it - either fix it of switch the build system to something else - most probably cmake. 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)? It's hard to say now, i have just started with demo application that blinks leds and it was quite easy ;-) 4) What about Qt Mobility? If there is anything useful there we can use it. 5) Will QtMoko still remain Debian-based? (I hope so! :) ) Sure, but not only debian, you can compile if for any rootfs. I am now using SHR unstable for work on FSO integration. 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? I try to add QtCreator projects for all new projects and i try to make sure the apps work also on PC where you can debug them easily. I havent looked for more integration like automatic deploy and debugging on the device, but on the other hand scp& gdb good enough for me. Thanks for this detail - excuse my ignorance but how does the above fit into your comment about qtopiamail for SMS and getting a CLI going for SMSs in a future development? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
Wow, it would be great! :) Joif Btw, I've been thinking about integrating qtmoko to Debian. Perhaps as a Debian Pure Blend, or even building single packages. I didn't go deeper yet, but will try to share this ideia during Debconf. Actually, pabs mentioned it once to me in some debian irc channel, so strictly speaking it's his idea :) Had anyone here thought the same? It wouldn't change the current upstream development model, so radek and qtmoko contributors don't need to worry. Updating the system would be much easier for users having official Debian packages for qtmoko. Regards, -- Tiago Bortoletto Vaz http://tiagovaz.org 0xA504FECA - http://pgp.mit.edu ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
> Btw, I've been thinking about integrating qtmoko to Debian. Perhaps as a > Debian Pure Blend, or even building single packages. I didn't go deeper yet, > but will try to share this ideia during Debconf. Actually, pabs mentioned it > once to me in some debian irc channel, so strictly speaking it's his idea :) > Had anyone here thought the same? It wouldn't change the current upstream > development model, so radek and qtmoko contributors don't need to worry. > Updating the system would be much easier for users having official Debian > packages for qtmoko. > This sounds nice! I coundn't try qtmoko till now because I have a normal Debian installation with FSO-Stack, Matchbox and Zhone. Being able to use qtmoko aside would be cool. Greets and thanks for your work, Kai ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
On Wed, 11 May 2011 21:06:01 +0300, Timo Jyrinki wrote > 2011/5/9 Radek Polak : > > qtopia => qt extended => qt extended improved => QtMoko > ... > > From technical point of view QtMoko is using regular Qt as framework for GUI, > > networking and other nice features that Qt supports. Qt is just compiled with > > custom configure switches. We can upgrade Qt from upstream and receive new Qt > > features quite easily. > > Great to hear that! I obviously thought Qt Exte... QtMoko is more > stuck in the Qt 4.4 time than it it is in reality. Sounds pretty > great, maybe actually at some point QtMoko or some part of it could > be pushed back to upstream as part of the ongoing improvements in > the Open Governance model :) Especially if there is something that would > help maintaining QtMoko in the longer term. Btw, I've been thinking about integrating qtmoko to Debian. Perhaps as a Debian Pure Blend, or even building single packages. I didn't go deeper yet, but will try to share this ideia during Debconf. Actually, pabs mentioned it once to me in some debian irc channel, so strictly speaking it's his idea :) Had anyone here thought the same? It wouldn't change the current upstream development model, so radek and qtmoko contributors don't need to worry. Updating the system would be much easier for users having official Debian packages for qtmoko. Regards, -- Tiago Bortoletto Vaz http://tiagovaz.org 0xA504FECA - http://pgp.mit.edu ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
Am Mittwoch, den 11.05.2011, 21:06 +0300 schrieb Timo Jyrinki: > 2011/5/9 Radek Polak : > > qtopia => qt extended => qt extended improved => QtMoko > ... > > From technical point of view QtMoko is using regular Qt as framework for > > GUI, > > networking and other nice features that Qt supports. Qt is just compiled > > with > > custom configure switches. We can upgrade Qt from upstream and receive new > > Qt > > features quite easily. > > Great to hear that! I obviously thought Qt Exte... QtMoko is more > stuck in the Qt 4.4 time than it it is in reality. Sounds pretty > great, maybe actually at some point QtMoko or some part of it could be > pushed back to upstream as part of the ongoing improvements in the > Open Governance model :) Especially if there is something that would > help maintaining QtMoko in the longer term. For what it's worth... a bunch of folks and me have just started working on a new featurephone-client (expect a "formal" announcement later this week) which is going to use QML, so we can perhaps share some Qt code. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
2011/5/9 Radek Polak : > qtopia => qt extended => qt extended improved => QtMoko ... > From technical point of view QtMoko is using regular Qt as framework for GUI, > networking and other nice features that Qt supports. Qt is just compiled with > custom configure switches. We can upgrade Qt from upstream and receive new Qt > features quite easily. Great to hear that! I obviously thought Qt Exte... QtMoko is more stuck in the Qt 4.4 time than it it is in reality. Sounds pretty great, maybe actually at some point QtMoko or some part of it could be pushed back to upstream as part of the ongoing improvements in the Open Governance model :) Especially if there is something that would help maintaining QtMoko in the longer term. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
On Saturday 07 May 2011 17:20:50 Joif wrote: > Hi list > In the announcement of QtMoko v33 there were some discussions about the > future of QtMoko. > 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. > 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? Hi, much of the questions were already answered by Timo (thanks), i will try to add some more info. To avoid confusion i will try to explain what QtMoko is. From historical point of view its: qtopia => qt extended => qt extended improved => QtMoko Please note that you cant use first three names for your projects, because they are trademarks of Nokia, so that's why QtMoko. >From technical point of view QtMoko is using regular Qt as framework for GUI, networking and other nice features that Qt supports. Qt is just compiled with custom configure switches. We can upgrade Qt from upstream and receive new Qt features quite easily. On top of Qt there are additional libraries for modem, bluetooth, wireless... and programs like homescreen, dialer, bluetooth gui, media player. QtMoko is upstream of these programs and libs. They can look like dead from the GIT commit history, but they compile ok and are working well, so there is not much reason to touch them. >From my point of view there is nothing rotten in QtMoko except the build system which is no longer working with newer Qt because QtScript has been rewritten in upstream Qt and is no longer working in qbuild (qtmoko build system). There are two ways to solve it - either fix it of switch the build system to something else - most probably cmake. > 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)? It's hard to say now, i have just started with demo application that blinks leds and it was quite easy ;-) > 4) What about Qt Mobility? If there is anything useful there we can use it. > 5) Will QtMoko still remain Debian-based? (I hope so! :) ) Sure, but not only debian, you can compile if for any rootfs. I am now using SHR unstable for work on FSO integration. > 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? I try to add QtCreator projects for all new projects and i try to make sure the apps work also on PC where you can debug them easily. I havent looked for more integration like automatic deploy and debugging on the device, but on the other hand scp & gdb good enough for me. Regards Radek [1] https://github.com/radekp/qtmoko/tree/master/src/libraries/qfso ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future (and Qt Extended -> Qt in general)
2011/5/7 Joif : > 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
