Re: Problem compiling openmoko with MokoMakefile
Gary Oliver wrote: I've been trying to get the openmoko build (using the super Makefile) to go for the last few days without complete success. I believe I've followed the instructions with respect to the system requirements, and the build DOES get through about 12 hours of work (about 400meg has been downloaded and the build directory contains about 5 Gb before failing, so it seems to be quite well along. The failure comes at: NOTE: package gtk+-directfb-2.10.9-r0: task do_fetch: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: started NOTE: Unpacking /home/go/Projects/openmoko/sources/gtk+-2.10.9.tar.bz2 to /home/go/Projects/openmoko/build/tmp/work/armv4t-linux/gtk+-directfb-2.10.9-r0/ NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started NOTE: Applying patch 'no-xwc.patch' ERROR: Error in executing: /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/home/go/Projects/openmoko/openembedded/packages/gtk+/files/./no-xwc.patch' Which appears to be a failure to apply a patchfile no-xwc.patch which doesn't seem to be part of the source tree at this point. The files directory contains only migration.patch. Has anyone else seen this, and if so, what bit of detail in the instructions did I fail to notice that's causing this? FYI I have tried building from complete scratch a number of times (blowing away everything except the Makefile) in hopes that I'd simply polluted my local tree somehow. Didn't fix it. A quick google for this file netted me several different variations, so am not quite sure what no-xwc patches are required for OE/OpenMoko. Am running a fairly stock Debian testing system on an 32 bit AMD platform. No apparent shortage of disk space. Thanks for any help, Gary ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I had the same problem today. Rod W. let me know that there's now a fix in place for it. a make update brought in the changes and the subsequent build completed ok. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko - SoC--- is there a mentor?
Hi Guy, the linchpin of you concept is the keyboard layout. If you use unsuited layouts initially, no one will invest the time to get it right for themself, because one can't easily experience the advantages of the concept when making first impressions. Although I am not an expert for language forensic, I assume that the biggest part of your work will NOT the implementing part, but the research for a propper keyboard layout for english and portuguese at least. A lot of fine concepts in open software got never used due to the circumstance that the first available implementation couldn't impress the users enough to encourage them to invest their time to improve it. As you said on your web page, your concept is a composite of the ideas your found on the wishlist. If I identify the original ideas correctly, your solution will need more time to get used to as the single original ideas will do. So you have to offer a significant added value, which would be a working keyboard layout for at least the english language (I assume that the majority of users will be native english or correspond in english mostly). And do think about the implications of different layouts for the user. For every language one has to learn a completely different position of each letter. What is left from the advantage of the single stroke architecture if one has to search for the next character each time after changing the layout to a different language? We end up at the same point we started: the layout is the linchpin (and - in my opinion - also the weak point) of your concept. Regards Karsten --- gsilva85 wrote: Karsten, i agree with you about the layout of the chars ( on my example they was put aleatory )! but at this point I'm just introducing another concept of a finger based keyboard. I'm not able to know whats the better place for each char optimized for English, Germany or even to Portuguese (my native language, I'm Brazilian...). For this use cases I'll try to implement some way to easy develop/change the layout of keys (like i said at bottom of my page). Anyone could make their own layout optimized for his language, share with community then you download to your phone, when you need it probably you press some predefined key on this keyboard, select what layout you want and dynamically change to it. This concept is already presents in phones, like when you change the input method to letters, number, symbols, t9... what do you think? Guy PS:don't worry I'm still encouraged to submit it to SoC : ) 2007/3/24, Karsten Ensinger [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Guy, following your explanation, I will get c, z, g and q as characters when tapping on 1, dragging to 3 and dragging back to 1. When I want to have c, g and q, I have to tap on 1, drag to 2, lift the finger, tap on 3 and drag to 1. If I want to have c, g and c, I have to tap on 1, drag to 2, lift the finger, tap on 3, drag to 2, lift the finger, tap on 1 and drag to 2. Depending on the needed character sequence, your new concept can result in the same amount of taps and drags as the original finger splash concept. So everthing depends on the intelligent placement of the characters on the keyboard layout. Let's come to the usability aspects. If I look at the finger splash, the tapping on 1 will result in a button overlay which will hide the complete 2 at least (maybe also some parts of 3, depending on size). So there is no way for the user to see what is on the right side of the 2 button. This leads to a drag into the blind to get the z. This seems to me as not user friendly enough to get accepted widely. One has to remember the whole keyboard layout in mind while typing. This would lead to the idea to NOT enlarge the buttons when one taps them. The user would be able to see what he gets, when dragging to the next button. Unfortunately the size of the buttons can't get big enough to hold characters with an easy readable fontsize due to limited physical screen size. This seems to be a dilemma. Making the buttons bigger means less buttons per row and column, means less benefit from the dragging feature. Maybe the KISS pattern matches here (KISS = Keep It Small and Simple). Although the ability to type more than one letter with a single stroke has charming aspects, the learning curve of the keyboard usage should be as steep as possible and to me, the current concept seems to be to much in need of an explanation. What I have only shortly mentioned before, is the fact that you have to analyse the inherent syllables of the language the user will use. You have to place the characters in a way, that one can type as much words with one or two strokes as possible. So the keyboard layout will vary from language to language. What about users using two different languages at the same
Re: No stylus on V1 release?
On Sunday 25 March 2007 01:16:46 Clare Johnstone wrote: Dear all, This frightens me in my role as mother, grandmother etc, i.e. a representative of the public to which you hope to sell this phone. Essentially any laser device powerful enough to be useful has no place in a home which may ever have children in it. (Even quite old ones). Basically, yes, laser pointers can be dangerous, however, actual damage is not very likely: http://en.wikipedia.org/wiki/Laser_pointer#Hazards. As for the rest, I agree with Joe. pgpMzUM8lvQW1.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
On Sun, Mar 25, 2007 at 08:16:46AM +0800, Clare Johnstone wrote: Dear all, This frightens me in my role as mother, grandmother etc, i.e. a representative of the public to which you hope to sell this phone. Essentially any laser device powerful enough to be useful has no place in a home which may ever have children in it. (Even quite old ones). clare Hi Clare! I like it, that you think about this. But as all laser pointers are battery powered, what's about just not putting batteries in the stylus? Okay, you wont be able to use the torch, but if you feel better with a plain stylus without any extras? _Guessing_ from koen's unboxing the neo pictures, the batteries are shipped seperately, so you just don't install them in the first place and leave them in the box. As one of those few who don't own a laser pointer/torch thingy, I anyway wonder how long the batteries last... Elrond ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Wiki update: bootable usb stock emulation
Hi I just updated/developed my previous idea of using the transflash as a bootable device (mass storage mode). http://wiki.openmoko.org/wiki/Wishlist:Bootable_USB_device_emulation * What do you think? * Could somebody owning a device test it? * If you have pointers to other resources, please add them/tell me; more generic information could be interesting, especially about the memtest method (i have no idea how the payload was generated, or if we can do the same for others) * i'd be glad to know how one could simply boot on a regular iso using grub I'm not sure what could prevent it to work, but it would be great to know. Thanks Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
Dnia niedziela, 25 marca 2007, Elrond napisał: But as all laser pointers are battery powered, what's about just not putting batteries in the stylus? _Guessing_ from koen's unboxing the neo pictures, the batteries are shipped seperately, so you just don't install them in the first place and leave them in the box. My Neo stylus came with batteries inside and extra ones in box. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Don't mind me, I'm just checking if you are dense enough to cause a tide ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI long term development perspective: physics engine
The physics comes in if you give the slider mass and intertia. Then it accelerates and decelerates depending upon how hard you push it and how much friction there is. The acceleration is driven by the difference in position of the touch point and the slider as you move the touch point and the slider lags the movement. Move the touch point slowly and the slider follows it, flick it fast and the slider will get a bigger kick, accelerate more then coast to a halt and have the overshoot that you want. Adrian On 3/24/07, Florent THIERY [EMAIL PROTECTED] wrote: I'll add here sotg from an off-list msg; In fact we have the position given by the touchscreen : [ x(t) ; y(t) ] speed is: [ (x(t') - x(t)) / (t' -t) ; (y(t') - y(t)) / (t' -t) ] - friction_factor*(t' - t) ... Where the friction_factor is in [0 ; 1] If we want acceleration, then we have to integrate the equation once. Shit, i gotta look into my college courses, it's terrible how fast it fades away :-p I'm not sure we really need to take acceleration into account. The changes to bring to the standard gtk scrolling are: - consider the list as scrollable (not just the scroll item) - change the scrolling stop behaviour (when the user stops touching the screen) like this: if (last_cursor_speed 0), continue_scrolling(last_cursor_speed) - when touching the moving list again, stop the scrolling immediately - addition of friction may be a plus, for a more wheel-of-fortune-like experience ___ 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: Problem compiling openmoko with MokoMakefile
Mark Chandler wrote: Gary Oliver wrote: I've been trying to get the openmoko build (using the super Makefile) to go for the last few days without complete success. ... I had the same problem today. Rod W. let me know that there's now a fix in place for it. a make update brought in the changes and the subsequent build completed ok. My make openmoko-devel-image has cruised past that former roadblock. Thanks! -Gary ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
Hi Elrond, Thank you for that. It is a partial solution to my concern about children. I am still hoping for a stylus that is part of the phone, for convenience reasons. The suggestions about an alternative back were promising. My current phone has the stylus in a slot at the back and it is wonderful. I have trained myself always to put it back after use and I always have it, That means all I need to grab to take with me is the phone. The only other thing I carry all the time is my keys. One of them maybe will do as a stylus. clare. On 3/25/07, Elrond [EMAIL PROTECTED] wrote: On Sun, Mar 25, 2007 at 08:16:46AM +0800, Clare Johnstone wrote: Dear all, This frightens me in my role as mother, grandmother etc, i.e. a representative of the public to which you hope to sell this phone. Essentially any laser device powerful enough to be useful has no place in a home which may ever have children in it. (Even quite old ones). clare Hi Clare! I like it, that you think about this. But as all laser pointers are battery powered, what's about just not putting batteries in the stylus? Okay, you wont be able to use the torch, but if you feel better with a plain stylus without any extras? _Guessing_ from koen's unboxing the neo pictures, the batteries are shipped seperately, so you just don't install them in the first place and leave them in the box. As one of those few who don't own a laser pointer/torch thingy, I anyway wonder how long the batteries last... Elrond ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Compressed SMS (and other text messages)
One of the things that I have just received recently is that, somehow, the network detected that I had a phone that was not able to receive a MMS. It just sent me a text message with a web address in it to retrieve it. This implementation is not too good as it immediacy of SMS is lost. Can the type of phone be known by the network, if so, can we exploit to it? On 3/23/07, Jeff Andros [EMAIL PROTECTED] wrote: On 3/22/07, Ian Stirling [EMAIL PROTECTED] wrote: Andreas Kostyrka wrote: * Jonathon Suggs [EMAIL PROTECTED] [070321 22:58]: Andreas Kostyrka wrote: snip My challenge is just to think bigger. Think how this could be incorporated to work with *any* phone. Then you can have a much larger group of people to brainstorm, test, and bugfix. We have enough protocols and standards to support. Creating yet another one isn't really going to help that much. Also, I don't know anyone else that is planning on getting a OpenMoko device, so its pretty pointless for me at this point. I know you've got to start somewhere, but starting out a battle fighting uphill isn't the best of ideas. what about sacrificing a few bytes at the beginning/end of the compressed data to include to decompress, forward to . If you've got an openmoko/other compression capable phone, this would be disregarded, but for the vanilla phone users out there, forwarding to that number/short code would send the encoded data to a decoding server, which would then call back to the sender with the decompressed message(s). it's not really that good a solution, kind of kludgy, and it would cost whoever you sent the message to several extra texts. On the other hand, it generates some interest, and shows a tangible benefit to purchasing an openmoko phone... for the heavy sms'er this could even start saving them some cash. anyways, I got to thinking of the compatibility problem, and this popped into my head... hopefully it'll help spur some more ideas -- Jeff O|||O ___ 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
