Re: About QtMoko future

2011-05-24 Thread Tiago Bortoletto Vaz


On Mon, 16 May 2011 13:08:36 +0200, Alfa21-mobile freerun...@my.is.it 
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=fsosearchon=namessuite=allsection=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-05-16 Thread Philip Rhoades

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

2011-05-16 Thread Radek Polak
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

2011-05-16 Thread 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=fsosearchon=namessuite=allsection=all

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About QtMoko future

2011-05-16 Thread Timo Jyrinki
2011/5/16 Alfa21-mobile freerun...@my.is.it:
 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=fsosearchon=namessuite=allsection=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=AttachFiledo=viewtarget=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

2011-05-12 Thread Kai L√ľke

 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

2011-05-12 Thread Francesco De Vita

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

2011-05-11 Thread Timo Jyrinki
2011/5/9 Radek Polak pson...@seznam.cz:
 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

2011-05-11 Thread Michael 'Mickey' Lauer
Am Mittwoch, den 11.05.2011, 21:06 +0300 schrieb Timo Jyrinki:
 2011/5/9 Radek Polak pson...@seznam.cz:
  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-05-11 Thread Tiago Bortoletto Vaz
On Wed, 11 May 2011 21:06:01 +0300, Timo Jyrinki wrote
 2011/5/9 Radek Polak pson...@seznam.cz:
  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

2011-05-09 Thread Radek Polak
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-05-08 Thread Timo Jyrinki
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