Re: secure encrypted phoning..
> Moin, > > Am Sat, 24 Mar 2007 19:44:36 +0100 schrieb Edwin Lock: > >> Maybe a bit OT, but: >> Is there a way to implement the kind of encryption that the >> cryptophones( http://www.cryptophone.de/) use? > > In principle, yes. See the cryptophone.de FAQ: > [...] > | We will use all legal means to ensure that no one tries to compete > | with us on the base of our published source. You are perfectly free > | to develop a compatible product on the base of the published > | CryptoPhone protocol, but not using our source. > -- http://www.cryptophone.de/qa/published_source/index.html Hi Henryk, I assume You have ported Your software to linux (and also to OpenMoko), so everybody can buy that in a near future? cu math ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem compiling openmoko with MokoMakefile
Gary Oliver wrote: I've been trying to get the openmoko build (using the super Makefile) to go for the last few days without complete success. I believe I've followed the instructions with respect to the system requirements, and the build DOES get through about 12 hours of work (about 400meg has been downloaded and the build directory contains about 5 Gb before failing, so it seems to be quite well along. The failure comes at: NOTE: package gtk+-directfb-2.10.9-r0: task do_fetch: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: started NOTE: Unpacking /home/go/Projects/openmoko/sources/gtk+-2.10.9.tar.bz2 to /home/go/Projects/openmoko/build/tmp/work/armv4t-linux/gtk+-directfb-2.10.9-r0/ NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started NOTE: Applying patch 'no-xwc.patch' ERROR: Error in executing: /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/home/go/Projects/openmoko/openembedded/packages/gtk+/files/./no-xwc.patch' Which appears to be a failure to apply a patchfile "no-xwc.patch" which doesn't seem to be part of the source tree at this point. The "files" directory contains only "migration.patch". Has anyone else seen this, and if so, what bit of detail in the instructions did I fail to notice that's causing this? FYI I have tried building from complete scratch a number of times (blowing away everything except the Makefile) in hopes that I'd simply polluted my local tree somehow. Didn't fix it. A quick google for this file netted me several different variations, so am not quite sure what "no-xwc" patches are required for OE/OpenMoko. Am running a fairly stock Debian "testing" system on an 32 bit AMD platform. No apparent shortage of disk space. Thanks for any help, Gary ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I had the same problem today. Rod W. let me know that there's now a fix in place for it. a make update brought in the changes and the subsequent build completed ok. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
Clare Johnstone writes: >Yes, that is the whole problem. This would be an item in constant and >casual use in the home, with no special precautions as might be used >for knives, hot stoves or poisons, and bound to cause a curious child >to experiment with it. >clare The whole problem is that while there is some remote possibility of injury, it isn't dangerous enough to be concerned about? "Might be used?" The kitchen knives have always been right out on the counter available for use. There are no locks on the knobs on the gas stove. The kids had bicycles, and got driver's licenses, right on schedule. I've got a challenge for you: how many documented cases of eye damage from laser pointers have there ever been? How does that number compare with deaths from choking on food in the period since laser pointers were invented? Seriously, you're worried about a complete non-issue. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
Yes, that is the whole problem. This would be an item in constant and casual use in the home, with no special precautions as might be used for knives, hot stoves or poisons, and bound to cause a curious child to experiment with it. clare On 3/25/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote: Clare Johnstone writes: >Dear all, >This frightens me in my role as mother, grandmother etc, i.e. a >representative of the public to which you hope to sell this phone. >Essentially any laser device powerful enough to be useful has no place in >a home which may ever have children in it. (Even quite old ones). While a laser pointer can conceivably do damage, it's nowhere near as dangerous as a steak knife or even a ballpoint pen, and is in nothing like the same league as a bicycle. ___ 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: No stylus on V1 release?
Clare Johnstone writes: >Dear all, >This frightens me in my role as mother, grandmother etc, i.e. a >representative of the public to which you hope to sell this phone. >Essentially any laser device powerful enough to be useful has no place in >a home which may ever have children in it. (Even quite old ones). While a laser pointer can conceivably do damage, it's nowhere near as dangerous as a steak knife or even a ballpoint pen, and is in nothing like the same league as a bicycle. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko - SoC--- is there a mentor?
Karsten, i agree with you about the layout of the chars ( on my example they was put aleatory )! but at this point I'm just introducing another concept of a finger based keyboard. I'm not able to know whats the better place for each char optimized for English, Germany or even to Portuguese (my native language, I'm Brazilian...). For this use cases I'll try to implement some way to easy develop/change the layout of keys (like i said at bottom of my page). Anyone could make their own layout optimized for his language, share with community then you download to your phone, when you need it probably you press some predefined key on this keyboard, select what layout you want and dynamically change to it. This concept is already presents in phones, like when you change the input method to letters, number, symbols, t9... what do you think? Guy PS:don't worry I'm still encouraged to submit it to SoC : ) 2007/3/24, Karsten Ensinger <[EMAIL PROTECTED]>: Hi Guy, following your explanation, I will get "c", "z", "g" and "q" as characters when tapping on "1", dragging to "3" and dragging back to "1". When I want to have "c", "g" and "q", I have to tap on "1", drag to "2", lift the finger, tap on "3" and drag to "1". If I want to have "c", "g" and "c", I have to tap on "1", drag to "2", lift the finger, tap on "3", drag to "2", lift the finger, tap on "1" and drag to "2". Depending on the needed character sequence, your "new" concept can result in the same amount of taps and drags as the original "finger splash" concept. So everthing depends on the intelligent placement of the characters on the keyboard layout. Let's come to the usability aspects. If I look at the "finger splash", the tapping on "1" will result in a button overlay which will hide the complete "2" at least (maybe also some parts of "3", depending on size). So there is no way for the user to see what is on the right side of the "2" button. This leads to a drag into the blind to get the "z". This seems to me as not user friendly enough to get accepted widely. One has to remember the whole keyboard layout in mind while typing. This would lead to the idea to NOT enlarge the buttons when one taps them. The user would be able to see what he gets, when dragging to the next button. Unfortunately the size of the buttons can't get big enough to hold characters with an easy readable fontsize due to limited physical screen size. This seems to be a dilemma. Making the buttons bigger means less buttons per row and column, means less benefit from the "dragging feature". Maybe the KISS pattern matches here (KISS = Keep It Small and Simple). Although the ability to type more than one letter with a single stroke has charming aspects, the learning curve of the keyboard usage should be as steep as possible and to me, the current concept seems to be to much in need of an explanation. What I have only shortly mentioned before, is the fact that you have to analyse the inherent syllables of the language the user will use. You have to place the characters in a way, that one can type as much words with one or two strokes as possible. So the keyboard layout will vary from language to language. What about users using two different languages at the same time? They will have to pay the price for this. One language will fit perfectly to the keyboard while the other will not (most of the times). I myself will definitely use german and english at the same time every day, and I think most of the non-english natives will do the same. German and english do not have a lot of syllables in common when counting the frequency with which they appear in day to day communications vocabulary. But whatever I comment here, it's my personal and therefore biased opinion. I do NOT want to discourage you to start your own implementation, because an old man think he found a fly in the ointment. Take my comments as food for thoughts and nothing else. Regards Karsten --- gsilva.85 wrote: > Karsten, > > you are right except for one thing on my idea: you are considering only > a row and only a drag from left to right (or right to left..) in this > case only 2 characters will be draw. But think if you press the '1' drag > to '3' and drag again to '1' we got one press with four characters at > output but on finger splash to produce 4 characters (in the better case) > we have to press 4 times. And you can drag not only to left or right but > up, down... > did you understood? > > I thought to adapt this to fingers splash: when the 'splash' appear if > you continue dragging over the buttons of the splash it possible > continues writing that chars (like the speed script concept) but even > with this we stay limited to only 7 different chars in a drag... > > please fell free to comment... > > > thanks > Guy > > [...] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No stylus on V1 release?
Dear all, This frightens me in my role as mother, grandmother etc, i.e. a representative of the public to which you hope to sell this phone. Essentially any laser device powerful enough to be useful has no place in a home which may ever have children in it. (Even quite old ones). clare On 2/16/07, Ian Stirling <[EMAIL PROTECTED]> wrote: denis wrote: > Ian Stirling schrieb: >> Stefan Schmidt wrote: >>> It has a stylus, but no place in the case to hide it. >>> >> >> My thoughts on this: http://wiki.openmoko.org/wiki/Expansion_Back - a >> modified case. Should we add that page to the hardware wish list? and someone did, thus: http://wiki.openmoko.org/wiki/Wish_List_-_Hardware#Laser_Pointer ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: secure encrypted phoning..
Moin, Am Sat, 24 Mar 2007 19:44:36 +0100 schrieb Edwin Lock: > Maybe a bit OT, but: > Is there a way to implement the kind of encryption that the > cryptophones( http://www.cryptophone.de/) use? In principle, yes. See the cryptophone.de FAQ: | The nice thing about our product is that we have no (trade) secrets, | and invite everyone to make interoperable products based on the | published protocol. We believe in standards that are open for anybody | to join - as long as they go and implement their own product and do | not steal from our published source. [...] | We will use all legal means to ensure that no one tries to compete | with us on the base of our published source. You are perfectly free | to develop a compatible product on the base of the published | CryptoPhone protocol, but not using our source. -- http://www.cryptophone.de/qa/published_source/index.html -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: secure encrypted phoning..
la, 2007-03-24 kello 19:44 +0100, Edwin Lock kirjoitti: > Maybe a bit OT, but: > Is there a way to implement the kind of encryption that the > cryptophones(http://www.cryptophone.de/) use? It's not off-topic, but it has been discussed before, so I refer you to the February archives¹, subjects "Voice over GPRS?" and "Encrypting voice communications". Summary: Possible to code support for this using GSM data calls, which come with the quality of service GPRS lacks. May cost a bit extra depending on your provider. Compatibility with cryptophone perhaps possible if their source is up for review, though not necessarily (haven't checked if they eg. want cryptophone.de's signatures on both ends). Either way, at least Moko-to-Moko encrypted calls are quite possible to implement, just that somebody (TM) needs to do the work. ¹ http://lists.openmoko.org/pipermail/community/2007-February/thread.html -- Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> Transhumanist - WTA member - http://www.transhumanism.org/> Singularitarian - SIAI supporter - http://www.singinst.org/> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Master Studies in "Embedded systems" starts in Pforzheim/Germany
Robert Michel schrieb: > Salve! > > Seems that this master courses are not given in > English: > http://www.heise.de/newsticker/meldung/87322 > http://es.hs-pforzheim.de/menue/frame_ma_es.htm > > Is here someone on the list with good contacts > to the hs-pforzheim? > Do you have ideas how to make OpenMoko populare > there? Hi everybody! I am just finishing the Bacchelor grade in HSSE (Hardware/Software Systems Engineering) in Hagenberg in Austria. Here at the university we have the master following to HSSE called Embedded Systems Design. In addition we also have a branch of study called Mobile Computing. I think it would be great if we could make OpenMoko popular there... I just don't know how to do this other than ordering my Neo and showing it to other people and hoping that the word of mouth will spread the information. This is just what I will do. Greetings, Wolfgang. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko - SoC--- is there a mentor?
Hi Guy, following your explanation, I will get "c", "z", "g" and "q" as characters when tapping on "1", dragging to "3" and dragging back to "1". When I want to have "c", "g" and "q", I have to tap on "1", drag to "2", lift the finger, tap on "3" and drag to "1". If I want to have "c", "g" and "c", I have to tap on "1", drag to "2", lift the finger, tap on "3", drag to "2", lift the finger, tap on "1" and drag to "2". Depending on the needed character sequence, your "new" concept can result in the same amount of taps and drags as the original "finger splash" concept. So everthing depends on the intelligent placement of the characters on the keyboard layout. Let's come to the usability aspects. If I look at the "finger splash", the tapping on "1" will result in a button overlay which will hide the complete "2" at least (maybe also some parts of "3", depending on size). So there is no way for the user to see what is on the right side of the "2" button. This leads to a drag into the blind to get the "z". This seems to me as not user friendly enough to get accepted widely. One has to remember the whole keyboard layout in mind while typing. This would lead to the idea to NOT enlarge the buttons when one taps them. The user would be able to see what he gets, when dragging to the next button. Unfortunately the size of the buttons can't get big enough to hold characters with an easy readable fontsize due to limited physical screen size. This seems to be a dilemma. Making the buttons bigger means less buttons per row and column, means less benefit from the "dragging feature". Maybe the KISS pattern matches here (KISS = Keep It Small and Simple). Although the ability to type more than one letter with a single stroke has charming aspects, the learning curve of the keyboard usage should be as steep as possible and to me, the current concept seems to be to much in need of an explanation. What I have only shortly mentioned before, is the fact that you have to analyse the inherent syllables of the language the user will use. You have to place the characters in a way, that one can type as much words with one or two strokes as possible. So the keyboard layout will vary from language to language. What about users using two different languages at the same time? They will have to pay the price for this. One language will fit perfectly to the keyboard while the other will not (most of the times). I myself will definitely use german and english at the same time every day, and I think most of the non-english natives will do the same. German and english do not have a lot of syllables in common when counting the frequency with which they appear in day to day communications vocabulary. But whatever I comment here, it's my personal and therefore biased opinion. I do NOT want to discourage you to start your own implementation, because an old man think he found a fly in the ointment. Take my comments as food for thoughts and nothing else. Regards Karsten --- gsilva.85 wrote: Karsten, you are right except for one thing on my idea: you are considering only a row and only a drag from left to right (or right to left..) in this case only 2 characters will be draw. But think if you press the '1' drag to '3' and drag again to '1' we got one press with four characters at output but on finger splash to produce 4 characters (in the better case) we have to press 4 times. And you can drag not only to left or right but up, down... did you understood? I thought to adapt this to fingers splash: when the 'splash' appear if you continue dragging over the buttons of the splash it possible continues writing that chars (like the speed script concept) but even with this we stay limited to only 7 different chars in a drag... please fell free to comment... thanks Guy > [...] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem compiling openmoko with MokoMakefile
Gary Oliver: I've been trying to get the openmoko build (using the super Makefile) to go for the last few days without complete success. I believe I've followed the instructions with respect to the system requirements, and the build DOES get through about 12 hours of work (about 400meg has been downloaded and the build directory contains about 5 Gb before failing, so it seems to be quite well along. The failure comes at: NOTE: package gtk+-directfb-2.10.9-r0: task do_fetch: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: started NOTE: Unpacking /home/go/Projects/openmoko/sources/gtk+-2.10.9.tar.bz2 to /home/go/Projects/openmoko/build/tmp/work/armv4t-linux/gtk+-directfb-2.10.9-r0/ NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started NOTE: Applying patch 'no-xwc.patch' ERROR: Error in executing: /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/home/go/Projects/openmoko/openembedded/packages/gtk+/files/./no-xwc.patch' I did a /home/moko$ find . -name no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.10.3/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.6.10/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.10.6/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.4.13/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.8.16/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.2.4/no-xwc.patch ./openmoko/branches/oe/pre-20070305/packages/gtk+/gtk+-2.8.9/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.2.4/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.4.13/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.6.10/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.8.9/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.8.16/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.10.9/no-xwc.patch ./openembedded/packages/gtk+/gtk+-2.10.10/no-xwc.patch I decided to copy all patches from ...gtk+-2.10.9/ (because of "18:46:56 (97.93 KB/s) - »/home/moko/sources/gtk+-2.10.9.tar.bz2« saved [1490]" ... ) /home/moko$ cp ./openembedded/packages/gtk+/gtk+-2.10.9/* /home/moko/openembedded/packages/gtk+/files/./ The result is, that all patches appling: NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started NOTE: Applying patch 'no-xwc.patch' NOTE: Applying patch 'automake-lossage.patch' NOTE: Applying patch 'disable-tooltips.patch' NOTE: Applying patch 'gtklabel-resize-patch' NOTE: Applying patch 'menu-deactivate.patch' NOTE: Applying patch 'xsettings.patch' NOTE: Applying patch 'scroll-timings.patch' NOTE: Applying patch 'small-gtkfilesel.patch' NOTE: Applying patch 'migration.patch' NOTE: Applying patch 'run-iconcache.patch' NOTE: Applying patch 'hardcoded_libtool.patch' NOTE: Applying patch 'no-demos.patch' NOTE: Applying patch 'single-click.patch' NOTE: Applying patch 'spinbutton.patch' NOTE: Applying patch 'gtk+-handhelds.patch' But only the last one failed (known: `less /home/moko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb`) NOTE: Applying patch 'directfb_pixbuf_deprecated_fix.patch' ERROR: Error in executing: /home/moko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb I did not find the "directfb_pixbuf...", neither by a locale "find" nor by a "google find" and also not with "google openmoko find" :-( I also checked the tarball "gtk+-2.10.9.tar.bz2" (there's no other "gtk" inside of /home/moko/sources). The error is reproduceable... I did a `rm -rf sources build openmoko` `mtn update` (mtn was complaining about a missing file (mtpaint-??) ) `make update makefile` `make setup` `make openmoko-devel-image` rgd /homyx ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
secure encrypted phoning..
Maybe a bit OT, but: Is there a way to implement the kind of encryption that the cryptophones( http://www.cryptophone.de/) use? Would be very interesting as more customers could be caught that way.. And secondly it would be very cool to say that you can telephone completely secretly :) The source is supposed to be open...( http://www.heise.de/newsticker/meldung/42155) Greetings, Edwin Lock ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI long term development perspective: physics engine
I'll add here sotg from an off-list msg; In fact we have the position given by the touchscreen : [ x(t) ; y(t) ] speed is: [ (x(t') - x(t)) / (t' -t) ; (y(t') - y(t)) / (t' -t) ] - friction_factor*(t' - t) ... Where the friction_factor is in [0 ; 1] If we want acceleration, then we have to integrate the equation once. Shit, i gotta look into my college courses, it's terrible how fast it fades away :-p I'm not sure we really need to take acceleration into account. The changes to bring to the standard gtk scrolling are: - consider the list as scrollable (not just the scroll item) - change the scrolling "stop" behaviour (when the user stops touching the screen) like this: if (last_cursor_speed > 0), continue_scrolling(last_cursor_speed) - when touching the moving list again, stop the scrolling immediately - addition of friction may be a plus, for a more "wheel-of-fortune"-like experience ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko - SoC--- is there a mentor?
Karsten said: Unfortunately the thumb is the one of your fingers which has the biggest fingertip. This limits the number of "action areas" ... some "special sized" thumbs (means: big hands). Hi Karsten et al, Thumbs and fingers... I've never programmed with a touch screen, but I'm interested in trying my hand (ha). How accurate is a finger on the Neo touch screen? Does the sensor average the pressure to a single point or register a many points over a wide area? Could a drawing program reasonably use finger input? Would the screen be quickly filled with a mess of big fat lines or could one do some descent sketches with an index finger? What is the smallest distinguishable 'A', 'L', and smiley face? Alex -- 亚 | [EMAIL PROTECTED] 历 | http://genaud.net 山 | GPS: [ 55.67N 12.588E ] 大 | PGP: CCC7 D19D D107 F079 2F3D BF97 8443 DB5A 6DB8 9CE1 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko - SoC--- is there a mentor?
Karsten, you are right except for one thing on my idea: you are considering only a row and only a drag from left to right (or right to left..) in this case only 2 characters will be draw. But think if you press the '1' drag to '3' and drag again to '1' we got one press with four characters at output but on finger splash to produce 4 characters (in the better case) we have to press 4 times. And you can drag not only to left or right but up, down... did you understood? I thought to adapt this to fingers splash: when the 'splash' appear if you continue dragging over the buttons of the splash it possible continues writing that chars (like the speed script concept) but even with this we stay limited to only 7 different chars in a drag... please fell free to comment... thanks Guy 2007/3/24, Karsten Ensinger <[EMAIL PROTECTED]>: Hi Guy, first of all, please do NOT feel offended when I criticise some aspects of your idea. I am definitely prejudiced due to my addiction to the "finger splash" idea on the openmoko-wiki. The decisive difference between the "finger splash" idea and your idea seems to be the fact, that one can input several characters by a single stroke. Due to the restricted place we have on screen and the fact that we want to be able to use the input with a single finger, the number of "action areas" is limited to three of four in a row. If you take an arbitrary mobile phone in your preferred hand and try to use the keyboard (it doesn't matter if it is a "real" keyboard or a touch screen), you will use your thumb for typing normally. Unfortunately the thumb is the one of your fingers which has the biggest fingertip. This limits the number of "action areas" to less than four, if you take into account that a lot of people use their hands for work and therefore have some "special sized" thumbs (means: big hands). Your solution should fit for the majority of users and not only for people with hands sized like children. With three "action areas" in a row, the number of characters reachable by your idea will be just two. This two characters, to me, seem not to be a viable advantage over the "finger splash" idea nor legitimate the more complicated usage (one has to meet the correct boundaries to prevent typing more characters than wanted). Maybe you should adapt the complete "finger splash" idea as is and try to find a mentor for that. The original author of the "finger splash" mentioned that he will not be able to start with implementing his idea very soon and encouraged others to start with it. Why not you? Regards Karsten ---gsilva.85 wrote: > like someone said i wrote something about my ideia and put on wiki... > > http://www.inf.ufsc.br/~guy/text_input.html > > what do you think? > > forgive me if you found some erros in english because i don't speak it > very well... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Master Studies in "Embedded systems" starts in Pforzheim/Germany
Salve! Seems that this master courses are not given in English: http://www.heise.de/newsticker/meldung/87322 http://es.hs-pforzheim.de/menue/frame_ma_es.htm Is here someone on the list with good contacts to the hs-pforzheim? Do you have ideas how to make OpenMoko populare there? rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem compiling openmoko with MokoMakefile
Hi, On Sat, 2007-03-24 at 00:54 -0700, Gary Oliver wrote: > I've been trying to get the openmoko build (using the super Makefile) > to go for the last few days without complete success. > > I believe I've followed the instructions with respect to the system > requirements, and the build DOES get through about 12 hours of work > (about 400meg has been downloaded and the build directory contains > about 5 Gb before failing, so it seems to be quite well along. > > The failure comes at: > > NOTE: package gtk+-directfb-2.10.9-r0: task do_fetch: completed > NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: started > NOTE: Unpacking /home/go/Projects/openmoko/sources/gtk+-2.10.9.tar.bz2 > to > /home/go/Projects/openmoko/build/tmp/work/armv4t-linux/gtk+-directfb-2.10.9-r0/ > NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: completed > NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started > NOTE: Applying patch 'no-xwc.patch' > ERROR: Error in executing: > /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb > ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or > directory: > '/home/go/Projects/openmoko/openembedded/packages/gtk+/files/./no-xwc.patch' > > > Which appears to be a failure to apply a patchfile "no-xwc.patch" which > doesn't seem to be part of the source tree at this point. The "files" > directory contains only "migration.patch". > > Has anyone else seen this, and if so, what bit of detail in the instructions > did I fail to notice that's causing this? Well it seems that OE takes the wrong preferred provider for gtk. One easy and dirty hack is removing the /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk +-directfb_2.10.9.bb file. However it makes monotone complain on update. I do not know if it hurts the monotone update. However there must be a better solution I do not know about. Cheers, Philippe ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Problem compiling openmoko with MokoMakefile
I've been trying to get the openmoko build (using the super Makefile) to go for the last few days without complete success. I believe I've followed the instructions with respect to the system requirements, and the build DOES get through about 12 hours of work (about 400meg has been downloaded and the build directory contains about 5 Gb before failing, so it seems to be quite well along. The failure comes at: NOTE: package gtk+-directfb-2.10.9-r0: task do_fetch: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: started NOTE: Unpacking /home/go/Projects/openmoko/sources/gtk+-2.10.9.tar.bz2 to /home/go/Projects/openmoko/build/tmp/work/armv4t-linux/gtk+-directfb-2.10.9-r0/ NOTE: package gtk+-directfb-2.10.9-r0: task do_unpack: completed NOTE: package gtk+-directfb-2.10.9-r0: task do_patch: started NOTE: Applying patch 'no-xwc.patch' ERROR: Error in executing: /home/go/Projects/openmoko/openembedded/packages/gtk+/gtk+-directfb_2.10.9.bb ERROR: Exception:exceptions.IOError Message:[Errno 2] No such file or directory: '/home/go/Projects/openmoko/openembedded/packages/gtk+/files/./no-xwc.patch' Which appears to be a failure to apply a patchfile "no-xwc.patch" which doesn't seem to be part of the source tree at this point. The "files" directory contains only "migration.patch". Has anyone else seen this, and if so, what bit of detail in the instructions did I fail to notice that's causing this? FYI I have tried building from complete scratch a number of times (blowing away everything except the Makefile) in hopes that I'd simply polluted my local tree somehow. Didn't fix it. A quick google for this file netted me several different variations, so am not quite sure what "no-xwc" patches are required for OE/OpenMoko. Am running a fairly stock Debian "testing" system on an 32 bit AMD platform. No apparent shortage of disk space. Thanks for any help, Gary ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
