Excellent progress, Radek.
Thanks,
Mickey.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
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
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
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
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
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'
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
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
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
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
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
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
. 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
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.
14 matches
Mail list logo
