Re: qtmoko and FSO
Excellent progress, Radek. Thanks, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko and FSO
On 02.06.2011 23:38, Radek Polak wrote: Hi, for those who are interested in qtmoko running on top of freesmartphone.org framework here is some update. Things are going really nice. We can now use Qt binding library for FSO which is automatically generated from fso xml spec files. It means that it's easy to use existing FSO api. It is very easy to add new api (just regenerate with one command) and compiler can find any FSO API changes. As for integration with QtMoko i have decided to add FSO phonevendor plugin. It means that there will be libfsovendor.so plugin file and you can swith between current libneovendor.so and libfsovendor.so by changing one environment variable. All future releases will have both pluging and you will be able to switch between them. It seems that both FSO and qtopia phone interfaces are nicely written and they seem to fit quite well together so i expect fast progress now. Currently QtMoko can use FSO to register to network, print available operators, make and hang call. I plan to do finish the call interface, then probably start with SMS and then i can do some experimental release. Thanks to FSO and SHR people for great framework and for help! Thank you Radek for the work you and the others have done! I imported the qfsodbusxml2cpp utility at git.freesmartphone.org as own repository [1] and added automake support to it. There is even a own repository for a library called libfso-qt [2] now which gives you access to the FSO DBus API in every Qt application without the need to do the conversion from xml to cpp again. It takes the FSO xml specs directly from a installed version of fso-specs. regards, Simon [1]: http://git.freesmartphone.org/?p=qfsodbusxml2cpp.git;a=summary [2]: http://git.freesmartphone.org/?p=libfso-qt.git;a=summary ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko and FSO
Simon Busch wrote: Thank you Radek for the work you and the others have done! I imported the qfsodbusxml2cpp utility at git.freesmartphone.org as own repository [1] and added automake support to it. There is even a own repository for a library called libfso-qt [2] now which gives you access to the FSO DBus API in every Qt application without the need to do the conversion from xml to cpp again. It takes the FSO xml specs directly from a installed version of fso-specs. Also thanks a lot for your work - i am really happy that i dont have to mess with autotools ;-) Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qtmoko and FSO
Hi, for those who are interested in qtmoko running on top of freesmartphone.org framework here is some update. Things are going really nice. We can now use Qt binding library for FSO which is automatically generated from fso xml spec files. It means that it's easy to use existing FSO api. It is very easy to add new api (just regenerate with one command) and compiler can find any FSO API changes. As for integration with QtMoko i have decided to add FSO phonevendor plugin. It means that there will be libfsovendor.so plugin file and you can swith between current libneovendor.so and libfsovendor.so by changing one environment variable. All future releases will have both pluging and you will be able to switch between them. It seems that both FSO and qtopia phone interfaces are nicely written and they seem to fit quite well together so i expect fast progress now. Currently QtMoko can use FSO to register to network, print available operators, make and hang call. I plan to do finish the call interface, then probably start with SMS and then i can do some experimental release. Thanks to FSO and SHR people for great framework and for help! Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko and FSO
Radek, Hi, for those who are interested in qtmoko running on top of freesmartphone.org framework here is some update. Things are going really nice. We can now use Qt binding library for FSO which is automatically generated from fso xml spec files. It means that it's easy to use existing FSO api. It is very easy to add new api (just regenerate with one command) and compiler can find any FSO API changes. As for integration with QtMoko i have decided to add FSO phonevendor plugin. It means that there will be libfsovendor.so plugin file and you can swith between current libneovendor.so and libfsovendor.so by changing one environment variable. All future releases will have both pluging and you will be able to switch between them. It seems that both FSO and qtopia phone interfaces are nicely written and they seem to fit quite well together so i expect fast progress now. Currently QtMoko can use FSO to register to network, print available operators, make and hang call. I plan to do finish the call interface, then probably start with SMS and then i can do some experimental release. Thanks to FSO and SHR people for great framework and for help! Good news! Let me know if you want any testing done once you SMS going. Regards, 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: QtMoko and FSO
Le 09.03.11 20:48, Gennady Kupava a écrit : Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen my favorites: 3.7 make SMS working - I still have to reboot the phone a couple of times to get all SMS 3.8 make changes in audio-path automatic, not having to go through Neotools (well, nice than editing the alsa-files) 3.9 fix three alarm-bugs: - invisible button for discarding the alarm - pressing the invisible button at the wrong time keeps the buzzer going (well, helps you to wake up in the morning) - the alarm-bell doesn't ring if the phone was turned off The changes done in v32 are still not really digested, I think. I see the challenge of moving to FSO, from a programmer's point of view, as very, well, challenging, and thus nice. But, from a user's point of view, what are the advantages? And I think you know the famous 80/20-saying: 80% of the changes take 20% of the time. The remaining 20% of the changes (bugfixing) take another 80% of the time ;) Just a question, Radek: you're doing QTmoko in your spare time? Or you're being paid for doing that? Keep hacking, Linus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO
The changes done in v32 are still not really digested, I think. I see the challenge of moving to FSO, from a programmer's point of view, as very, well, challenging, and thus nice. But, from a user's point of view, what are the advantages? The future. Support for devices other than the Openmoko GTA, i.e. HTC, Motorola OpenEZX, Palm Pre, Nokia N900, but also forthcoming devices, such as the Goldelico GTA04, newer HP devices etc. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support- most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop:( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. +1 Absolutely. -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
+1. I've only recently switched from SHR to qtmoko (v31) and I'm impressed with performance and maturity of applications. I really wouldn't like to lose that again. Regards Bernhard Am Donnerstag, den 10.03.2011, 12:00 +0100 schrieb community-requ...@lists.openmoko.org: Von: Gennady Kupava g...@bsdmn.com Reply-to: List for Openmoko community discussion community@lists.openmoko.org An: List for Openmoko community discussion community@lists.openmoko.org Betreff: Re: QtMoko and FSO (was: qtmoko v33) Datum: Wed, 09 Mar 2011 22:48:28 +0300 (2011-03-09 20:48:28) Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ 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: QtMoko and FSO (was: qtmoko v33)
Gennady Kupava, Mar. 09, 2011, 22:48 +0300: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort OK, I'd like to ask one question now. Is there a reasonable technical way to *control* qt-stack-managed Freerunner without GUI? This means sending SMS from CLI and all these small things. In other words, I'm interested in command-line interface instead of programming interface. I believe the latter is up and running, but is the former implemented? Frankly, I do not know what the answer is. And yes, in case it is like You just invoke this function from this library with proper arguments, I think I'll go and write a simple CLI wrapper, for this is just what makes Unix-like systems so usable. But if the only correct implementation lives deep in the code of qt stack, then we'd better try and separate it. Generally speaking, I guess it's convenient and powerful interfaces, rather than compatibility with existing applications, that matter more just here. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ 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: QtMoko and FSO (was: qtmoko v33)
Agree with Gennady. Look what happened to SHR! It is also necessary to fix rndis usb-host ) On Wed, 09 Mar 2011 22:48:28 +0300, Gennady Kupava wrote: Hi, I hope there is still some chances that Radek will change his dicision. From my point of view where is no real need in FSO/qt gibrid, because of following reasons: 1. qt stack has richer functionalily, better performance, and less bugs than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) 2. qt has it's own resource management, FSO - it's own, rewriting qt one to FSO one is worthless effort 3. where logs of significantly more useful, easier and non-destructive goals to rich, i can suggest few: 3.1 switch back to X11. with new graphical subsystem performance this will work great. 3.2 switch to newer qt versions 3.3 fix 100500 bugs left 3.4 add gta04 support - most important 3.5 improve performance and usability 3.6 implement new features, like: 'geek' theme, sliding buttons in answer screen ^^^ IMO this set can keep everyone busy for a while. where is also no real benefit visible from switching to FSO. qtmoko will become more complicated, more buggy, slower, harder to develop :( I afraid i'll have to stay on non-FSO version forether. And certain, this planned change worth more discussion. If someone wants FSO, better to install it on debian or with SHR. Gennady. В Втр, 08/03/2011 в 18:00 +0100, Radek Polak пишет: Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko and FSO (was: qtmoko v33)
Radek Polak, Mar. 04, 2011, 07:37 +0100: i have uploaded new qtmoko v33 images to sourceforge now [1]. [...] The list is quite short on how much of work it was. Hello, Radek! Thank you for the work you are doing. Most of the effort was to package everything with debian package system. This should be done now except for kernel which is on the list for next release. [...] My plan for next version is to fix regression if you find any, package properly also kernel and release it as stable. Plans for future is FSO framework in qtmoko. I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Thanks once more. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO (was: qtmoko v33)
Dmitry Chistikov wrote: I'm afraid it's too early to ask, but could you give an estimate on how much time it'll take to enable the use of FSO framework? Just something like about a year or, say, not less than four months. Writing simple dialer application could be matter of days/hours. Integrating all the functions so that it looks like qtmoko now will be much more difficult (i cant even guess how much). We also need FSO running on debian - i'd prefer current git version. I am not aware if there are debian packages for recent FSO. Anyone knows? Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
