Re: community Digest, Vol 235, Issue 5
On 05/14/2011 12:00, community-requ...@lists.openmoko.org wrote: and the -verbose option gives: [...] eval: 1: arm-linux-gcc: not found [...] does this work for you like for me? radek@rp-skunk:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc arm-linux-gcc: no input files Regards Radek Hi Radek, Yes, it behaves quite exactly the same: $ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc: No such file or directory Thanks Giacomo -- ## 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
AtMoko v35 incoming SMS tone missing?
People, I don't get a tone when an SMS arrives - I can't find anything on the phone or googling that mentions this - is this a known issue? Am I missing something? 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
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: community Digest, Vol 235, Issue 5
On Monday 16 May 2011 10:37:02 giacomo 'giotti' mariani wrote: On 05/14/2011 12:00, community-requ...@lists.openmoko.org wrote: and the -verbose option gives: [...] eval: 1: arm-linux-gcc: not found [...] does this work for you like for me? radek@rp-skunk:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc arm-linux-gcc: no input files Regards Radek Hi Radek, Yes, it behaves quite exactly the same: $ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc: No such file or directory Ehm quite exactly the same? You are obviously missing toolchain. Please follow once more the README [1], and make sure you did the step called * Download and install toolchain Regards Radek [1] https://github.com/radekp/qtmoko/blob/master/README ___ 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
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/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: [QtMoko] amd64 compilation trouble
and the -verbose option gives: [...] eval: 1: arm-linux-gcc: not found [...] does this work for you like for me? radek at rp-skunk:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc arm-linux-gcc: no input files Regards Radek Hi Radek, Yes, it behaves quite exactly the same: $ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc: No such file or directory Ehm quite exactly the same? You are obviously missing toolchain. Please follow once more the README [1], and make sure you did the step called * Download and install toolchain Regards Radek [1] https://github.com/radekp/qtmoko/blob/master/README Hi Radek, my message could give that idea, but I installed the toolchain following your README. In fact: jack@nb2-mariani:~$ ls -l /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc lrwxrwxrwx 1 jack jack 25 2011-05-13 11:52 /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc - arm-linux-gnueabi-gcc-4.3 jack@nb2-mariani:~$ file /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped jack@nb2-mariani:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3: No such file or directory Thanks for your help Giacomo -- ## 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] amd64 compilation trouble
Hi Giacomo, There might be something wrong with the libraries, can you check with: ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 Kind regards, Ed On Monday 16 May 2011 14:44:31 giacomo 'giotti' mariani wrote: and the -verbose option gives: [...] eval: 1: arm-linux-gcc: not found [...] does this work for you like for me? radek at rp-skunk:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc arm-linux-gcc: no input files Regards Radek Hi Radek, Yes, it behaves quite exactly the same: $ /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc: No such file or directory Ehm quite exactly the same? You are obviously missing toolchain. Please follow once more the README [1], and make sure you did the step called * Download and install toolchain Regards Radek [1] https://github.com/radekp/qtmoko/blob/master/README Hi Radek, my message could give that idea, but I installed the toolchain following your README. In fact: jack@nb2-mariani:~$ ls -l /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc lrwxrwxrwx 1 jack jack 25 2011-05-13 11:52 /opt/toolchains/arm920t-eabi/bin/arm-linux-gcc - arm-linux-gnueabi-gcc-4.3 jack@nb2-mariani:~$ file /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped jack@nb2-mariani:~$ /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 -bash: /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3: No such file or directory Thanks for your help Giacomo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] amd64 compilation trouble
Hi Ed Hi Giacomo, There might be something wrong with the libraries, can you check with: ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 Kind regards, Ed here the output of ldd follows: jack@nb2-mariani:~$ ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 linux-gate.so.1 = (0xf77bb000) libc.so.6 = /lib32/libc.so.6 (0xf763f000) /lib/ld-linux.so.2 (0xf77bc000) It looks good to me, but I'm not a guru at all. Thank you very much Giacomo -- ## 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
Aurora
NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Dear FOSS-Telephony lovers, today we want to announce something that has been brewing in our minds for quite a while and will change the way we develop the freesmartphone.org middleware. In the past, FSO has been too much developed without considering how the features will actually be used by the API consumers. Apart from the great work our friends from SHR did, there has only been a handful of special purpose FSO clients, such as the Emacs client, Zhone, and Zhone2. Zhone (and its successor Zhone2) is currently an oversimplified approach based on a non-maintainable Edje file. We have therefore decided to develop a new testing/demonstrator for FSO named Aurora that is supposed to be the driving force for further development. AURORA The aim of Aurora is to replace zhone and zhone2 as development UIs for FSO. From the viewpoint of a middleware architect, it's essential to have clients available that use the various features of the FSO services. On the other hand though, this time we want to create something that is also suitable for day to day use. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Aurora being a featurephone client does not necessarily mean it will never get the smartphone features Android or iOS are popular for, it rather describes our approach as being as-simple-as-possible. So for now you will not be able to install additional apps or features. Everything (you need) is part of the Aurora client. DEVELOPMENT PROCESS At the top of every application stack is the user. Pleasing him or her is the topmost priority. Technology should not stand in the way, but rather support the user. Hence, Aurora releases will be done as user milestones. For every user milestone, we will pick a number of user stories to be implemented. We will then split a user story into tasks and distribute among the contributors. SUPPORTED DEVICES We decided to only support the Palm Pre devices (Pre/Pre Plus/Pre 2) for the first to-be-released version of Aurora. More supported devices will join after the 0.1 release. This decision has been forced by the fact that we are only very few people working both on FSO and Aurora (and also on OpenEmbedded). Later on, we expect to see the OpenEZX family of devices, the Openmoko devices, the Nokia N900, and possibly also a bunch of HTC smartphones supported. TECHNOLOGY Some words about the technology choices we have made for Aurora. The UI components of Aurora will be based on Qt's QML (Qt Markup Language) and will have parts written in C++ and Vala (although we're going to use Python for prototyping as well). We will support both Qt/X11 and Qt/Embedded, the latter being useful on smaller systems, such as the OpenEZX family of devices (48MB RAM, no GFX acceleration, etc.) For the first release we will only provide Qt/Embedded based images for the Palm Pre devices; those flashable images will be based on OpenEmbedded, however we'd welcome people taking care of creating releases based on Debian, Gentoo, etc. THE CODE At the moment, there is not much to look at, but feel free to download the current status via git.freesmartphone.org - aurora. HOW TO HELP Speaking about welcoming people, the major aim of this announcement is to find people who want to share this vision and give us a bit of a hand. We are especially lacking artists and folks who can improve our user interaction. Apart from the technical reasons, we chose QML to have a very low barrier of entry. QML is easy to understand and it also comes with a GUI design tool. If you are interested and share our vision, please feel free to contact us. We can then see how you could help us to get to the end goal (see roadmap) even faster. There are two possibilities to make us aware of you: - IRC: irc.freenode.net; channel: #openmoko-cdevel - Mail: smartphones-userl...@linuxtogo.org Thanks for your attention, Mickey Morphis. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? Thanks! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On 16 May 2011 17:02, Michael 'Mickey' Lauer mic...@vanille-media.de wrote:
NOTE: Cross-posted to three mailing lists, please keep it that way, if
you want to reply.
If you can persuade them all to accept emails from non-subscribed
email addresses... (For weird historical reasons, I'm subscribed to
different lists with different addresses.)
In the past, FSO has been too much developed without considering how the
features will actually be used by the API consumers.
Apart from the great work our friends from SHR did, there has only been
a handful of special purpose FSO clients, such as
the Emacs client, Zhone, and Zhone2. Zhone (and its successor Zhone2) is
currently an oversimplified approach based on a
non-maintainable Edje file. We have therefore decided to develop a new
testing/demonstrator for FSO named Aurora that
is supposed to be the driving force for further development.
I'm afraid I don't understand. Why not just have SHR as your
reference set of applications? If you don't think they are using the
FSO APIs in the pattern that you would recommend, presumably you could
work with them to correct that? Or, if they are missing applications
or features to showcase some of the latest FSO API features,
presumably you could help them to add those?
At the top of every application stack is the user. Pleasing him or her
is the topmost priority.
Speaking as a user, I would be pleased not to see more unnecessary
fragmentation of front-end efforts; also for the FSO2 middleware to be
rock-solid, with things fixed like RequestResource('bluetooth')
starting bluetoothd.
To be fair, it may be that FSO2 already is rock-solid now. I haven't
reviewed the situation recently, but I can't immediately think of any
known and clear issues, about from the bluetoothd one. But in that
case I'd still prefer focus on the SHR front end, over some new UI.
Some words about the technology choices we have made for Aurora. The UI
components of Aurora will be based on Qt's QML
(Qt Markup Language) and will have parts written in C++ and Vala
(although we're going to use Python for prototyping as well).
We will support both Qt/X11 and Qt/Embedded, the latter being useful on
If you strongly favour Qt, you could take QtMoko as your reference set
of applications. That would be especially helpful right now, as Radek
is just looking at converting QtMoko to use FSO.
Speaking about welcoming people, the major aim of this announcement is
to find people who want to share this vision
and give us a bit of a hand. We are especially lacking artists and folks
who can improve our user interaction.
Apart from the technical reasons, we chose QML to have a very low
barrier of entry. QML is easy to understand
and it also comes with a GUI design tool.
If you are interested and share our vision, please feel free to contact
us. We can then see how you could help us to get to the end goal (see
roadmap) even faster.
I'm almost lost for words here. Starting from scratch seems so
obviously the wrong thing to do, when there are mature projects that
you could contribute to...
I must be misunderstanding what you mean - please do explain more!
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On 16.05.2011 23:22, Neil Jerram wrote:
I'm afraid I don't understand. Why not just have SHR as your
reference set of applications? If you don't think they are using the
FSO APIs in the pattern that you would recommend, presumably you could
work with them to correct that? Or, if they are missing applications
or features to showcase some of the latest FSO API features,
presumably you could help them to add those?
SHR is a great thing, but it's too complex to be the first showcase for
new features. The main problem we have is time and man-power. We are
currentl two people doing most of the FSO work. With two people it's
even hard to get only the basics done.
SHR is based on the traditional design pattern of a window mananger
which runs some application you can work with. The work to integrate new
features like network (wireless, gprs, bluetooth pan) in a usable we
needs a lot of work (you need a new E Gadget, you need a application to
choose the network, you to adjust shr-settings, ...) to do.
I worked for now 2 two to get SHR running on the Palm Pre and it's so
much work that I will never finish it on my own. You invest a lot of
time to debug things, see how things work and never get your work
finished in a reasonable time frame.
At the top of every application stack is the user. Pleasing him or her
is the topmost priority.
Speaking as a user, I would be pleased not to see more unnecessary
fragmentation of front-end efforts; also for the FSO2 middleware to be
rock-solid, with things fixed like RequestResource('bluetooth')
starting bluetoothd.
Aurora is not about fragmentation. Zhone was already there before SHR
and Aurora will continue Zhone. We will take aurora as our new reference
application as it is quite simple and let us integrate new features very
fast.
To be fair, it may be that FSO2 already is rock-solid now. I haven't
reviewed the situation recently, but I can't immediately think of any
known and clear issues, about from the bluetoothd one. But in that
case I'd still prefer focus on the SHR front end, over some new UI.
As you may know we are working hand-in-hand with all the SHR developers
and we are loving SHR too. But at some point we need to concentrate us
on FSO and FSO as framework only to be successfull in the future and not
only on the Openmoko devices. There are a lot of devices out which are
suitable to be driven by FSO but needs time to be integrated into the
framework. If we do everytime to full work for SHR and FSO we will never
do anything else with this phones in their lifetime. If you work for a
long time very hard on such a project you want to see something working
and usable to have. But currently with doing the doubled work for SHR
and FSO does not let us come the this point.
If you strongly favour Qt, you could take QtMoko as your reference set
of applications. That would be especially helpful right now, as Radek
is just looking at converting QtMoko to use FSO.
With QtMoko it's the same as I said above. We need some simple stupid
thing we can change within an hour to support a new feature like network
management. We cannot archive this with QtMoko or SHR.
I'm almost lost for words here. Starting from scratch seems so
obviously the wrong thing to do, when there are mature projects that
you could contribute to...
We are not starting from scratch with a completely new platform. We are
just reordering the reponsibility of the FreeSmartphone team which is to
develop the middleware and concentrate of integrating new devices and
get new features like network management in.
I must be misunderstanding what you mean - please do explain more!
Don't thing about aurora as something big, it's a very simple thing for
simple needs. You will see all new features even in SHR, but not done by
the core FSO team.
regards,
morphis
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
