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 ac
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
Excellent progress, Radek.
Thanks,
Mickey.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
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
> us
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
> 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
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
Openmoko community
> discussion
>
> Betreff:
> Re: QtMoko and FSO (was: qtmoko
> v33)
> Datum:
> Wed, 09 Mar 2011 22:48:28 +0300
> (2011-03-09 20:48:28)
>
>
> Hi,
>
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 t
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
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, be
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 tomato
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.
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
14 matches
Mail list logo
