Re: [FSO/SHR/Debian] Update to BtGPS.py
Hi Angus What about putting this app on the opkg.org website, so people would easily find it ? Thanks anyway for sharing your work kimaidou ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hi all, I am glad people (re-)start to talk about keyboards. 2 points: * Another great improvement compared to the iphone, illume, etc. ones, would be to have a transparent keyboard, using the whole screen, but allowing to see through it. Of course we need the transparency % to be changed by the user. What about the technical feasibility of that ? Would it be possible ? I thing for example about the Qwo keyboard ( http://www.opkg.org/package_84.html ) which would be very finger friendly in full screen (like the other one) * I don't get how the dictionnary (illume and qtopia) actually helps to write some word. In mobile phones, on which you have only 9 numbers to type, so 3 letters by number, the T9 dictionnary was really helpfull, because it showed a list of words possible with the combination of the letters entered. I could actually write sms faster with only 9 keys than now with a complete qwerty keyboard because the buttons were much bigger and I had only 9 button to search among. Here with the FR, the eyes and brain must locate the desired letter among much more and much smaller keys. And furthermore, I don't see the point with the dictionnary. The dictionnary only shows words with the same number of letters as the ones entered. So it does not provide a way to easily choose a word (for example, when I type for it must show for, forest, force, etc., but with the illume keyboard it only shows for and other useless words like :big, fit, die, but, etc.-- not very related to for ) People using OpenOffice Writer with the autocompletion activated will understand what I am trying to explain with my limited english skills.. My 2 cents :) , of course in a constructive way Kimaidou 2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com On Tue, 6 Jan 2009 11:08:41 +0530 Shashank Bharadwaj shanka@gmail.com babbled: On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Tue, 06 Jan 2009 02:46:15 + Jan Henkins j...@henkins.za.net babbled: Hello there, Pascal d'Hermilly wrote: With 2008.12 release, a well working finger-friendly keyboard is the most critical missing feature for me. I've made a mockup of a keyboard that I think would make things a lot easier to type. http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png I think, the current Raster's Keyboard great for potrait mode. For landscape mode(i.e holding neo sideways) however, the keyboard does not utilize the extra space. What we need is, imho, a keyboard that would increase in size to take up the extra space in this landscape mode. That way we'll be able to type even faster. If we could add that fuctionality to raster's keyboard, then it'd be just great. that's a matter of just fixing the code to handle resizing appropriately. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Openmoko keyboard mockup
Good point about T9 kimaidou, but as far as I know the T9 itself is a patented technology, and would not be able to appear on Moko officially... kimaidou wrote: Hi all, I am glad people (re-)start to talk about keyboards. 2 points: * Another great improvement compared to the iphone, illume, etc. ones, would be to have a transparent keyboard, using the whole screen, but allowing to see through it. Of course we need the transparency % to be changed by the user. What about the technical feasibility of that ? Would it be possible ? I thing for example about the Qwo keyboard ( http://www.opkg.org/package_84.html ) which would be very finger friendly in full screen (like the other one) * I don't get how the dictionnary (illume and qtopia) actually helps to write some word. In mobile phones, on which you have only 9 numbers to type, so 3 letters by number, the T9 dictionnary was really helpfull, because it showed a list of words possible with the combination of the letters entered. I could actually write sms faster with only 9 keys than now with a complete qwerty keyboard because the buttons were much bigger and I had only 9 button to search among. Here with the FR, the eyes and brain must locate the desired letter among much more and much smaller keys. And furthermore, I don't see the point with the dictionnary. The dictionnary only shows words with the same number of letters as the ones entered. So it does not provide a way to easily choose a word (for example, when I type for it must show for, forest, force, etc., but with the illume keyboard it only shows for and other useless words like :big, fit, die, but, etc.-- not very related to for ) People using OpenOffice Writer with the autocompletion activated will understand what I am trying to explain with my limited english skills.. My 2 cents :) , of course in a constructive way Kimaidou 2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com mailto:ras...@rasterman.com On Tue, 6 Jan 2009 11:08:41 +0530 Shashank Bharadwaj shanka@gmail.com mailto:shanka@gmail.com babbled: On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler ras...@rasterman.com mailto:ras...@rasterman.com wrote: On Tue, 06 Jan 2009 02:46:15 + Jan Henkins j...@henkins.za.net mailto:j...@henkins.za.net babbled: Hello there, Pascal d'Hermilly wrote: With 2008.12 release, a well working finger-friendly keyboard is the most critical missing feature for me. I've made a mockup of a keyboard that I think would make things a lot easier to type. http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png I think, the current Raster's Keyboard great for potrait mode. For landscape mode(i.e holding neo sideways) however, the keyboard does not utilize the extra space. What we need is, imho, a keyboard that would increase in size to take up the extra space in this landscape mode. That way we'll be able to type even faster. If we could add that fuctionality to raster's keyboard, then it'd be just great. that's a matter of just fixing the code to handle resizing appropriately. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com mailto:ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org mailto: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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Mediaplayer
2009/1/6 Dylan Reilly drei...@atariland.net: To tell you the truth, I am not sure. I have always been running the testing distribution, but 2008.12 *should* be more or less the same as testing. No. There were two types of testing image, one using the 2008.12-like qtopia stuff and one using freesmartphone.org. 2008.12 is not using frameworkd, but the qtopia daemons like qpe and qtopia-x11 messaging/dialing/etc. software. 2008.12 does not include the profile switching feature, but like said there are scripts for it. I simply have a python app with a few buttons I can use to switch between profiles for music playback (phone, loudspeakers, headphones). -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
I don't get how the dictionnary (illume and qtopia) actually helps to write some word. To write forest with illume keyboard you just have to type : - near the f key - near the o key - near the r key - near the e key - near the s key - near the t key For each key you type, the illume keyboard makes the hypothesis that you probably type near the right key but not exactly on the right key, so with these 6 different positions (for forest) it searches in its dictionary all the possible words. That's why for and die come together. Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou kimai...@gmail.com babbled: Hi all, I am glad people (re-)start to talk about keyboards. 2 points: * Another great improvement compared to the iphone, illume, etc. ones, would be to have a transparent keyboard, using the whole screen, but allowing to see through it. Of course we need the transparency % to be changed by the user. What about the technical feasibility of that ? Would it be possible ? I thing for example about the Qwo keyboard ( http://www.opkg.org/package_84.html ) which would be very finger friendly in full screen (like the other one) not possible without compositing. not to mention the absolute HORROR of now having to mix keyboard input with controlling the apps under it - which is it u do? press the key or the ok button thats visible thru the key? compositing is not a viable thing on the freerunner - u'll need a much lower res to make it sane and even then it'll be really pushing it at qvga on the 2442. * I don't get how the dictionnary (illume and qtopia) actually helps to write some word. In mobile phones, on which you have only 9 numbers to type, so 3 letters by number, the T9 dictionnary was really helpfull, because it showed a list of words possible with the combination of the letters entered. I could actually write sms faster with only 9 keys than now with a complete qwerty keyboard because the buttons were much bigger and I had only 9 button to search among. Here with the FR, the eyes and brain must locate the desired letter among much more and much smaller keys. And furthermore, I don't see the point with the dictionnary. The dictionnary only shows words with the same number of letters as the ones entered. So it does not provide a way to easily choose a word (for example, when I type for it must show for, forest, force, etc., but with the illume keyboard it only shows for and other useless words like :big, fit, die, but, etc.-- not very related to for ) People using OpenOffice Writer with the autocompletion activated will understand what I am trying to explain with my limited english skills.. ok. let me draw u a keyboard (or part of it): q w e r t y u i o p a s d f g h j k l z x c v b n m i want to type dog. for this example i will only use english as the example - but it applies to all languages actually. now lets say i press d (i want to type dog), then o then g. but look at the keyboard - i may not EXACTLY hit d, o and g. i probably hit them or something near them, so ad i try and hit d i may hit e, and i may hit k and not o, and h instead of g, so i actually hit: ekh that's not dog! of course not. but it also is not any word in english (in the dictionary) so obviously.. it must be wrong. i meant something else. now lets stand back. first key i press e is near d. it's also near r, s, w, and f. let's write the possible keys i may have intended as a list per keystroke: e, d, r, s, w, f now for k (when i meant o): k, i, u, j, m, l, o and for h (when i meant g): h, y, u, j, n, b, g ok so now for every keystroke i have a list of possible keys near where i pressed that i may have meant (again i have simplified this - in reality the list of keys per press is more like 10-15 possible keys as it has a large search area - this is the fuzz value in the .kbd file - it determines how far the fuzzy matching should search in virtual keyboard units). now what we do is start checking all combinations of all the letters per key stroke, so we first try: ekh - wrong eih - wrong euh - wrong ejh - wrong emh - wrong elh - wrong eoh - wrong eky - wrong eiy - wrong euy - wrong ejy - wrong emy - wrong ely - wrong eoy - wrong ekh - wrong eiu - wrong euu - wrong eju - wrong emu - BINGO! a real word! elu - wrong eou - wrong ekj - wrong eij - wrong etc. in the end if you search permutations you'd get a list of words that match emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on. now we have a list of words i possibly wanted that match. (its very much like the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on mapping 26 letters to just 8 numbers on a numberpad - because you have no actual numberpad - its just a surface you tap on and you have a co-ordinate where you press. so you dont NEED to map it that way - you can just present a qwerty layout and just search for nearby keys u may have wanted to hit. anyway - this is the simple version. now.. things get more complex. lets go over the keys i possible wanted to hit again: e, d, r, s, w, f k, i, u, j, m, l, o h, y, u, j, n, b, g unlike the numberpas - the set of keys per press is entirely variable based on what keys are near within the fuzz search radius. also unlike a keypad each key will have a DISTANCE from the point i pressed so i know how far away it is from the press point - thus the further away - the more unlikely it is i wanted it. the closer it is, the more likely. so you can built a list of possible keys i pressed PLUS a
Re: Openmoko keyboard mockup
2009/1/6 kimaidou kimai...@gmail.com: Ok. Thanks both for your usefull answers. @Vasily : T9 is patented, but we can reproduce the same functionnality, as OpenOffice did with Microsoft Office, or am I missing something ? no, t9 is patented in it's entirety. ms office is not patented as a whole, although some parts might be - ms do not own the concepts of a word processor/spreadsheet/presentation editor as raster and om have shown, there are other great methods to input text; i'm sure someone can design more decent methods, without ripping ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default IP Address on All Distributions
wrote: fla...@correo.ugr.es wrote: Sure. And if we go that way, why not use the proper way of setting a link-local address? * Pick a random address * check that it is free (arp, ping,...) * take it. That has a good chance of working, even for those who routinely connect two phones to the same pc at the same time. Helge Hafting I'm not sure to have fully understood you, but I like having the phone always on the same address. There was a suggestion of using link-local addresses. If we do that, then we had better do it properly, because you aren't supposed to grab the same link-local address every time. If that is a problem, the solution is to not use link-local addresses. As long as you have one phone, a fixed IP address works well. If you have two or more, it is better if they are different or resolves the colission automatically. And then we might as well use existing standards. But perhaps there aren't that many people managing several phones from one pc. Helge Hafting Certainly there will be far less, proportionally, with Openmoko success. If Openmoko succeeds - which I presume we all want - then we, the linux hackers, will be the minority of users. The community as it exists right now cannot be considered the long-term target userbase. The more things deviate from 'just works' the more Joe Smartphone-user will consider broken when he can't figure it out. I'm not saying dumb it down, just reiterating my mantra of simple working defaults. I think we need to set a default IP pair in a /30 subnet or at least designate a subnet NOT commonly used, and UI network controls can allow to alter them at need. (or for those who perversely eschew UIs on a touchscreen phone, you can edit the config :) For 'backward-compatibility' (read: our convenience ;) I suggest 192.168.0.202/30 on the FR, .201 on host - machines with .200 can still communicate on this subnet. But my gut tells me we need a clean break and a clean subnet, like 10.19.73.0/24 or 10.79.77.0/24... ;) Something that works for a linux hacker works for us, something that works for the average smartphone user works for Openmoko. But by virtue of who and where we are, we can influence this and hopefully end up with something that just works. j Now when it comes to real users I believe the discussion about the best fixed IP-Number or a pool of dynamic numbers is far too short-sighted. As a true linux user by hard for many year now I have no problem in running a couple of commands to connect my Freerunner to my machine and configure it's internet connection to get some updates. However on the long run, if I will have to continue doing it like that I consider it a confession of failure. M$ and Apple are successful with their devices because users do not have to care at all about IP-Numbers or editing /etc/resolv.conf. Neither do today's Linux-Users as the vast majority is using DHCP on their DSL-(WiFi)-Routers They plug it in or move into a certain location and things just happen as expected. Believe me I don't like the side effects that come with all this automatisms, which is why I bought the freerunner so I have the freedom to change it. However as I sit in front of my desktop day by day already strangling with a more or less constant level of configuration problems (network gone, faulty acpi, xorg update broke screen resolution, etc.). I would really love to have my phone just work sometime in the relatively near future. For example a user friendly but still linux-like phone could ask me: Hey, while you already have decided to go on the internet (via usb or wifi or gprs, it's my decision and not limited by design flaws) shouldn't I download the latest updates in the background? or Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly sync your appointments and contacts with your favourite OpenSync-enabled PIM-Suite (or even with nasty Outlook)? Sorry for pouring out all that stuff here but I felt the urgent need to try to refocus on the efforts. I know it's a lot of work to which I haven't contributed much (yet), but if the Freerunner is supposed do revolutionize the mobile world it needs to do things better or smarter or at leased as good but with more freedom than it's competitors (Windows Mobile, IPhone, Blackberry from my point of view). Regards thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Pascal d'Hermilly pas...@tipisoft.dk writes: a well working finger-friendly keyboard is the most critical missing feature for me. Yes, I find this issue very strange. First and foremost, it is us hackers that use this device for now and are supposed to make apps for freerunner and all, and we don't have a damn keyboard;). All this fancy pancy dictionary based guessing is maybe good for normal people writing crappy SMS messages, but not for the current user base, in my opinion. -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Hi, Fox Mulder quakem...@gmx.net writes: Paul Fertser wrote: Sander van Grieken san...@3v8.net writes: So the question is, when will the default kernel be replaced by the new 2.6.28 andy kernel so that userspace tools could be adapted to it? That would be my question as well. I only care for userspace to be adapted to test the suspend/resume functionality (on FSO, only frameworkd?). frameworkd newer than 31 Dec should properly support both kernels. I'm afraid it's not included in any images yet (please correct me if i am wrong). Latest fso-frameworkd in debian is 0.8.4.3-20081215-1 which is older than 31 dec i would guess. I hope a new version comes very soon so i can try to change from 2.6.24 to the new 2.6.28 kernel. :) Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Aah exactly what I was looking for, thanks Paul. grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Developers guide for dummies - Eclipse
Hello I might start with that I don't have much developer experience(some java/Pascal class in school a few years ago) and im trying to setup eclipse on my ubuntu8.10 machine. I think I have installed it in 3 diffrent places(first 3.2 version second 3.4.4 version and one 3.4.1 with C/C++ platform). Maybe not too good but there it is. Im having problem setting it up. Im told to do: http://wiki.openmoko.org/wiki/Development_with_Eclipse create the managed C project and add `pkg-config --cflags --libs gtk+-2.0` both to the compiler options and to linker flags. and follow the 8 steps on the same page. I have no ide what the compiler options are or what linker flags are. My window looks like this.( http://picasaweb.google.se/lh/photo/Hqo8bETo7P2a9NvcoJ0fbQ?feat=directlink ) ( http://img377.imageshack.us/my.php?image=propertiesforfirstjt3.png ) Did I start on the wrong end here? Did I skip anything important since im a dummie and are starting from 0 as a developer. should I start somewhere else? -- /Robin Häggqvist Robin recommends: http://openoffice.org * http://gimp.org * http://avast.com * http://gmail.com * http://cdburnerxp.se * http://7-zip.org * http://realvnc.com/ or http://www.ubuntu-se.org/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Mediaplayer
Dear Timo, can you share your python app for switching the profiles? On Tue, Jan 6, 2009 at 10:07 AM, Timo Jyrinki timo.jyri...@gmail.comwrote: 2009/1/6 Dylan Reilly drei...@atariland.net: To tell you the truth, I am not sure. I have always been running the testing distribution, but 2008.12 *should* be more or less the same as testing. No. There were two types of testing image, one using the 2008.12-like qtopia stuff and one using freesmartphone.org. 2008.12 is not using frameworkd, but the qtopia daemons like qpe and qtopia-x11 messaging/dialing/etc. software. 2008.12 does not include the profile switching feature, but like said there are scripts for it. I simply have a python app with a few buttons I can use to switch between profiles for music playback (phone, loudspeakers, headphones). -Timo ___ 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: Openmoko keyboard mockup
no, t9 is patented in it's entirety. what exactly is patented that could not be reimplemented? - the system of numbers and characters per key is afaik a well known standard (and dating from long before the mobile era) - hitting the key several times to select a specific symbol was done long before t9 came up - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents so, what does t9 do that's not available already? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Woua ! THAT is a complete explanation ! It shows well the complexity and power of the illume keyboard method. I apologize for not having well understand this before. I will now definitely use the keyboard, and improve my dictionnary as I type. Thanks a lot for the complete explanation 2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou kimai...@gmail.com babbled: Hi all, I am glad people (re-)start to talk about keyboards. 2 points: * Another great improvement compared to the iphone, illume, etc. ones, would be to have a transparent keyboard, using the whole screen, but allowing to see through it. Of course we need the transparency % to be changed by the user. What about the technical feasibility of that ? Would it be possible ? I thing for example about the Qwo keyboard ( http://www.opkg.org/package_84.html ) which would be very finger friendly in full screen (like the other one) not possible without compositing. not to mention the absolute HORROR of now having to mix keyboard input with controlling the apps under it - which is it u do? press the key or the ok button thats visible thru the key? compositing is not a viable thing on the freerunner - u'll need a much lower res to make it sane and even then it'll be really pushing it at qvga on the 2442. * I don't get how the dictionnary (illume and qtopia) actually helps to write some word. In mobile phones, on which you have only 9 numbers to type, so 3 letters by number, the T9 dictionnary was really helpfull, because it showed a list of words possible with the combination of the letters entered. I could actually write sms faster with only 9 keys than now with a complete qwerty keyboard because the buttons were much bigger and I had only 9 button to search among. Here with the FR, the eyes and brain must locate the desired letter among much more and much smaller keys. And furthermore, I don't see the point with the dictionnary. The dictionnary only shows words with the same number of letters as the ones entered. So it does not provide a way to easily choose a word (for example, when I type for it must show for, forest, force, etc., but with the illume keyboard it only shows for and other useless words like :big, fit, die, but, etc.-- not very related to for ) People using OpenOffice Writer with the autocompletion activated will understand what I am trying to explain with my limited english skills.. ok. let me draw u a keyboard (or part of it): q w e r t y u i o p a s d f g h j k l z x c v b n m i want to type dog. for this example i will only use english as the example - but it applies to all languages actually. now lets say i press d (i want to type dog), then o then g. but look at the keyboard - i may not EXACTLY hit d, o and g. i probably hit them or something near them, so ad i try and hit d i may hit e, and i may hit k and not o, and h instead of g, so i actually hit: ekh that's not dog! of course not. but it also is not any word in english (in the dictionary) so obviously.. it must be wrong. i meant something else. now lets stand back. first key i press e is near d. it's also near r, s, w, and f. let's write the possible keys i may have intended as a list per keystroke: e, d, r, s, w, f now for k (when i meant o): k, i, u, j, m, l, o and for h (when i meant g): h, y, u, j, n, b, g ok so now for every keystroke i have a list of possible keys near where i pressed that i may have meant (again i have simplified this - in reality the list of keys per press is more like 10-15 possible keys as it has a large search area - this is the fuzz value in the .kbd file - it determines how far the fuzzy matching should search in virtual keyboard units). now what we do is start checking all combinations of all the letters per key stroke, so we first try: ekh - wrong eih - wrong euh - wrong ejh - wrong emh - wrong elh - wrong eoh - wrong eky - wrong eiy - wrong euy - wrong ejy - wrong emy - wrong ely - wrong eoy - wrong ekh - wrong eiu - wrong euu - wrong eju - wrong emu - BINGO! a real word! elu - wrong eou - wrong ekj - wrong eij - wrong etc. in the end if you search permutations you'd get a list of words that match emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on. now we have a list of words i possibly wanted that match. (its very much like the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on mapping 26 letters to just 8 numbers on a numberpad - because you have no actual numberpad - its just a surface you tap on and you have a co-ordinate where you press. so you dont NEED to map it that way - you can just present a qwerty layout and just search for nearby keys u may have wanted to hit. anyway - this is the simple version. now.. things get more complex. lets go over the keys i possible wanted to hit again:
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 11:20:12 +0100 arne anka openm...@ginguppin.de babbled: no, t9 is patented in it's entirety. what exactly is patented that could not be reimplemented? - the system of numbers and characters per key is afaik a well known standard (and dating from long before the mobile era) - hitting the key several times to select a specific symbol was done long before t9 came up - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents the last bit is patented. matching it to a dictionary (when combined with the first 2). this is the patent. when combined with a numberpad and key combinations per number - to use a dictionary to auto-guess the key you wanted without having to cycle through all keys with multiple presses on a key. so, what does t9 do that's not available already? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hi, Carsten Haitzler (The Rasterman) ras...@rasterman.com writes: what exactly is patented that could not be reimplemented? ... - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents the last bit is patented. matching it to a dictionary (when combined with the first 2). this is the patent. when combined with a numberpad and key combinations per number - to use a dictionary to auto-guess the key you wanted without having to cycle through all keys with multiple presses on a key. But isn't it a software patent and therefore unenforceable in any sane jurisdiction? It seems many people just can't believe how bad software patents are if they can be enforced. So bad it's hard to imagine. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
no, t9 is patented in it's entirety. what exactly is patented that could not be reimplemented? - the system of numbers and characters per key is afaik a well known standard (and dating from long before the mobile era) - hitting the key several times to select a specific symbol was done long before t9 came up - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents the last bit is patented. matching it to a dictionary (when combined with the first 2). this is the patent. when combined with a numberpad and key combinations per number - to use a dictionary to auto-guess the key you wanted without having to cycle through all keys with multiple presses on a key. sounds to my like a combination of prior art and triviality -- but probably no one has time or money to dispute it ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 13:37:41 +0300 Paul Fertser fercer...@gmail.com babbled: Hi, Carsten Haitzler (The Rasterman) ras...@rasterman.com writes: what exactly is patented that could not be reimplemented? ... - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents the last bit is patented. matching it to a dictionary (when combined with the first 2). this is the patent. when combined with a numberpad and key combinations per number - to use a dictionary to auto-guess the key you wanted without having to cycle through all keys with multiple presses on a key. But isn't it a software patent and therefore unenforceable in any sane jurisdiction? It seems many people just can't believe how bad software patents are if they can be enforced. So bad it's hard to imagine. you might be surprised how many jurisdictions its enforceable in. several companies have been taken to court and lost over this patent - having to pay up. and they had to pay up big-time. millions of $. now you can do your own software for your own software patents can go suck a duck world - but the moment that software goes to major markets in the world and is distributed and/or used - people are in danger of litigation over a successfully defended patent. and even worse - they are up for extra damages as you now KNOW about the patent - if you don't know you get off lighter. the moment it can be shown you knew and violated it anyway... you are in deep trouble. yes - software patents suck - but they are a reality of life unfortunately. i wish they didn't exist. even places where software patents don't apply - they are normally enforceable when COMBINED with hardware. so that means OM can't ever ship a product with such an input system so it's useless to om as its combined with hardware - even if it's an extra download later - OM is directly involved in development of the software and hosting repositories of software to download etc. etc. so they are playing with fire even having anything to do with such an input method. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 11:39:02 +0100 arne anka openm...@ginguppin.de babbled: no, t9 is patented in it's entirety. what exactly is patented that could not be reimplemented? - the system of numbers and characters per key is afaik a well known standard (and dating from long before the mobile era) - hitting the key several times to select a specific symbol was done long before t9 came up - completing a word from a dictionary based on the already available string is done by several keyboard apps (even xvkbd afaik) w/o violating any patents the last bit is patented. matching it to a dictionary (when combined with the first 2). this is the patent. when combined with a numberpad and key combinations per number - to use a dictionary to auto-guess the key you wanted without having to cycle through all keys with multiple presses on a key. sounds to my like a combination of prior art and triviality -- but probably no one has time or money to dispute it ... they do. they have. and they have lost. patent has withstood the court system. and that cost them dearly. google it. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
I like the illume keyboard! I like it a lot. Word matching is working for me very well even for thumb. I get exact words with my finger in a majority of cases. Dictionaries. It seems like a lot of people blame Raster's keyboard for not getting word matches because of the lack of dictionary. Do you really expect Rasterman to make dictionaries for every language? Dictionary format is very simple. In conclusion - for our screen, from all possible qwerty keyboards - Raster's is the best one. Maybe some other inpout method would be good, but as for keyboard it's actually very very impressive. Leonti ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 12:02:40 +0100 Esben Stien b...@esben-stien.name babbled: Pascal d'Hermilly pas...@tipisoft.dk writes: a well working finger-friendly keyboard is the most critical missing feature for me. Yes, I find this issue very strange. First and foremost, it is us hackers that use this device for now and are supposed to make apps for freerunner and all, and we don't have a damn keyboard;). All this fancy pancy dictionary based guessing is maybe good for normal people writing crappy SMS messages, but not for the current user base, in my opinion. you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as opposed to strings. don't like the keys on that .kbd? edit the .kbd file. change it yourself! its just text! i tackled both sides of the problem in 1 bit of code. if you want you can install and use the matchbox keyboard or the matchbox numberpad keyboard too- they both work. they need a little extra packaging with a .desktop file - but they are selectable. i tried to cover pretty much everything anyone could want - an internal built-in kbd capable of both dictionary fixup entry and simple straight-through terminal keyboard, able to have that just disabled in favor of an external keyboard window provided by any process, as well as protocols that are robust for hinting if you want keyboard entry or not and what kind of entry (numeric, password, terminal) etc. i've laid a lot of the groundwork and filled in a lot of the boxes too - can't expect me to do EVERYTHING for EVERYONE... but i tried to cover a good smattering. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Illume keyboard dictionary sorting and normalization
Hi, I'm working on a Swedish dictionary and keyboard for Illume, but I'm having some trouble with sorting of utf8 chars in the dictionary. I can't seem to get the sorting right. Looking at the code, Illume sorts the dictionary after first normalizing the strings according to the internal normalization table. Is there any way to reproduce this sorting with the sort command? I've tried with a few different locales (C, en_US.utf8) which all make the unix sort command work differently. But no matter what I try words don't show up correctly. Another issue I found is that the built in normalization table is not very good for typing Swedish text. On a standard Swedish qwerty layout, we have three additional letters (å, ä and ö). These are used very frequently in Swedish and there are many common words that have different meanings if spellt with a, å or ä (for example har, här and hår are all very common words). But in Illume these are all normalized to a. Writing Swedish with a US qwerty layout and then having to select aåä manually after the dictionary lookup is a pain, since many common words will have to be selected from the lookup list each time. Instead, what you want is a Swedish qwerty layout (which is very simple to implement as a .kbd file), and not normalize åäö for the Swedish dictionary lookup. So the normalization table would really need to be configurable, either as a part of the dictionary or the .kbd file. I suppose this problem exists for other languages as well. If I were to work on such a change, what would be the best approach? Best regards, Olof Sjobergh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com: you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as following on from this, would a hybrid of the two (the terminal kb no guesses, and the dictionary lookup kb) be possible? it can be very frustrating to think a long word will be in the dictionary, type it, find it's not in the dictionary, and have to delete it, switch to the terminal kb and type it again. when the list of possible words comes up, it would be very useful to have the kb give the exact sequence of letters, as typed, as one option, alongside the dictionary guesses ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default IP Address on All Distributions
Thomas Otterbein wrote: Now when it comes to real users I believe the discussion about the best fixed IP-Number or a pool of dynamic numbers is far too short-sighted. As a true linux user by hard for many year now I have no problem in running a couple of commands to connect my Freerunner to my machine and configure it's internet connection to get some updates. However on the long run, if I will have to continue doing it like that I consider it a confession of failure. Sure. The default should just work. And there should be configurability for those with different needs. Such as updating 30 company phones all connected to the same usb hub... M$ and Apple are successful with their devices because users do not have to care at all about IP-Numbers or editing /etc/resolv.conf. Neither do today's And they fail because you usually can't do anything out of the ordinary. Connect just one phone to the PC at a time, please. Connect two phones to each other with a usb cable? Why would anyone want that? A networked phone game that doesn't need to call into one of our servers - where is the money in that . . . Linux-Users as the vast majority is using DHCP on their DSL-(WiFi)-Routers They plug it in or move into a certain location and things just happen as expected. Believe me I don't like the side effects that come with all this automatisms, which is why I bought the freerunner so I have the freedom to change it. However as I sit in front of my desktop day by day already strangling with a more or less constant level of configuration problems (network gone, faulty acpi, xorg update broke screen resolution, etc.). I would really love to have my phone just work sometime in the relatively near future. I agree that it should just work as far as possible. And the expert user can always make changes precisely because this is linux. Still, the way to just works is to use existing standards as much as possible. A fixed IP address is a last resort. Use that only if we have to. If this phone (or the next one) makes it to mass markets, then there will be families with several phones. It may be convenient to charge update them at the same time from the same PC. Your friend with the same phone might visit. You may want to surf the net at the same time. It'd be nice if all this just works too, and it won't when all phones share a fixed address. Running DHCP on the PC's usb interface is one way to make this case just work. Combining link-local addresses with NAT is perhaps another way. A fixed address won't do the trick. Either way, some software has to be set up on the PC. But that is OK, even windows people are used to installing a driver CD in order to connect their new phone to the computer. If this software then allows plugging in all your phones at the same time, so much the better! For example a user friendly but still linux-like phone could ask me: Hey, while you already have decided to go on the internet (via usb or wifi or gprs, it's my decision and not limited by design flaws) shouldn't I download the latest updates in the background? or Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly sync your appointments and contacts with your favourite OpenSync-enabled PIM-Suite (or even with nasty Outlook)? Do this or don't do this. Make it a setup option. But please - don't pop up questions! Questions that pop up while I use the phone gets in my way - yuk. Questions that pop up while the phone is in my pocket just wastes CPU effort and drains the battery. And it is particularly nasty if I pull the phone out of my pocket to make a call, and have to wade through 2-3 items that popped up since the last use - items that may even be irrelevant now that I have moved around. With SHR I already get one such popup - the one that suggests charging the nearly empty battery. The warning makes sense, but I usually put the phone on charging without looking at the screen, and the popup hang around forever until I need to use the thing. So often enough, I see this power complaint combined with a full battery. Of course this case can be fixed - the phone notices that power gets plugged in, and could remove the warning. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 6 Jan 2009 23:55:13 +1300 Robin Paulson robin.paul...@gmail.com babbled: 2009/1/6 The Rasterman Carsten Haitzler ras...@rasterman.com: you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as following on from this, would a hybrid of the two (the terminal kb no guesses, and the dictionary lookup kb) be possible? it can be very frustrating to think a long word will be in the dictionary, type it, find it's not in the dictionary, and have to delete it, switch to the terminal kb and type it again. when the list of possible words comes up, it would be very useful to have the kb give the exact sequence of letters, as typed, as one option, alongside the dictionary guesses hold and press -to zoom and select keys. once in the dict - its in. and yes its possible to make a version of the basic (Default) qwerty that doesnt use the dict - just do a .kbd file- look at the terminal and default kbd files and work it out - its easy to figure that one out :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 11:53:37 +0100 Mathieu Rochette math...@gmail.com babbled: Shashank Bharadwaj wrote: On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler ras...@rasterman.com mailto:ras...@rasterman.com wrote: On Tue, 06 Jan 2009 02:46:15 + Jan Henkins j...@henkins.za.net mailto:j...@henkins.za.net babbled: Hello there, Pascal d'Hermilly wrote: With 2008.12 release, a well working finger-friendly keyboard is the most critical missing feature for me. I've made a mockup of a keyboard that I think would make things a lot easier to type. http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png I think, the current Raster's Keyboard great for potrait mode. For landscape mode(i.e holding neo sideways) however, the keyboard does not utilize the extra space. What we need is, imho, a keyboard that would increase in size to take up the extra space in this landscape mode. That way we'll be able to type even faster. If we could add that fuctionality to raster's keyboard, then it'd be just great. if you start the keyboard in landscape mode, it does utilize all available place and it's great :) (in keyboard settings, just select non and then default while in landscape mode) Another thing, I can't test it from office, but, is it possible to have multiple at the same position, if so one could make a t9 like layout just put, abc on the same position, def, on another, etc. would that be possible? no it's not possible as they'd overlap and you'd not see the ones underneath - BUT you could do just as well with: [...@][!][?][.] [ a][ b][ c] [ d][ e][ f] [ g][ h][ i] [ j][ k][ l] [ m][ n][ o] [p][q][r][s] [ t][ u][ v] [w][x][y][z] [ * ][] [ + ][ . ] [ # ][ ] (make it a bit taller). :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.3
Thomas White wrote: Helge Hafting helge.haft...@hist.no wrote: My SHR is unable to open audio. But the older moocow worked with the same setup. I can stop speech-dispatcher, but it doesn't help. There is no snd-pcm-oss module to load, bt the previous moocow didn't need that. Previous meaning version 0.2? All the previous versions are available from my site: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ - would you be able to check version 0.2 again to be sure? This is particularly puzzling because the audio parts of the program haven't been touched between 0.2 and 0.3... Strange. I must have done something wrong, this time both version 0.2-r2 and version 0.3 moos, as soon as I stop speech-dispatcher. The accelerometers don't work though. hexdump /dev/input/event2 gets me changing output as I turn the phone around. event3 is dead, perhaps that is the problem? I have a 2.6.24 kernel, as SHR doen't work well with 2.6.28 yet. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hi Raster, thanks for the explanation. anyway. i hope this helps people understand how it works. someone can throw this onto the wiki if they like. this is the code i wrote for the illume kbd I've summarized this in a page: http://wiki.openmoko.org/wiki/Illume_keyboard it's cool, you should really patent it! :-))) ciao, leonardo. -- http://leonardo.lilik.it Key fingerprint = 2C20 A587 05AC 42E5 1292 D0D4 3EED CFB5 52FD AD1E ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default IP Address on All Distributions
Hi Helge, I largely agree with you. Yes of course every needs to be widely configurable. To me the phone be able to be confiured to a range starting from fixed IP and just sitting there waiting for it's masters orders to booking automatically into known WLANs and downloading updates without any user interaction. Between these two extremes there are numerous layers of asking for permission/confirmation, just notifying me of something, etc., which of course should also be configurable. Probably a standard for convenience levels would help to describe what the phone should do or not do. Or usage scenarios like I'm just a user on holiday, trying to find the next free wifi hotspot or I'm the companies administrator and believe me I know what I'm doing. Applications or the phone as such could adhere to this and behave appropriate. Regards thomas On Tuesday 06 January 2009 12:03 Helge Hafting wrote: Thomas Otterbein wrote: Now when it comes to real users I believe the discussion about the best fixed IP-Number or a pool of dynamic numbers is far too short-sighted. As a true linux user by hard for many year now I have no problem in running a couple of commands to connect my Freerunner to my machine and configure it's internet connection to get some updates. However on the long run, if I will have to continue doing it like that I consider it a confession of failure. Sure. The default should just work. And there should be configurability for those with different needs. Such as updating 30 company phones all connected to the same usb hub... M$ and Apple are successful with their devices because users do not have to care at all about IP-Numbers or editing /etc/resolv.conf. Neither do today's And they fail because you usually can't do anything out of the ordinary. Connect just one phone to the PC at a time, please. Connect two phones to each other with a usb cable? Why would anyone want that? A networked phone game that doesn't need to call into one of our servers - where is the money in that . . . Linux-Users as the vast majority is using DHCP on their DSL-(WiFi)-Routers They plug it in or move into a certain location and things just happen as expected. Believe me I don't like the side effects that come with all this automatisms, which is why I bought the freerunner so I have the freedom to change it. However as I sit in front of my desktop day by day already strangling with a more or less constant level of configuration problems (network gone, faulty acpi, xorg update broke screen resolution, etc.). I would really love to have my phone just work sometime in the relatively near future. I agree that it should just work as far as possible. And the expert user can always make changes precisely because this is linux. Still, the way to just works is to use existing standards as much as possible. A fixed IP address is a last resort. Use that only if we have to. If this phone (or the next one) makes it to mass markets, then there will be families with several phones. It may be convenient to charge update them at the same time from the same PC. Your friend with the same phone might visit. You may want to surf the net at the same time. It'd be nice if all this just works too, and it won't when all phones share a fixed address. Running DHCP on the PC's usb interface is one way to make this case just work. Combining link-local addresses with NAT is perhaps another way. A fixed address won't do the trick. Either way, some software has to be set up on the PC. But that is OK, even windows people are used to installing a driver CD in order to connect their new phone to the computer. If this software then allows plugging in all your phones at the same time, so much the better! For example a user friendly but still linux-like phone could ask me: Hey, while you already have decided to go on the internet (via usb or wifi or gprs, it's my decision and not limited by design flaws) shouldn't I download the latest updates in the background? or Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly sync your appointments and contacts with your favourite OpenSync-enabled PIM-Suite (or even with nasty Outlook)? Do this or don't do this. Make it a setup option. But please - don't pop up questions! Questions that pop up while I use the phone gets in my way - yuk. Questions that pop up while the phone is in my pocket just wastes CPU effort and drains the battery. And it is particularly nasty if I pull the phone out of my pocket to make a call, and have to wade through 2-3 items that popped up since the last use - items that may even be irrelevant now that I have moved around. With SHR I already get one such popup - the one that suggests charging the nearly empty battery. The warning makes sense, but I usually put the phone on charging without looking at the screen, and the popup hang around forever until I
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 12:34:28 +0100 leona...@lilik.it leona...@lilik.it babbled: Hi Raster, thanks for the explanation. anyway. i hope this helps people understand how it works. someone can throw this onto the wiki if they like. this is the code i wrote for the illume kbd I've summarized this in a page: http://wiki.openmoko.org/wiki/Illume_keyboard it's cool, you should really patent it! :-))) i'd rather not. 1. trollt.. err.. nokia deserve thanks for the core inspiration and initial work on their one - i didn't know how the code worked until later but i nutted out how it probably should work just by poking at it. so if anyone deserves a patent - it's them. 2. i'd rather this be well publicised and out there code in the public eye - so the idea is widespread and well known - thus serves as prior art pretty much making it impossible for someone to come along and patent the idea and make things a pain. get the ideas out there in code - in the public eye with a trail of history so it's available for everyone to see and use. if someone implements a better kbd but steals the same idea - i'm sticking my thumbs up going good on-ya mate! i want users and the community to benefit. 3. i fundamentally disagree with software patents - or at least the way they have been implemented. the vast majority i have seen are neither novel nor non-obvious to someone skilled in the art. most are incredibly mundane straightforward things to someone skilled in the art and the system has been abused to further greed and misplace credit in the hands of those with more lawyers, not those who innovate the most or the best. be that as it may - the system is there and we are stuck with it. i'm not a crusader trying to bring it down - i don't have the time. got code to write and ideas to make happen :) but i hope in my little way i can shake my fist at the system and go here... prior art. take that!. i'll let others fight the good fight in trying to reform the patent system. i'm just rattling my chains and moaning in my corner... 'brains! brains! braiins! need moore brains!' :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hi I like the idea to create a new layout with the well known phone arrangement : [] [abc] [def] [ghi] [jkl] [mno] [pqrs] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
SorrI just sent it to fast: here is the end of my message : 2009/1/6 kimaidou kimai...@gmail.com Hi I like the idea to create a new layout with the well known phone arrangement : [] [abc] [def] [ghi] [jkl] [mno] [pqrs] [tuv] [wxyz] Do you think it will help to type faster with illume keyboard ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 6 Jan 2009 12:46:41 +0100 kimaidou kimai...@gmail.com babbled: SorrI just sent it to fast: here is the end of my message : 2009/1/6 kimaidou kimai...@gmail.com Hi I like the idea to create a new layout with the well known phone arrangement : [] [abc] [def] [ghi] [jkl] [mno] [pqrs] [tuv] [wxyz] Do you think it will help to type faster with illume keyboard ? no. as its the same # of keys - same letters, simply laid out differently. those used to phone keypads who like them much more than qwerty may prefer it - those used to qwerty will do nothing but swear and curse. my bet is more people are more proficient at qwerty than at abcdefgh... (those really proficient at abcdefgh are ALSO likely to be really good at qwerty too - the teenagers and young people totally addicted to smsing eachother on their phones probably also are pretty good at tapping away on their instant messengers on their laptops/desktops - but thats just my bet on the audience). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Shashank Bharadwaj wrote: On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler ras...@rasterman.com mailto:ras...@rasterman.com wrote: On Tue, 06 Jan 2009 02:46:15 + Jan Henkins j...@henkins.za.net mailto:j...@henkins.za.net babbled: Hello there, Pascal d'Hermilly wrote: With 2008.12 release, a well working finger-friendly keyboard is the most critical missing feature for me. I've made a mockup of a keyboard that I think would make things a lot easier to type. http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png I think, the current Raster's Keyboard great for potrait mode. For landscape mode(i.e holding neo sideways) however, the keyboard does not utilize the extra space. What we need is, imho, a keyboard that would increase in size to take up the extra space in this landscape mode. That way we'll be able to type even faster. If we could add that fuctionality to raster's keyboard, then it'd be just great. if you start the keyboard in landscape mode, it does utilize all available place and it's great :) (in keyboard settings, just select non and then default while in landscape mode) Another thing, I can't test it from office, but, is it possible to have multiple at the same position, if so one could make a t9 like layout just put, abc on the same position, def, on another, etc. would that be possible? Mathieu. Just my INR 0.02. -- Regards Shashank As our circle of knowledge expands, so does the circumference of darkness surrounding it - Albert Einstein ___ 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: Openmoko keyboard mockup
On Tue, 6 Jan 2009 10:14:19 +0100 kimaidou kimai...@gmail.com babbled: Ok. Thanks both for your usefull answers. @Vasily : T9 is patented, but we can reproduce the same functionnality, as OpenOffice did with Microsoft Office, or am I missing something ? no you can't a patent coverts any form of reproduction of the idea. its not copyright. the way the illume kbd works as best i know bypasses apples patent on the iphone kbd (which enlarges hit areas for keys based on the most likely key you want next also based on dictionary lookup) as it works differently (not playing with hit areas at all but using distances to keys). it doesnt do anything like t9 that could be violating the patent - so as such unless you come up with a better way to enter stuff that isnt patented... good luck! my take on the Fr touchscreen: 1. avoid drags - you have to press hard with a finger to retain enough pressure to keep a press down. it's a resistive screen meant for a stylus - a sharp point. a finger is not a small sharp point thus more pressure is needed to keep things down soa press is registered and stays registered. 2. stick to taps - it's easy to tap a finger down with a bit of speed to thus get enough momentum and press the screen to get a tap - but maintaining as above is much harder and should be avoided. so input methods that need a press +drag (a lot) are going to be painful with fingers - avoid them like the plague. they are nice theories - and work with styluses. good luck doing it with a finger. so.. now you want an input method that uses taps. you want something that is familiar/easily learnable by people. you can do dasher. you can do all sorts of out-there input methods people dream up. humans are creatures of habit. we like the familiar. so... you could go the qwerty - familiar if you ever used a computer or typewriter or abc def ghi ... arrangement (in fact the illume kbd can do this just fine - go make a .kbd file with keys laid out like they are on a numberpad! it will work - just fine! thats the idea of .kbd layout files - it puts the power in the hands of (advanced) users without having to code to be able to do new keyboard layouts). the core dictionary and fuzzy matching code is the same and applies to both. some people will find the qwerty layout more familiar - some the abc def ghi etc. numberpad layout better... all the mechanisms, file formats and power is there - just waiting to be harnessed. :) (i love writing stuff to be generic to tackle a problem in a broad way to solve lots of problems in one foul swoop - it is a painful entry barrier to get it done to begin with, but once done and tuned - is nice how its so flexible with just some config swizzling - it solves a problem a whole new way etc.) :) @Xavier : Ah ah, I completely lost this one ! I wil try it now @ both and others : what about transparency ? see my long long long email about the kbd. :) 2009/1/6 Xavier Cremaschi omega.xav...@gmail.com I don't get how the dictionnary (illume and qtopia) actually helps to write some word. To write forest with illume keyboard you just have to type : - near the f key - near the o key - near the r key - near the e key - near the s key - near the t key For each key you type, the illume keyboard makes the hypothesis that you probably type near the right key but not exactly on the right key, so with these 6 different positions (for forest) it searches in its dictionary all the possible words. That's why for and die come together. Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR/Debian] Update to BtGPS.py
If you suggest me to enter the application in opkg, i will say why not, but I think the author is the best person to do it. This way he can give the link to website, better explain the app, and give a link to an .ipk file instead of a python file if he wants to. Not having yet the knowledge for creating a package, I cannot do it. But I got your point, and I think you are right. 2009/1/6 Minh Ha Duong hadu...@centre-cired.fr Le mardi 06 janvier 2009, kimaidou a écrit : Hi Angus What about putting this app on the opkg.org website, so people would easily find it ? Thanks anyway for sharing your work I would like to kindly share my recent experience with opkg.org. Entering or updating an application page is really simple. Just fill a form with half a dozen fields. Anybody can do it, it does not need to be done by the author. I recon it is not as simple as writing an email to ask someone else to do it, but almost ;) ... Yours, Minh ___ 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: Offer to write some neat programs for the Freerunner
Sargun Dhillon xbmodder+openm...@gmail.com writes: IMAP IDLE is not a push mechanism... SMS is a push mechanism. Something that doesn't require the FR to be out of suspend mode before You can be in suspend with GPRS connected. The only trouble is that port scanners will wake up your phone all the time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
El Martes, 6 de Enero de 2009, Carsten Haitzler escribió: [...] my bet is more people are more proficient at qwerty than at abcdefgh... (those really proficient at abcdefgh are ALSO likely to be really good at qwerty too - the teenagers and young people totally addicted to smsing eachother on their phones probably also are pretty good at tapping away on their instant messengers on their laptops/desktops - but thats just my bet on the audience). I agree. I feel better with something like this... but using two fingers. [ q w e ] [ r t ] [ y u ] [ i o p ] [ a s d ] [ f g ] [ h j ] [ k l ; ] [ z x c ] [ v b ] [ n m ] [ , . / ] [space ] This one is quicker than previous, but the number of dictionary suggestions has to be studied. [ q w e r t ] [ y u i o p ] [ a s d f g ] [ h j k l ; ] [ z x c v b ] [ n m , . / ] [space ] For example, the word house... not too bad results. $ egrep ^[hjkl;][yuiop][yuiop][asdfg][qwert]$ /usr/share/dict/american-english hoist house joist joust loose louse Perhaps this one would be better for one finger only: [ q w e ] [ r t y u ] [ i o p ] [ a s d ] [ f g h j ] [ k l ; ] [ z x c ] [ v b n m ] [ , . / ] [space ] $ egrep ^[fghj][iop][rtyu][asd][qwe]$ /usr/share/dict/american-english gorse horde horse house -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hello Raster, On Tue, January 6, 2009 09:56, Carsten Haitzler wrote: ok. let me draw u a keyboard (or part of it): q w e r t y u i o p a s d f g h j k l z x c v b n m Excellent! Better than any info currently on the WIKI (I could only find reference to the qtopia keyboard and it's usage). Would you mind if I or somebody else put this into the WIKI? -- Regards, Jan Henkins ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 6 Jan 2009 12:28:09 - (UTC) Jan Henkins j...@henkins.za.net babbled: Hello Raster, On Tue, January 6, 2009 09:56, Carsten Haitzler wrote: ok. let me draw u a keyboard (or part of it): q w e r t y u i o p a s d f g h j k l z x c v b n m Excellent! Better than any info currently on the WIKI (I could only find reference to the qtopia keyboard and it's usage). Would you mind if I or somebody else put this into the WIKI? someone just did... leonardo: http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - feel free to just copy and paste it out or re-type/edit/whatever as i said at the bottom - throw it up on the wiki :) i'm just here to spew forth mindless babble about what i know of the internals of code i wrote. :) you guys can make it into some usable document! that's teamwork! i babble incoherently. you guys make it coherent :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Hi! First and foremost, it is us hackers that use this device for now and are supposed to make apps for freerunner and all, and we don't have a damn keyboard;). All this fancy pancy dictionary based guessing is maybe good for normal people writing crappy SMS messages, but not for the current user base, in my opinion. you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as opposed to strings. don't like the keys on that .kbd? edit the .kbd file. change it yourself! its just text! Im planning to develop an application, where is a table, and in each column I want different keyboard layout with different dictionary. Is it possible to change layout and dictionary on the fly? (ie. entering in another text input field). The application would be something, in the first column is only numbers, so I want a keyboard with [0..9-.] buttons, and accept only numbers. In the second column I want to write down what I see (microwave, lamp, soldering iron, etc) and in the third column I want to write the trademark of it (sony, samsung, philips, weller, etc) so I want to change the keyboard between numeric and qwerty, and I want to change the dictionary as of input text field. Is it doable? If so where to start? I know python, and would be glad to see some debian/ubuntu guide how to start programming in efl. (or is it a complete development virtualbox/qemu image? it was discussions about some time ago). Thank you in advance. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 2009-01-06 at 01:51 +0100, Pascal d'Hermilly wrote: With 2008.12 release, a well working finger-friendly keyboard is the most critical missing feature for me. I've made a mockup of a keyboard that I think would make things a lot easier to type. http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png I don't have the skills to code this, but please. I really need a good keyboard to be able to use my openmoko. Best regards from Pascal, Denmark ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community The most interesting thing about this mockup for me is that it doesn't try to make the rest of the UI usable. It reminds me of this keyboard: http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png Where the entire screen is a keyboard. Perhaps a good way to get this idea working would be to have a fullscreen button on the existing keyboard so you can toggle it when you want to. Kieran Fleming ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Carsten Haitzler (The Rasterman) schrieb: ok. let me draw u a keyboard (or part of it): q w e r t y u i o p a s d f g h j k l z x c v b n m Excellent! Better than any info currently on the WIKI (I could only find reference to the qtopia keyboard and it's usage). Would you mind if I or somebody else put this into the WIKI? someone just did... leonardo: http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - feel free to just copy and paste it out or re-type/edit/whatever as i said at the bottom - throw it up on the wiki :) i'm just here to spew forth mindless babble about what i know of the internals of code i wrote. :) you guys can make it into some usable document! that's teamwork! i babble incoherently. you guys make it coherent :) And please don't miss to merge and link it with [1] to avoid redundancy or conflicts. Thanks, Marc [1] http://wiki.openmoko.org/wiki/Illume#How_to_use_.28Raster.27s.29_keyboard_.3F ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Paul Fertser wrote: Hi, Fox Mulder quakem...@gmx.net writes: Paul Fertser wrote: Sander van Grieken san...@3v8.net writes: So the question is, when will the default kernel be replaced by the new 2.6.28 andy kernel so that userspace tools could be adapted to it? That would be my question as well. I only care for userspace to be adapted to test the suspend/resume functionality (on FSO, only frameworkd?). frameworkd newer than 31 Dec should properly support both kernels. I'm afraid it's not included in any images yet (please correct me if i am wrong). Latest fso-frameworkd in debian is 0.8.4.3-20081215-1 which is older than 31 dec i would guess. I hope a new version comes very soon so i can try to change from 2.6.24 to the new 2.6.28 kernel. :) Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Ok. I downloaded the fso-frameworkd source, copied the patch into it and applied it without any problems. Now do i install the fso-frameworkd with ./setup.py install ? But i have the problem that on [1] only the 2.6.28 kernel but no modules are online. Where do i get the corresponsing modules for this kernel? Last time i checked there was an older kernel with a modules package but no more. Ciao, Rainer [1] http://people.openmoko.org/andy/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Report] - Buzz fix
The .pdf says this hardware fix transforms a GTA02v5 with buzz into a GTA02v7-equivalent (without buzz). But is the GTA02v7 currently produced and/or sold ? The wiki seems to stop at GTA02v6 (for which buzz is still a possibility). Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Hi, Fox Mulder quakem...@gmx.net writes: Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Ok. I downloaded the fso-frameworkd source, copied the patch into it and applied it without any problems. Now do i install the fso-frameworkd with ./setup.py install ? That's distribution-dependent. I'd suggest to apply the patch to the frameworkd you have already installed and change /etc/freesmartphone/oevents/rules.yaml by hand. Or if you want to try to install from source, you probably don't need any patches at all, as you can install a version recent enough (though it's possible that some SHR apps are not ready yet). But i have the problem that on [1] only the 2.6.28 kernel but no modules are online. Where do i get the corresponsing modules for this kernel? Last time i checked there was an older kernel with a modules package but no more. I think it's assumed that everything you need for everyday work is compiled-in. If you want to use some webcams or other unusual devices, just compile a kernel yourself from git, it's not hard. Or ask Andy to provide all the modules ;) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Buzz fix attempt, tomorrow
Hello Community, Tommorow, I (my colleague, actually) will try to fix the buzz of my OM version A5 according to the manual of Joerg. If any of you have some last minute advice to give me, I take :) I can take pictures and make a report of my experience if you think that's necessary. I don't know so just tell me. Bye. -- Yoann ARNAUD Nantes, France. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hardware buzz - can OpenMoko help?
To whom this may concern... I've been using my FreeRunner for some time now, and although some points keep irking me (esp. sound and accelerometers after suspend/resume), it's more and more a daily phone. Except for the buzz. The last few days, people have constantly complained about a loud, high-pitched noise when I call them. I presume it's the 'ahrdware buzz' we're talking about here. I am unable to do the hardware fix for this, myself, and I find it troublesome to go somewhere and get my (still expensive!) phone 'fixed'. I'd rather have an OpenMoko (or FIC) engineer fix this for me, but shipping would be prohibitively expensive, I guess. Here's a thought... on Februari 7th and 8th there will be the Fosdem event, in Brussels, Belgium. Would it be possible to send someone over with an SMD soldering iron, a boatload of capacitors and other stuff needed to do the SD-card cap and buzz cap fix? I'd gladly pay a couple of euro's (10? 20?) to get this fixed in a way that I know it will be done correctly. If enough geeks show up with their phones, paying 10 or 20 euro... I have no idea how many phones were sold in Europe, and how much time it takes to do the fix, so I can't calculate costs vs. money, but perhaps this would be a way to help us users from 'far away'. Thoughts? Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Laszlo KREKACS wrote: Hi! First and foremost, it is us hackers that use this device for now and are supposed to make apps for freerunner and all, and we don't have a damn keyboard;). All this fancy pancy dictionary based guessing is maybe good for normal people writing crappy SMS messages, but not for the current user base, in my opinion. you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as opposed to strings. don't like the keys on that .kbd? edit the .kbd file. change it yourself! its just text! Im planning to develop an application, where is a table, and in each column I want different keyboard layout with different dictionary. Is it possible to change layout and dictionary on the fly? (ie. entering in another text input field). The application would be something, in the first column is only numbers, so I want a keyboard with [0..9-.] buttons, and accept only numbers. In the second column I want to write down what I see (microwave, lamp, soldering iron, etc) and in the third column I want to write the trademark of it (sony, samsung, philips, weller, etc) so I want to change the keyboard between numeric and qwerty, and I want to change the dictionary as of input text field. Is it doable? If so where to start? I know python, and would be glad to see some debian/ubuntu guide how to start programming in efl. (or is it a complete development virtualbox/qemu image? it was discussions about some time ago). this is be doable. keyboard application can receive message for client, message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE and message data is one of: - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD (I don't know where this list came from, is there some specification or recommendation for virtual keyboard application implementation?) so, the application just have to send one of those messages when entering a field or another. Mathieu. Thank you in advance. Laszlo ___ 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: Hardware buzz - can OpenMoko help?
Christ van Willegen cvwille...@gmail.com writes: The last few days, people have constantly complained about a loud, high-pitched noise when I call them. I presume it's the 'ahrdware buzz' we're talking about here. The buzz seems to be proportional to the transmit power which itself seems to be proportional to the reception quality I can monitor with mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 According to specs these units are # 0-113 dBm or less # 1-111 dBm # 2...30 -109... -53 dBm # 31 -51 dBm or greater # 99 not known or not detectable and when it is around 26 or more the recipient does not hear the buzz here anymore. Thus, to mitigate the effect I can monitor the reception quality during call and align myself so that the quality is as high as possible (just going near a window helps a lot). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume keyboard dictionary sorting and normalization
Carsten Haitzler (The Rasterman) wrote: On Tue, 6 Jan 2009 11:49:55 +0100 Olof Sjobergh olo...@gmail.com babbled: Hi, I'm working on a Swedish dictionary and keyboard for Illume, but I'm having some trouble with sorting of utf8 chars in the dictionary. I can't seem to get the sorting right. Looking at the code, Illume sorts the dictionary after first normalizing the strings according to the internal normalization table. Is there any way to reproduce this sorting with the sort command? I've tried with a few different locales (C, en_US.utf8) which all make the unix sort command work differently. But no matter what I try words don't show up correctly. sort -f i think does it... i think... Another issue I found is that the built in normalization table is not very good for typing Swedish text. On a standard Swedish qwerty layout, we have three additional letters (å, ä and ö). These are used very frequently in Swedish and there are many common words that have different meanings if spellt with a, å or ä (for example har, här and hår are all very common words). But in Illume these are all normalized to a. Writing Swedish with a US qwerty layout and then having to select aåä manually after the dictionary lookup is a pain, since many common words will have to be selected from the lookup list each time. Instead, what you want is a Swedish qwerty layout (which is very simple to implement as a .kbd file), and not normalize åäö for the Swedish dictionary lookup. So the normalization table would really need to be configurable, either as a part of the dictionary or the .kbd file. I suppose this problem exists for other languages as well. If I were to work on such a change, what would be the best approach? hmm interesting i was just going of german/french and portuguese on this where i thought i could get away with simple normalisation and a basic qwerty layout - with selecting the matches (Vogel/Vögel for example). making the table part of the dictionary does make a lot of sense of course. the dict format does need to change to make it a lot faster and intl-char friendly. i avoided this at the time as i'd need to efficiently encode a b-tree in the file and be able to mmap () it efficiently and use it. Mapping of cafe to café (French) and Vogel to Vögel (German) is indeed handy, this funcitonality would be handy internationally for most languages. What about mapping Koeln to Köln etcetera? This would be handy for German only. Like the above story is (maybe) specific for Swedish. Perhaps an optional config file can be provided for the dictionaries that need one. Keeping this info outside the dict itself eases sorting of the dict and upgrading dicts. I would keep this optional config surely independent of the .kbd keyboard configs. Raster, the dicts I'm making for Dutch will be a large version (250.000 words) and a small version. Do you have an indication how many words is advisable for the small version? However it would be desirable that each .kbd file can indicate: - predictive mode is not possible, e.g. for numeric keyboards. I don't want it to remember my PIN, credit card number, etcetera. (numeric keyboard, a real one, without the é, ë, ..) - predictive mode is default on, but user can temporarily disable it, e.g. when going into a shell (alpha keyboard) - predictive mode is defaul off, but user can temporarily enable it, e.g. when typing proza inside a shell (terminal keyboard) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume keyboard dictionary sorting and normalization
Pander wrote: ... However it would be desirable that each .kbd file can indicate: - predictive mode is not possible, e.g. for numeric keyboards. I don't want it to remember my PIN, credit card number, etcetera. (numeric keyboard, a real one, without the é, ë, ..) - predictive mode is default on, but user can temporarily disable it, e.g. when going into a shell (alpha keyboard) - predictive mode is defaul off, but user can temporarily enable it, e.g. when typing proza inside a shell (terminal keyboard) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I think the functionality described above is already partly implemented for: - type NUMERIC - type ALPHA - type TERMINAL settings in the .kbd file. But what behaviour is exactly enabled by the above types? Could TERMINAL and NUMERIC by default also be non-predictive? It is not clear for me from http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd.c and http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd_int.c what effect it has on predictive mode. Also There are many more modes available like HEX, PASSWORD etc. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/Illume] Program icons not showing up
Helge Hafting wrote: Michael 'Mickey' Lauer wrote: This always happens when we're starting to stabilize for a release. Last time it was something with a missing mimetypes postinst. Raster, any idea what it can be this time? There is definitely a problem with whatever parses the .desktop files. Try installing a third party app like openmoocow. You get no icon, although the icon file exists. Then, remove openmoocow.desktop and recreate it. Use some other .desktop file as a template, and enter the correct filename, name and icon name. Then you get an icon. a problem with categories will certainly make an icon disappear, but that is not the only way. Enter the options in a different order or omit something else, and it may still fail. I haven't researched _exactly_ what works, so far I have concentrated on making the icons show up when they doesn't. Helge Hafting The problem went away when a new build of e-wm was available i.e. 'e-wm - 0.16.999.050+svnr38352-r0' Which build of e-wm do you have ? Also in previous version of e-wm - *+svnr37988* changing the 'Display Type' from 'Icons - Slider' in 'Illume: Wrench-Launcher' displayed the various icons, very strected that is... - Ingi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Paul Fertser wrote: Hi, Fox Mulder quakem...@gmx.net writes: Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Ok. I downloaded the fso-frameworkd source, copied the patch into it and applied it without any problems. Now do i install the fso-frameworkd with ./setup.py install ? That's distribution-dependent. I'd suggest to apply the patch to the frameworkd you have already installed and change /etc/freesmartphone/oevents/rules.yaml by hand. Or if you want to try to install from source, you probably don't need any patches at all, as you can install a version recent enough (though it's possible that some SHR apps are not ready yet). But i have the problem that on [1] only the 2.6.28 kernel but no modules are online. Where do i get the corresponsing modules for this kernel? Last time i checked there was an older kernel with a modules package but no more. I think it's assumed that everything you need for everyday work is compiled-in. If you want to use some webcams or other unusual devices, just compile a kernel yourself from git, it's not hard. Or ask Andy to provide all the modules ;) I don't think that all modules are compiled in because the current kernel is only 896K in size. And the OM kernels are ~1,7M. I already though about compiling the freerunner kernel myself having a bit knowledge about normal pc linux kernel compilation. But for this i have to set up cross compile what i never did before. So first i have to find a good how-to which describes how i fetch the kernel with git (never used it) and how to cross compile it for my freerunner on my pc. It would be much easier if i got a working kernel and modules. Maybe andy has a bit spare time to update his website. Else i have to jump in the cold water and do this on my own. :/ Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Questions and Answers
On Sat, 03 Jan 2009 02:13:45 +0100 Marco Trevisan (Treviño) m...@3v1n0.net babbled: Let me give everyone a bit more background into the keypad issue. We first saw the Qtopia predictive keypad back in February of 2008, and became extremely exited. This keypad, we believed, had the potential to become better than anything on the market. Yes, it was... We asked Raster to integrate this keypad into Om 2008 and extend it to make it more hacker friendly (i.e., usable from places like the terminal). After two months of more or less silence he showed us his own version, written from scratch. The design was a work in progress. And the dictionary was far inferior to what Qtopia had already. An internal battle started that lasted until one month before Om 2008 was set to be released when our product manager, Will Lai, couldn't take it anymore. He asked another engineer to just get the Qtopia keypad working. Ok, I understand this. But, why have you asked Raster to improve a thing (like qtopia-x11) that should have been only a kind of placeholder? Wasn't it considered in a such way at that time? I always thought that the future of Openmoko was going to reach the Framework, and also if qtopia could be adapted to use it, we all know that its performances under X aren't the ones that we can bear. At that point Raster's keypad was getting stable. It had many new features. But basic text entry was still not as good as Qtopia's. Major parts of Om 2008, in the meantime, were still not finished (like the Glamo or network manager). Openmoko (the company) needs to focus on simplifying. We need to limit ourselves to building what doesn't already exist. We cannot constantly try to build better components from scratch. Our resources are just too limited for that. Openmoko is trying to repackage the essentials (just enough) to make people feel inspired. What's not there is often times more inspiring than what is there. I emailed Raster, the other day, asking if my current perspective corresponds with his. The main motivation for writing a new keypad from scratch, he said, had to do with his ability to (easily) extend Qtopia's code. C++ and qt were not familiar to him. And he wanted something with more configuration options. To get there with Qtopia, he thought, would take more time then writing a new one from scratch. So reading this I only think that what Raster said was not only true about the implementation difficulties, but also about the fact that at that time we needed something that should have survived to Om2008. The keyboard he wrote is actually what the future seems to reserve to us and also if it has some issues with accented words (maybe fixed in svn r38274?!?) and it performs worse with big dictionaries than the Qtopia predictive, I figure that he did the right move. So maybe what happened wasn't in the spirit of the backs to the basics, but he lead us the best input method available today. since what i wrote really got distilled down and lost a lot of details and info - i'll quote myself here on the keyboard issue: ok - here's my take: looked at qtopia keyboard code. it's c++ and qt - not too familiar with qt but readable. looked at code (very much qt/qws centric) and its all integrated into the 1 big qpe process. it has no ability to change layout from config nor anything to support using a terminal. we also will depend on a external app that does phone handling for the most rudimentary of things. while it worked well for english text input ONCe you learnt how to use it (someone told you the tricks) it lacked: ease of discoverability (how do i enter space? how do i type the return key? where are numbers? what happened to ctrl and alt? how do i do backspace? etc.) there were a list of ui issues that i knew would be top of the complaints list - they were already on the top of mine. now figuring the work needed to add all of this and fix it vs. re-implementing - i chose to re-implement given all the above concerns (it only took about 3 weeks for the first cut - i was busy doing all sorts of other things at the same time, not just keyboard). so the work to fix it vs. the code to re-implement with all the other bits done better. i chose the latter as i saw it as a faster way to get to thew right solution. in the end qtopia was meant to be a TEMPORARY solution until FSO was done - and thus there would need to be a new keyboard implemented anyway later so work would be duplicated probably by the same person - me. so instead of doing it twice - did it once. there were enough other unsolved problems at the time - like how do i request a keyboard as an app properly? (the matchbox protocol had holes you can drive a truck through to cause problems so i ended up implementing that for compatibility, but also a newer protocol involving properties). also how to select from one of N installed keyboards and manage the running,
Re: Buzz fix attempt, tomorrow
Hi Oh yes, please take pictures and give feedback to help people understand the process and evaluate its feasibility. Thanks in advance :D 2009/1/6 Yoann ARNAUD yarn...@crans.org Hello Community, Tommorow, I (my colleague, actually) will try to fix the buzz of my OM version A5 according to the manual of Joerg. If any of you have some last minute advice to give me, I take :) I can take pictures and make a report of my experience if you think that's necessary. I don't know so just tell me. Bye. -- Yoann ARNAUD Nantes, France. ___ 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: Openmoko keyboard mockup
Hi Kieran, +1 for your idea : a toggle fullscreen button would be a great improvement. I still consider a transparent keyboard will be a good stuff too. By transparent, I don't mean you can click on the interface under , I mean you can see what you are writting under the keyboard, but cannot have an action on the things under. With you toggle fullscreen button, the transparent keyboard would be an improvement. 2009/1/6 Kieran Fleming kieran.flem...@gmail.com The most interesting thing about this mockup for me is that it doesn't try to make the rest of the UI usable. It reminds me of this keyboard: http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png Where the entire screen is a keyboard. Perhaps a good way to get this idea working would be to have a fullscreen button on the existing keyboard so you can toggle it when you want to. Kieran Fleming ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware buzz - can OpenMoko help?
Hi Timo Thanks for your feedback on monitoring the reception quality. Is it possible to create a script which display the number each 5 seconds, so that we can actually see the evolution of the reception as moving the phone ? I am no coder, so I don't know how to do it. The best would be to display the value fullscreen in big size. Anyone can please code this ? Here is my very small start #!/bin/sh mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 I think a loop must be added... Thanks anyway Kimaidou 2009/1/6 Timo Juhani Lindfors timo.lindf...@iki.fi Christ van Willegen cvwille...@gmail.com writes: The last few days, people have constantly complained about a loud, high-pitched noise when I call them. I presume it's the 'ahrdware buzz' we're talking about here. The buzz seems to be proportional to the transmit power which itself seems to be proportional to the reception quality I can monitor with mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 According to specs these units are # 0-113 dBm or less # 1-111 dBm # 2...30 -109... -53 dBm # 31 -51 dBm or greater # 99 not known or not detectable and when it is around 26 or more the recipient does not hear the buzz here anymore. Thus, to mitigate the effect I can monitor the reception quality during call and align myself so that the quality is as high as possible (just going near a window helps a lot). ___ 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: [Report] - Buzz fix
Greetings, I have been following the developments of OM, and I, too would like to know when I can expect to see GTA02 with buzz fix available commercially. Thanks for any updates, z On Tue, Jan 6, 2009 at 8:35 AM, Xavier Cremaschi omega.xav...@gmail.comwrote: The .pdf says this hardware fix transforms a GTA02v5 with buzz into a GTA02v7-equivalent (without buzz). But is the GTA02v7 currently produced and/or sold ? The wiki seems to stop at GTA02v6 (for which buzz is still a possibility). Xavier. ___ 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: Illume keyboard dictionary sorting and normalization
On Tue, Jan 6, 2009 at 11:57 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: sort -f i think does it... i think... Thanks, that seems to work. I created a package and uploaded to http://www.opkg.org/package_90.html for anyone who is interested. The source is hosted at http://github.com/olofsj/swedish-illume. hmm interesting i was just going of german/french and portuguese on this where i thought i could get away with simple normalisation and a basic qwerty layout - with selecting the matches (Vogel/Vögel for example). making the table part of the dictionary does make a lot of sense of course. the dict format does need to change to make it a lot faster and intl-char friendly. i avoided this at the time as i'd need to efficiently encode a b-tree in the file and be able to mmap () it efficiently and use it. I understand it would make the dictionary format more complicated. Maybe it could be split into 2 files, one with general configuration data such as a normalisation table, an icon etc, and then a raw dictionary file like there is now. Best regards, Olof Sjöbergh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware buzz - can OpenMoko help?
kimaidou kimai...@gmail.com writes: mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 Just make sure this is a complete line and not split to multiple lines as it was in your mail. I think a loop must be added... my ~/bin/loop does #!/bin/sh while true; do $1 sleep 2 done so I can just loop gsm-strength, loop energy, loop temperature or loop consumption. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzz fix attempt, tomorrow
kimaidou a écrit : Tommorow, I (my colleague, actually) will try to fix the buzz of my OM version A5 according to the manual of Joerg. Since I was asked, here is the documentation I will use : http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf -- Yoann ARNAUD Nantes, France. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware buzz - can OpenMoko help?
Hi ! thanks for your help So basically, I need 2 files : * one ~/bin/loop as described in your email : #!/bin/sh while true; do $1 sleep 2 done * And one monitorgsm with only the complete line (not splitted) such as: #!/bin/sh mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 then I can do in the terminal : loop monitorgsm ? 2009/1/6 Timo Juhani Lindfors timo.lindf...@iki.fi kimaidou kimai...@gmail.com writes: mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 Just make sure this is a complete line and not split to multiple lines as it was in your mail. I think a loop must be added... my ~/bin/loop does #!/bin/sh while true; do $1 sleep 2 done so I can just loop gsm-strength, loop energy, loop temperature or loop consumption. ___ 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: Hardware buzz - can OpenMoko help?
Hi I just tested, and it worked like a charm ! Just don't forget to chmod +x the 2 scripts Thanks a lot ! 2009/1/6 kimaidou kimai...@gmail.com Hi ! thanks for your help So basically, I need 2 files : * one ~/bin/loop as described in your email : #!/bin/sh while true; do $1 sleep 2 done * And one monitorgsm with only the complete line (not splitted) such as: #!/bin/sh mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 then I can do in the terminal : loop monitorgsm ? 2009/1/6 Timo Juhani Lindfors timo.lindf...@iki.fi kimaidou kimai...@gmail.com writes: mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n|tr ' '\n'|grep ^\+CSQ:|cut -d, -f1|cut -d' ' -f2 Just make sure this is a complete line and not split to multiple lines as it was in your mail. I think a loop must be added... my ~/bin/loop does #!/bin/sh while true; do $1 sleep 2 done so I can just loop gsm-strength, loop energy, loop temperature or loop consumption. ___ 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
Seeling my Freerunner on Ebay
Hello, I just bought an another phone, so I am selling my Freeruner on ebay. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemssPageName=STRK:MESELX:ITitem=270326829135 Starting bid is 100$, no reserve, free shipping. Phone is like new, it always had a zack invisible shield for the full body and for the screen. Headset have never been used, and it comes with the pouch. (i lost the stylus long time ago). I can provide more picture and more info in request. At the moment, it is loaded with the 2008.12 version of software. Regards Philippe ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzz fix attempt, tomorrow
Yoann ARNAUD wrote: kimaidou a écrit : Tommorow, I (my colleague, actually) will try to fix the buzz of my OM version A5 according to the manual of Joerg. Since I was asked, here is the documentation I will use : http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP_rc2.pdf is the newer version. Don't know what changed but DRAFT3 is the first public version available and rc2 the latest. Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
connect freerunner with debian to a windows-PC
Hi, all, is there anyone who can help me? I've got debian installed on my freerunner and now i try to connect to a windows xp machine. my debian is quite naked, but in general it's the debian built by the official script linked in the wiki, you surely know. The rndis-windows driver has been taken from here: http://users.informatik.uni-halle.de/~rabe/neo/Neo1973.inf connecting the freerunner with om2008.12 installed works just fine, with debian the driver on xp says he could not connect and gives an error-code 10. anyone knows whats up? and: i know i shouldn't use windows and i should take a linux-distribution instead. Well, i would if i could, you know? please help me! thank you very much -- View this message in context: http://n2.nabble.com/connect-freerunner-with-debian-to-a-windows-PC-tp2118647p2118647.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Mediaplayer
Well, FWIW, I have both running on my system concurrently: qtopia for the phone-kit and frameworkd for all the system level stuff. On Tue, Jan 6, 2009 at 4:07 AM, Timo Jyrinki timo.jyri...@gmail.com wrote: 2009/1/6 Dylan Reilly drei...@atariland.net: To tell you the truth, I am not sure. I have always been running the testing distribution, but 2008.12 *should* be more or less the same as testing. No. There were two types of testing image, one using the 2008.12-like qtopia stuff and one using freesmartphone.org. 2008.12 is not using frameworkd, but the qtopia daemons like qpe and qtopia-x11 messaging/dialing/etc. software. 2008.12 does not include the profile switching feature, but like said there are scripts for it. I simply have a python app with a few buttons I can use to switch between profiles for music playback (phone, loudspeakers, headphones). -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo / FreeRunner 'stand'
I'm planning to make an open hardware design for something like this and have it manufactured by a 3D printer. Anyone can have it manufactured at a place like http://www.shapeways.com/ At the moment I'm waiting to get some help to get started, see http://lists.openmoko.org/pipermail/community/2008-December/038598.html Christopher Friedt wrote: Wouldn't it be great to have a moulded plastic stand that would just clip into place on the back of the FreeRunner or Neo1973, so that you could rest it on a table in widescreen mode, and have it sit at a comfortable angle? Maybe it's a good 'extra' to include int the box for GTA03 :) Nokia has had a 'desk stand' on their internet tablets since the N770. In the mean time, I'm sure I can work out something using a small triangular piece of wood, crazy glue, a slice from my girlfriend's yoga mat, and velcro :) C ___ devel mailing list de...@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Strength int to bar conversion
On Monday 05 January 2009 23:07:39 arne anka wrote: not sure if feasible, but what about making it configurable to have either the bar chart or the number itself shown? the number still could be coloured depending on the level (red to green or so, drawing a string in different colours shouldn't be that expensive, shouldn't it?). You could even have a number of 'faded in' versions of each of the four bars to get a higher number different states. solar.george signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
I also am somewhat surprised by the lack of an excellent code-friendly keyboard. I use QWO because it actually has the capability of syntactical symbols and is relatively finger-friendly. Still, sometimes you just can't beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that takes up the entire screen with just a little space at the top to see what you're typing, and once you've finished you can dump the whole mess into whatever textbox is focused. A lot more real-estate that way. It doesn't have to be transparent either. I read most of the explanation of Illume's error-corrective keyboard, and it sounded so great, I went and tried it. However, when everything except Hello was listed when I typed hdllo and hwllo I gave up on it. :( Also, it DESPERATELY needs a reset button to start over on the word, if it's not in the list. -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Fox Mulder wrote: Paul Fertser wrote: Hi, Fox Mulder quakem...@gmx.net writes: Actually, you can try to change from 2.6.24 after applying an ad-hoc patch from http://trac.freesmartphone.org/ticket/293 even on old version that's provided by Debian (that's exactly what i did a month ago). Ok. I downloaded the fso-frameworkd source, copied the patch into it and applied it without any problems. Now do i install the fso-frameworkd with ./setup.py install ? That's distribution-dependent. I'd suggest to apply the patch to the frameworkd you have already installed and change /etc/freesmartphone/oevents/rules.yaml by hand. Or if you want to try to install from source, you probably don't need any patches at all, as you can install a version recent enough (though it's possible that some SHR apps are not ready yet). But i have the problem that on [1] only the 2.6.28 kernel but no modules are online. Where do i get the corresponsing modules for this kernel? Last time i checked there was an older kernel with a modules package but no more. I think it's assumed that everything you need for everyday work is compiled-in. If you want to use some webcams or other unusual devices, just compile a kernel yourself from git, it's not hard. Or ask Andy to provide all the modules ;) I don't think that all modules are compiled in because the current kernel is only 896K in size. And the OM kernels are ~1,7M. I already though about compiling the freerunner kernel myself having a bit knowledge about normal pc linux kernel compilation. But for this i have to set up cross compile what i never did before. So first i have to find a good how-to which describes how i fetch the kernel with git (never used it) and how to cross compile it for my freerunner on my pc. It would be much easier if i got a working kernel and modules. Maybe andy has a bit spare time to update his website. Else i have to jump in the cold water and do this on my own. :/ I installed the om toolchain and compiled the 2.6.28 kernel after some help of [1] and google with ./build dummy. After i compiled the kernel i got dummy/uImage-GTA02.bin what looks quite good so far. But how do i extract the compiled modules from the dummy directory to package them for transfer to the freerunner? On my pc i just would do make modules_install to copy the compiled modules to the right place. And in the subdirectories of the dir dummy are predominantly *.cmd and *.o files but modules normally end with *.ko. So i don't know what to to at this point to get the modules out of it. I hope someone can help me a bit. :) Ciao, Rainer [1] http://wiki.openmoko.org/wiki/Toolchain#Building_Openmoko_Kernel_from_git_repo_using_Toolchain ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
of the explanation of Illume's error-corrective keyboard, and it sounded so great, I went and tried it. However, when everything except Hello was listed when I typed hdllo and hwllo I gave up on it. :( Also, it DESPERATELY needs a reset button to start over on the word, if it's not in the list. actually i tried it now and even with pure h e l l o i got to see Gallo, jello, troop, tempo and was puzzled as you did... then i pressed the ^ icon on the left and learned (again) something new :) try it! Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Jan 06 16:59+0100, kimaidou wrote: Hi Kieran, +1 for your idea : a toggle fullscreen button would be a great improvement. I still consider a transparent keyboard will be a good stuff too. By transparent, I don't mean you can click on the interface under , I mean you can see what you are writting under the keyboard, but cannot have an action on the things under. With you toggle fullscreen button, the transparent keyboard would be an improvement. snip A 'transparent' keyboard would have a high 'coolness' factor, but I think it would be hard to really see what you are typing (not to mention the technical limitations pointed out by rasterman). Maybe it would be better to have a full-screen input mode where you can see what will be typed (maybe keep the rightmost 20-30 characters of the string visible in the keyboard app, then actually pass it to the program when leaving 'full-screen' mode or pressing 'enter', etc). That still allows you to see what you are typing with a full-screen keyboard (which is what it seems most people are wanting from the transparency). Extra points could be awarded for allowing applications to give the keyboard app a description of the 'active' field to be displayed in a 'full-screen' mode. -- Eldon Koyle -- The graveyards are full of indispensable men. -- Charles de Gaulle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Hi, Fox Mulder quakem...@gmx.net writes: I installed the om toolchain and compiled the 2.6.28 kernel after some help of [1] and google with ./build dummy. After i compiled the kernel i got dummy/uImage-GTA02.bin what looks quite good so far. But how do i extract the compiled modules from the dummy directory to package them for transfer to the freerunner? You gave a parameter to the build script, so it should have installed the modules to the staging directory and made a file named modules$VERSION.tar.gz . Just scp it to your FR and untar to / . -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
Maybe it would be better to have a full-screen input mode where you can see what will be typed (maybe keep the rightmost 20-30 characters of the string visible in the keyboard app, then actually pass it to the program when leaving 'full-screen' mode or pressing 'enter', etc). That still allows you to see what you are typing with a full-screen keyboard (which is what it seems most people are wanting from the transparency). I think that would be good, though things like tab-completion have to be considered when inputting to a separate field and dumping the result when finished. From Petr: actually i tried it now and even with pure h e l l o i got to see Gallo, jello, troop, tempo and was puzzled as you did... then i pressed the ^ icon on the left and learned (again) something new :) try it! Unfortunately, that's the list I was referring to. :( I scrolled through the entire list (there were probably 15 words) and Hello was not present. Seeing as the letters I hit wrong were adjacent to the target letter, and I would say Hello is far more common than Gallo, I was really stunned. Nevertheless, as has been pointed out... Keyboards like that are excellent for SMS and whatnot... But when it comes to using a terminal, they are really not very useful. On a slightly other topic, I've noticed the programs in my phone stack (such as creating contacts) are smart about when to have the keyboard up. They automatically bring it up when you visit a page with text inputs. The terminal needs this feature badly, but many other apps could use this little bit of intuitiveness as well. -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Paul Fertser wrote: Hi, Fox Mulder quakem...@gmx.net writes: I installed the om toolchain and compiled the 2.6.28 kernel after some help of [1] and google with ./build dummy. After i compiled the kernel i got dummy/uImage-GTA02.bin what looks quite good so far. But how do i extract the compiled modules from the dummy directory to package them for transfer to the freerunner? You gave a parameter to the build script, so it should have installed the modules to the staging directory and made a file named modules$VERSION.tar.gz . Just scp it to your FR and untar to / . That's what is also described on the wiki page but there is no modules tar.gz file. I searched the whole linux-2.6 directory with all subdirs without luck. I did a ./build dummy again and i see that at some point it shows Building modules, stage 2.. And after that all modules are listed with extension *.ko which is correct. After i took a closer look i can see that within dummy and all these other files are the wanted *.ko files. But it doesn't exist any archive with all of them in it. Now i could search for every *.ko file and extract it out of dummy, but i don't think this is normal. :/ Could it be that i have to issue some command which produces the modules tar.gz file? Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, Jan 06, 2009 at 04:17:06PM +1100, Carsten Haitzler wrote: All of them have nice big buttons and share a simple layout. The FR's screen is big enough even in portrait mode to accommodate a keyboard like this. The Illume keyboard, as excellent as it is (thanks Raster!!), is fiddly to use without a stylus. I would like to not have to use a stylus to compose notes/emails/sms. For terminal use (and using VI) a more complete k/b is of course justified, but for everyday use we need a nice finger keyboard. with dictionary correction the illume keyboard (and the qtopia one) in normal plain qwerty for writing notes and emails and sms's work just great - i've used them walking down the street and i can type better on it than i can on my rokr e6 WITH a stylus. in fact my n800 with a landscape 4.3 screen is almost equivalent in usability (it doesnt dictionary correct). I agree, I used it today to take notes at a meeting. In vi :) Rui -- Keep the Lasagna flying! Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, Jan 06, 2009 at 12:34:28PM +0100, leona...@lilik.it wrote: Hi Raster, thanks for the explanation. anyway. i hope this helps people understand how it works. someone can throw this onto the wiki if they like. this is the code i wrote for the illume kbd I've summarized this in a page: http://wiki.openmoko.org/wiki/Illume_keyboard it's cool, you should really patent it! :-))) Please die a slow and painful death for suggesting that. [1] Rui [1] unless you were really just making a very bad taste joke :) -- Or is it? Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?
Fox Mulder quakem...@gmx.net writes: Could it be that i have to issue some command which produces the modules tar.gz file? Oh, man... If you don't want to read ``build'' then please do it by hand in the root of the build: rm -rf staging mkdir -p staging make ARCH=arm modules_install INSTALL_MOD_PATH=staging cd staging tar czf ../modules-whatever.tar.gz . cd .. And then scp your modules-whatever.tar.gz to FR and untar to /. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 06 Jan 2009 15:14:56 +0100 Mathieu Rochette math...@gmail.com babbled: Laszlo KREKACS wrote: Hi! First and foremost, it is us hackers that use this device for now and are supposed to make apps for freerunner and all, and we don't have a damn keyboard;). All this fancy pancy dictionary based guessing is maybe good for normal people writing crappy SMS messages, but not for the current user base, in my opinion. you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine in illume to allow for straight-through pushing of key presses without a dict int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as opposed to strings. don't like the keys on that .kbd? edit the .kbd file. change it yourself! its just text! Im planning to develop an application, where is a table, and in each column I want different keyboard layout with different dictionary. Is it possible to change layout and dictionary on the fly? (ie. entering in another text input field). The application would be something, in the first column is only numbers, so I want a keyboard with [0..9-.] buttons, and accept only numbers. In the second column I want to write down what I see (microwave, lamp, soldering iron, etc) and in the third column I want to write the trademark of it (sony, samsung, philips, weller, etc) so I want to change the keyboard between numeric and qwerty, and I want to change the dictionary as of input text field. Is it doable? If so where to start? I know python, and would be glad to see some debian/ubuntu guide how to start programming in efl. (or is it a complete development virtualbox/qemu image? it was discussions about some time ago). this is be doable. keyboard application can receive message for client, message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE and message data is one of: - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD (I don't know where this list came from, is there some specification or recommendation for virtual keyboard application implementation?) well ecore_x has a small wrapper for this stuff - but its basically simple x properties and atoms - i just came up with a list of types of input fields i could think of and put them in the list. this can be expanded without problems. so, the application just have to send one of those messages when entering a field or another. it's actually a property on the window - but yes. just asking for a kind of keyboard is what the app can do - then the keyboard need to do whatever it sees fit to honor that request. you cant explicitly select a dictionary though. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume keyboard dictionary sorting and normalization
On Tue, 06 Jan 2009 15:43:35 +0100 Pander pan...@users.sourceforge.net babbled: Carsten Haitzler (The Rasterman) wrote: On Tue, 6 Jan 2009 11:49:55 +0100 Olof Sjobergh olo...@gmail.com babbled: Hi, I'm working on a Swedish dictionary and keyboard for Illume, but I'm having some trouble with sorting of utf8 chars in the dictionary. I can't seem to get the sorting right. Looking at the code, Illume sorts the dictionary after first normalizing the strings according to the internal normalization table. Is there any way to reproduce this sorting with the sort command? I've tried with a few different locales (C, en_US.utf8) which all make the unix sort command work differently. But no matter what I try words don't show up correctly. sort -f i think does it... i think... Another issue I found is that the built in normalization table is not very good for typing Swedish text. On a standard Swedish qwerty layout, we have three additional letters (å, ä and ö). These are used very frequently in Swedish and there are many common words that have different meanings if spellt with a, å or ä (for example har, här and hår are all very common words). But in Illume these are all normalized to a. Writing Swedish with a US qwerty layout and then having to select aåä manually after the dictionary lookup is a pain, since many common words will have to be selected from the lookup list each time. Instead, what you want is a Swedish qwerty layout (which is very simple to implement as a .kbd file), and not normalize åäö for the Swedish dictionary lookup. So the normalization table would really need to be configurable, either as a part of the dictionary or the .kbd file. I suppose this problem exists for other languages as well. If I were to work on such a change, what would be the best approach? hmm interesting i was just going of german/french and portuguese on this where i thought i could get away with simple normalisation and a basic qwerty layout - with selecting the matches (Vogel/Vögel for example). making the table part of the dictionary does make a lot of sense of course. the dict format does need to change to make it a lot faster and intl-char friendly. i avoided this at the time as i'd need to efficiently encode a b-tree in the file and be able to mmap () it efficiently and use it. Mapping of cafe to café (French) and Vogel to Vögel (German) is indeed handy, this funcitonality would be handy internationally for most languages. What about mapping Koeln to Köln etcetera? This would be handy for German only. Like the above story is (maybe) specific for Swedish. yup. i've gone over this before. i think the solution is a dict change. you have a match string and a list of possible outputs: vogel - Vogel,Vögel koln - Köln koeln - Köln etc. etc. - this allows arbitrary mappings from 1 string to any other. should cover a whole HOST of languages (japanese, chines and korean included if using the romanised input methods of these languages). again - whole dict format change would be needed and it'd be much harder to crate dicts. Perhaps an optional config file can be provided for the dictionaries that need one. Keeping this info outside the dict itself eases sorting of the dict and upgrading dicts. I would keep this optional config surely independent of the .kbd keyboard configs. Raster, the dicts I'm making for Dutch will be a large version (250.000 words) and a small version. Do you have an indication how many words is advisable for the small version? you don't really need a small one - the small english one i used 1. because it was simpler to check my match results in a small set of data and it used less ram in my initial in memory only dict code. in the end there likely need a major dict format and data content change to basically support all this stuff. but once done it should cover a whole slew of languages. However it would be desirable that each .kbd file can indicate: - predictive mode is not possible, e.g. for numeric keyboards. I don't want it to remember my PIN, credit card number, etcetera. (numeric keyboard, a real one, without the é, ë, ..) outputting keysyms instead of strings (like Terminal.kbd) bypasses the dict. so this is how it is effectively turned off. - predictive mode is default on, but user can temporarily disable it, e.g. when going into a shell (alpha keyboard) that's what Terminal.kbd is for... ? - predictive mode is defaul off, but user can temporarily enable it, e.g. when typing proza inside a shell (terminal keyboard) of course this can be done - the problem is - where do i conveniently attach all the controls. i guess if no word is composed currently ^ on the top-left can pop up a control panel. but for now - kbd is not on my radar - got other things to do at the moment. :( -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten
Re: Illume keyboard dictionary sorting and normalization
On Tue, 06 Jan 2009 15:58:55 +0100 Pander pan...@users.sourceforge.net babbled: Pander wrote: ... However it would be desirable that each .kbd file can indicate: - predictive mode is not possible, e.g. for numeric keyboards. I don't want it to remember my PIN, credit card number, etcetera. (numeric keyboard, a real one, without the é, ë, ..) - predictive mode is default on, but user can temporarily disable it, e.g. when going into a shell (alpha keyboard) - predictive mode is defaul off, but user can temporarily enable it, e.g. when typing proza inside a shell (terminal keyboard) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I think the functionality described above is already partly implemented for: - type NUMERIC - type ALPHA - type TERMINAL settings in the .kbd file. But what behaviour is exactly enabled by the above types? none. it's a hint. for example if the app requests you're in a numeric input field - as the keyboard for a numeric mode for the keyboard code to switch layouts to that layout. it's to hook with the hints from apps. Could TERMINAL and NUMERIC by default also be non-predictive? they are both non predictive. remember the kbd only puts strings through the dict - keysyms (raw key names) it doesn't. It is not clear for me from http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd.c and http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd_int.c what effect it has on predictive mode. Also There are many more modes available like HEX, PASSWORD etc. dictionary use is implied by how the key outputs a char. i.ie using ! instead of exclam (for exlamation mark) puts ! thru the dict, but exclam goes straight to the app - no dict involved. thats whhy terminal.kbd doesnt go through the dictionary prediction at all - as no keys there output a string. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Tue, 6 Jan 2009 13:28:44 -0600 The Digital Pioneer digitalpion...@gmail.com babbled: I also am somewhat surprised by the lack of an excellent code-friendly keyboard. I use QWO because it actually has the capability of syntactical symbols and is relatively finger-friendly. Still, sometimes you just can't beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that takes up the entire screen with just a little space at the top to see what you're typing, and once you've finished you can dump the whole mess into whatever textbox is focused. A lot more real-estate that way. It doesn't have to be transparent either. I read most of the explanation of Illume's error-corrective keyboard, and it sounded so great, I went and tried it. However, when everything except Hello was listed when I typed hdllo and hwllo I gave up on it. :( Also, it DESPERATELY needs a reset button to start over on the word, if it's not in the list. yeah - deleting 1 char at a time is nasty. and yes. it seems not to find hello in the dic - i suspect a bug or 2 in dict matching and stopping a search too early. again loop around back to need a better dic format :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume keyboard dictionary sorting and normalization
On Tue, 6 Jan 2009 17:28:30 +0100 Olof Sjobergh olo...@gmail.com babbled: On Tue, Jan 6, 2009 at 11:57 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: sort -f i think does it... i think... Thanks, that seems to work. I created a package and uploaded to http://www.opkg.org/package_90.html for anyone who is interested. The source is hosted at http://github.com/olofsj/swedish-illume. hmm interesting i was just going of german/french and portuguese on this where i thought i could get away with simple normalisation and a basic qwerty layout - with selecting the matches (Vogel/Vögel for example). making the table part of the dictionary does make a lot of sense of course. the dict format does need to change to make it a lot faster and intl-char friendly. i avoided this at the time as i'd need to efficiently encode a b-tree in the file and be able to mmap () it efficiently and use it. I understand it would make the dictionary format more complicated. Maybe it could be split into 2 files, one with general configuration data such as a normalisation table, an icon etc, and then a raw dictionary file like there is now. it could be - but there needs to be a redo of the dict format. i need to at least add the following: 1. actual match sting and display string should be different. i.e.: (german) vogel - Vogel,Vögel (japanese) sakana - さかな,サカナ,魚,肴,茶菓な yes japanese is a silly example as there is no way to type matches in kanji (chinese chars) - you NEED an input method (this is where vkbd and xim etc. need to tie in eventually). 2. something much faster to just mmap() and use dynamically. it currently is mmaped with a small lookup table built for faster access - but it still need to parse whole lines on the fly to do matching currently even tho it's mmaped. so if the format changes - then it doesn't matter much. so the above ability to map 1 input match to multiple possible outputs (that could even be radically different) would negate the need for a mapping table :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
this is be doable. keyboard application can receive message for client, message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE and message data is one of: Is it also possible to change the dictionary on the fly too? (if I understand correctly, you are changing the layout ofthe keyboard) Thank you for the pointer, I will digg it more! Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: connect freerunner with debian to a windows-PC
This isn't going to help you but... The windows driver seems dodgy. The 5th of december Android image made windows bluescreen when you plugged the FR into a machine with the driver installed. Linux is your friend, though of course that's not always possible. -- View this message in context: http://n2.nabble.com/connect-freerunner-with-debian-to-a-windows-PC-tp2118647p2120195.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko keyboard mockup
On Wed, 7 Jan 2009 00:33:41 +0100 Laszlo KREKACS laszlo.krekacs.l...@gmail.com babbled: this is be doable. keyboard application can receive message for client, message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE and message data is one of: Is it also possible to change the dictionary on the fly too? (if I understand correctly, you are changing the layout ofthe keyboard) Thank you for the pointer, I will digg it more! no - dict isnt changeable - not by app. as such i havent addressed this beyond kind of input that doesnt specifically require a layout or dict to be used - but hints on input. it's up to the keyboard to do what it thinks it best there. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
stupid networking question
I have an eeepcwifi'd into the Net, running ubuntu,but when i plug the openmoko into one of its usb ports it goes into wifi reconnection. halp! -- ha...@jonesnose.com Harry L Lee (via gmail) chief cook and bottle washer http://jonesnose.com mailto:ha...@jonesnose.com 207-384-8030 (email preferred) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Dying battery
OK, I just don't get how this can be... Why is it that I can have my phone in my pocket all day, I don't touch it, and when I check it, it has 3/4 of the battery monitor still; and then an hour later it's dead? Can someone explain this to me please? It's completely illogical to me. -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: stupid networking question
On Tue, 6 Jan 2009 20:09:14 -0500, Harry L. Lee ha...@jonesnose.com wrote: I have an eeepcwifi'd into the Net, running ubuntu,but when i plug the openmoko into one of its usb ports it goes into wifi reconnection. halp! -- ha...@jonesnose.com What Ubuntu version and flavor? Network Manager has issues under 8.10/Intrepid - I've only had reliable networking (with multiple interfaces) when I disabled NM and wrote manual config. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware buzz - can OpenMoko help?
On 2009.01.06.18.30, Timo Juhani Lindfors wrote: | my ~/bin/loop does | | #!/bin/sh | while true; do | $1 | sleep 2 | done | | so I can just loop gsm-strength, loop energy, loop | temperature or loop consumption. You could also check out the 'watch' command. --Brock ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dying battery
On 2009.01.06.19.31, The Digital Pioneer wrote: | OK, I just don't get how this can be... Why is it that I can have my phone | in my pocket all day, I don't touch it, and when I check it, it has 3/4 of | the battery monitor still; and then an hour later it's dead? Can someone | explain this to me please? It's completely illogical to me. Perhaps this is the Bouncing Calypso bug, in which the GSM registers and unregisters a whole lotta times. http://docs.openmoko.org/trac/ticket/1024 It appears that most or all distributions have a work-around? You didn't mention what flavor you're running... --Brock ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: connect freerunner with debian to a windows-PC
Gothnet wrote: This isn't going to help you but... The windows driver seems dodgy. The 5th of december Android image made windows bluescreen when you plugged the FR into a machine with the driver installed. Linux is your friend, though of course that's not always possible. Everything is possible with LiveCD/LiveUSB Stick :D ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
is there an effort to port ubuntu to openmoko?
-- ha...@jonesnose.com Harry L Lee (via gmail) chief cook and bottle washer http://jonesnose.com mailto:ha...@jonesnose.com 207-384-8030 (email preferred) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware buzz - can OpenMoko help?
Brock awwa...@thelackthereof.org writes: You could also check out the 'watch' command. It only shows the latest number, I want to see the trend with as much history as possible. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: connect freerunner with debian to a windows-PC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gothnet schrieb: This isn't going to help you but... The windows driver seems dodgy. The 5th of december Android image made windows bluescreen when you plugged the FR into a machine with the driver installed. Linux is your friend, though of course that's not always possible. I don't know what your problem is. I conected my fr often to my Windows XP and never had problems. I tried 2007.X, 2008.X and Qt Extended. Greetings Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJZDvPlYiDScJJ+7QRAupGAJ9N98wl3JMQF/1Tj47XdUQnzUdb4QCePexM Etduiuh03u01aCpxgQeRaKk= =YG52 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: connect freerunner with debian to a windows-PC
Bastian Muck schrieb: Gothnet schrieb: This isn't going to help you but... The windows driver seems dodgy. The 5th of december Android image made windows bluescreen when you plugged the FR into a machine with the driver installed. Linux is your friend, though of course that's not always possible. I don't know what your problem is. I conected my fr often to my Windows XP and never had problems. I tried 2007.X, 2008.X and Qt Extended. Greetings Bastian But is there anyone who tried it with debian? ___ 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
