Qtopia coming for Neo1973
before someone beats me to it. http://trolltech.com/company/newsroom/announcements/press.2007-09-17.9260755578 and http://www.linuxdevices.com/news/NS5429713730.html In short: Qtopia is going to be fully GPL'd (telephony applications included, which weren't) and is being ported to Neo1973. Some comments (personal, I can be wrong...): 1) I hope this stops the Qtopia dismissal because not-GPL'd arguments. No one can doubt of Trolltech commitment to Open Source world, whether you like them being commercial or not. 2) collaboration can be complete now, if not sharing the source (at least not fully, because of the different stacks), at least in borrowing design patterns. 3) this could be seen also as a temporary solution for those which want to use the Neo _right_now_ (despite it still being developers-only) 4) it stresses the no-software-lock-in that Neo wants to have, in contrast to all other phones. This is freedom. Seems to me a great step in making the Neo a big platform. I can't wait to see it. cheers, mauro ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia coming for Neo1973
On 18/09/2007, Jonathan Spooner [EMAIL PROTECTED] wrote: I hate to say it but in my experience at least, its a dream developing apps using QT esp given the nice IDE in comparison to using GTK. QT just has the docs and organised feel which makes it easy. Regards, Jon with the drawback that _everything_ will need to be Qt based, in contrast with openmoko, which will let you run any X app written out there (resolution issues aside) and, if the CPU is powerful enough, even Qt apps. Seems to me it will just be better when it will be finished. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia coming for Neo1973
On 18/09/2007, Giles Jones [EMAIL PROTECTED] wrote: Mauro Iazzi [EMAIL PROTECTED] wrote : before someone beats me to it. http://trolltech.com/company/newsroom/announcements/press.2007-09-17.9260755578 Ironic given one of their Greenphone guys was slagging the OpenMoko project a while back. I remember, I suppose he wasn't speaking for all Trolltech, or they have just changed their minds... anyway it's good to see they are now working for the Greater Good(TM) . It seems a gain for all, also given they may even be stopping pushing the greenphone now that it has inferior hardware and same software of Neo. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia coming for Neo1973
On 18/09/2007, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007 17:45:51 +0200, Mauro Iazzi [EMAIL PROTECTED] wrote: I hate to say it but in my experience at least, its a dream developing apps using QT esp given the nice IDE in comparison to using GTK. QT just has the docs and organised feel which makes it easy. with the drawback that _everything_ will need to be Qt based Why is that? Qtopia does not make use of X. It uses direct rendering and draws with its very own primitives. It is one the primary reason for the different naming, I think... I also think you can hook to draw directly in the framebuffer, but there would be no policy for interacting with other apps, which you would have using X. Everyone could draw over you and viceversa. They chose to make it so, so there is no expectation this will change. It's a little more locked than what OpenMoko would be. In the meantime, it works well being limited, so it's a legitimate choice. @Giles Qt if fully GPL. Qtopia (the full stack: Phone Edition) used to be only partly GPL'd (a large part indeed called OpenSource Edition), but by October will completely be GPL. There are really no license issues with this software. This should be made clear. The problem people have is for it to be commercial (i.e. sold). It's a different issue. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia coming for Neo1973
On 18/09/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Has anyone seen these benchmarks: http://zrusin.blogspot.com/2006/10/benchmarks.html It compares Cairo (what GTK+ uses) against QT. When it comes to rendering, I believe Qtopia QT use the same code. So ignoring X, Qt was respectively 7, 5 and 6 times faster. Than Cairo in those plain tests. Now factor in the fact that QWS has a lot less overhead than X and a smaller memory footprint. Can someone _please_ give me a technical reason why they believe GTK+ is better? The only arguments I've seen on this list are philosophical ones. The only technical argument has been that you can run applications on the phone and have them appear on your desktop thanks to X. Surely there is a better reason? I hate to say it, but I'm beginning to feel that the OpenMoko developer's ego is a big driving force behind developing the OpenMoko stack. You are shifting to the dark side... I'm all for KDE over Gnome, Qt ove Gtk, Vim over Emacs, but not at the level of saying there is no reason for others to exist. I would be lost if I were foced to use Emacs, I suppose the same is valid for an experienced Emacs user with Vim. The fact that Emacs is an inferior solution in every respect does not change that someone _needs_ it. I suggest you read this post over redundancy written by a prominent member of KDE community http://troy-at-kde.livejournal.com/7771.html He just says what many people already said. Redundancy is good. For innovation and choice, and because what X and Y want may be different. OpenMoko was designed. There surely were reasons for it to chose Gtk over Qt. While I don't know exactly, one of those may have been that a phone software based on Qt was already there, and it was not fully Open Source. If they chose Qt, what to do now that Qtopia is fully open (trust: Trolltech behaving badly is _inconceivable_). You can develop and install the one or the other freely. Redundancy is good. I don't think switching to Qt is an option for OpenMoko, because there is Qtopia for that. The choice has been done, and in my opinion, has been wise. You can chose which distro to support, or both if you can. ___ 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: Neo1973 Update!
On 05/06/07, Tim Newsom [EMAIL PROTECTED] wrote: If your tracking movement with 2 3D accelerometers... What would another one provide. As far as I can tell (I am not an expert...) Tracking all 6 vectors will tell you absolute movement in space. I.e, when 2 vectors point in the same direction with the same magnitude at approximately the same acceleration as gravity.. Its probably laying or positioned flat on that side. Probably is the key here. with two 3d (linear) accelerometers you cannot sense rotation around the axis between the two in an inertial frame of reference. Moreover you cannot distinguish if the Neo is laying face down or pushed downwards with 2mg force. This example is somewhat artificial, but means that you can probably find more realistic (though complicated) movements that are not distinguishable with only two accelerometers. You must then consider the errors which sum up, if you try to track. A rough mental estimate gives that you can sum up as much as 1 meter of error in ten seconds if you have a precision of 10^-3g over acceleration measure. (it does not mean that you are 1 meter away from the real position, it means that you can only be sure that you are at most 1 meter away from that). Most of the time you will need good assumptions to get any information from raw data: http://www.wiili.org/index.php/Motion_analysis can be of some help. No linear accel, no rotation, no tilt, are assumptions which can give some meaning to the data and can be done for single application, where you can assume the user will have some particular behaviour (or you require it). Still absolute tracking won't probably be anyhow realizable. --mauro ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Lua hacking
As everyone may have noticed, the previous message was not intended for openmoko lists. It is not related by anything to it but for the fact that I am interested in Neo1973 and read this mailing list. I apologize. Late night makes my stupidity worse than ever. I will repost on the correct mailing list as soon as possible. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Lua hacking
Hi all,
being my first post on this mailing list I'd like to thank everyone
(team and community) for Lua itself and the great load of useful Lua
code around.
To the point: I have modified Lua code to change the parser. The
result is that it that parses differently from Lua (but generates the
same bytecode and has the same API). The main changes are quite small
(with one exception) so that most Lua code will compile anyway.
Precisely the changes are:
- short comments are not allowed (the BIG change) and '--' is
considered as an identifier
- '.' to access table objects only works if not preceeded by a space
otherwise is considered as an identifier
- in a statement, the first token is always interpreted as an
identifier (so that ? = 1 is valid) if it is not a keyword
- every statement which starts with an identifier not followed by a
list of ',' and other identifiers, plus an assignment does not
generate an error but translates in a call of that identifier instead.
The remaining characters until subsequent '\n', '\r', or';' (and, of
course, EOS/EOZ) are absorbed in a literal string and passed as an
argument to the call. Thus foo bar is equivalent to foo(' bar') and
foo is foo(nil).
Why so strange? I'll explain in a minute. Before that I'd like to say
that it was an easy task. I had to touch three files only and diff is
about 260 total lines (mostly commented out development code). Lua is
wonderfully coded!
I have now a complete Lua-like shell, written on top of this patch.
Some fun things I could do are:
- dynamic prompt (a function in Lua that returns a string) that
supports escape sequences (e.g. colors)
- callbacks to override history behaviour
- binding of keystrokes to different actions (not actually Lua
callbacks as of now, but a predefined set) through Lua function bind
- I have the feeling that it uses POSIX only, but cannot be sure
- and most of all, bash-like completion. Obviously, it is written in
Lua! so it should be easy to extend from present PATH/currentdir file
completion
- and clearly accepts Lua code so it has full introspection and all
the wonderful things that Lua provides.
For non bash-power-users should be very similar to bash (I had to
prefix my prompt with LSH: to tell the difference). I hope it to be
at least as powerful as soon as possible.
I think the possibilities are so many. I have lots of ideas which
could be useful (or not)but I will not list here for brevity.
I need help on a few issues.
First and foremost to understand all license issues around the code I
used. I'd very appreciate any help on this. I used this Lua patch I
described above (I assume modifying code and not redistributing is
allowed :P ) and this light replacement of readline:
http://www.astro.caltech.edu/~mcs/tecla/index.html
which is under MIT license and seems discontinued from 2004. I'd like
to release this under a permissive license. Perfect would be the same
as Lua (whichever). Is it possible? How?
If it is ok I'll soon post patches to Lua 5.1.2. I hope someone is interested.
As I'm a bad programmer you'd better be advised that the code is not
well indented and contains lot of commented out code. Sorry, I can't
help. If you _really_ want you could point out things which do not
work as intended above (and bugs: there should be plenty of them), I'd
appreciate.
The patched Lua should work in every way as vanilla one but for
parsing. (this would allow compiling plain Lua script to be loaded
during initialization)
As soon as possible I will pack the lsh code and put it somewhere (I
don't know where).
I strongly hope this is of some interest for someone. If so, please
tell me. I'm developing in spare time, thus knowing it is not wasted
time helps. If you mind, let me know, please.
Thanks to all,
Mauro Iazzi
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
