Re: New To the list
Ben Wilson skrev: That's for the developer version of GTA02, not the public release What I understand it is the public release hardware, but it will be sold to developers until the software is ready for prime time. After that they hopefully succeed in making a 850Mhz version and then start design next killer handset (quad band? 3G? GB of storage? usb2? cant wait to know about it!). /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT:administrivia -- a request to reduce duplicate mails
Joshua Layne skrev: 'trivial' might be a tad strong here :) I, for example, have no idea how to do this with exim4 - I have no doubt it is possible though. I'll see what my brain extender (aka google) turns up. It is trivial for the software... that does not necessarily make it trivial to get any given software to do it :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: A problem with usb networking
[EMAIL PROTECTED] skrev: Nothing, same problem... :( I also tryied to change the configuration of my network: from 192.168.1.x to 192.168.0.x as yours. But nothing... I think the problem is in ubuntu... I'm on ubunto to. In my /etc/network/interfaces i added: auto usb0 iface usb0 inet static address 192.168.0.200 netmask 255.255.255.0 network 192.168.0.0 up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 up echo 1 /proc/sys/net/ipv4/ip_forward up iptables -P FORWARD ACCEPT down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 (sorry if some lines ge broken up) The autopart is not always working, but 'sudo ifup usb0' and 'sudo ifdown usb0' make the trick when auto fail. The only other thing I remember is adding my nameserver to /etc/resolv.conf on the neo. But it do asume Your pc/laptop is not on the 192.168.0.x net. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OT:administrivia -- a request to reduce duplicate mails
Joshua Layne skrev: Hi all, I am subscribed to several of the openmoko lists. When someone copies multiple lists on a message, I get all the copies (usually 3 for some reason). Worse, when anyone replies to the initial mail, they reply all and I get another full set of mails. I realize that there are valid reasons for crossposting some of the content (particularly by core devs). Could I request the following? Send one email to each list (instead of copying all lists on a single email) That's a bad idea for two reasons: 1) If the message was appropriate for cross posting, so is the discussion. Else we get a fragmented discussion repeating the same points in all lists, making thing worse for people reading all lists. 2) If it is the same mail it is trivial for mail software to detect duplicates and remove them. If its different mail the problem get much harder to handle technically. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Development env *on* the neo?
The toolchain is great news, but I rather avoid cross compiling completely and build native on the neo. Building small apps should not be too slow on the neo. And having the build env with You on that 9 hour train trip is *good*. As most development and testing can be performed on the desktop You would only need to check out and build on the neo maybe every second day. Would not hurt even if the build take some time! But You don't want to build more than necessary. I have seen gcc, g++, make and stuff available for ipkg - but are there any dev versions of the libs available? And would it be possible to have stripped libs on the neo and install dev libs (and dev env) on the memory card? /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Development env *on* the neo?
Shawn Rutledge skrev: Yes all the ipkg's you need exist, but there isn't enough flash to install them all. What I did is reformat a MicroSD card to ext2, cp -a /usr to the card, then modify /etc/fstab to automatically mount the card on /usr at boot. Then install task-base-dev and whatever else you need. The regular image is not modified much (since nearly all the new files are installed under /usr), so you can still run without that card, but if you have it mounted you have all the tools. Thanks, exactly what I was hoping for. Is all in the default repository's or did You have to hunt it down? My plan was to mount the sd card as /dev and use 'ipkg -d /dev' to install all dev related. But I'm not sure about all needed to tie it all up (PATH, lsconfig etc). Will try Your way insted, it's proven and I'm not really going to switch sd-card (unless to get a bigger one, but that uncommon enough so a little extra work is no problem). Now off to flash 2007.11 and getting on to it. Thanks again /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Development env *on* the neo?
Shawn Rutledge skrev: On Dec 4, 2007 7:13 PM, Lars Hallberg [EMAIL PROTECTED] wrote: Thanks, exactly what I was hoping for. Is all in the default repository's or did You have to hunt it down? Just do ipkg install like usual (assuming you have set things up so that the phone has 'net access, like via NAT over USB) great! But I hit some kind of brick wall... The dfu-util that comes with 2007-11 cant run om my ubuntu 7.10 (gutsy) system (seams not to be recognized as a binary at all. MD5 sum is OK, and yes, execute rights is set). The only other I found is from April, it runs but feels too old. Specially as the README tell me to flash uboot (my is from May). Have no debugboard so I really not willing to take extra chances on that. Reports of usb trouble in gutsy does not make it feel better :-/ BTW: readme say 'use August uboot' but ther is a newer in 2007-11 dir itself. Is that less stable? Maybe I should wait for it to be stable, not having a debugboard I realy want to flash uboot as few times as ever possibly. Might later attempt putting kernel stuff on hold and upgrade with ipkg. If it renders phone unusable (until reflash) it's OK. But I really want a working 'pda' for developing. My plan was to mount the sd card as /dev and use 'ipkg -d /dev' to install all dev related. /dev has a reserved meaning (device nodes). Doh, t late at night... should *realy* not attempt flashing uboot now :-) But I'm not sure about all needed to tie it all up (PATH, lsconfig etc). Maybe ipkg -d takes care of some of the work for you, but I haven't tried lately (seems like something was not quite right when I tried it on the zaurus a while back). OK, Thanks for the info. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email App (why openmoko-apps not on gmane?)
Mike Montour skrev: Lars Hallberg wrote: http://lists.openmoko.org/pipermail/openmoko-apps/2007-November/000279.html Is there a reason this list and others like the owner list is *not* available on gmane? Would be far easier to follow. It is there - gmane.comp.handhelds.openmoko.apps (as are all of the others). That's where I read the lists - I'm only directly subscribed to announce and device-owners. Sorry... didn't hit the update button *banging head to wall*. Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone and 850, perspectives
Doug Sutherland skrev: 850Mhz is odd because north america is big. Output power 2 watt versus 1 watt for 1900 Mhz. To cover rural areas, less towers required for 850Mhz. There will be more not less 850 support in the future. Europe is much more congested so can justify more towers with less output power on phones. Not really true... Europe have GSM 900/1800... 850 is not that big a difference from 900, nether is 1900 from 1800. Probably the 900 and 1800 bands was occupied in the us. However, Ericson and Nokia are pushing GSM 450 for the 3:d world and the most remote arias in richer countrys. So we might end up with the need for 5 GSM band: 450/900/1800 for 'the world' and 850/1900 (and possibly 450) for 'parts of America'. The part with lower frequency give bigger coverage is true. 900 reach ~twice as far as 1800, cowering ~four times the area. 450 will reach ~twice as far as 900, cowering ~sixteen times the area 1800 cover. Thats the rational for GSM 450. Hope the Neo1973 GTA2v4 will be released fast as possably as is. Then a 850/1800/1900 as soon as posably. Don't think a sales organization more then the already existing one need to be built in north America before the 850/1800/1900 version is ready. If this is reconfigurable in soft/firmware... It's realy a quad band phone... You just have to configure what three band to listen to. I Know of no place having 850 and 900 in the same aria. I have litle hope for that tho... It sounds like hw changes is needed :-( /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sv: New input method demo!
Mikkel Meyer Andersen skrev: Hi, I've also tried to develop a keyboard for finger-use. I started with developing a dictionary library, and have only made a very simple GUI to use it. I haven't seen you keyboard yet, but I'm really looking forward to. In addition to this, I hope to be able to incorporate the dictionary I've made. I'm been thinking about this for a while... And Yes thanks... I want to play with it. While the app often have better knowledge, it make sens to put the logic in one place. To give all apps completion, and to avoid duplication. An api to let apps control what they need would probably not be too complicated ether. So, Yes... Where can I find the code and data? I would also want to find a list of the most used English words... To add directly in the keyboard layout. It is better for short words then completion, and the most used words is often short. As positions in the keyboard layout have to be memorized to work fast it will work for far less words. So completion is a nice complement. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New input method demo!
New demo, download 3key package at: https://projects.openmoko.org/frs/?group_id=42 Short intro: 3key demo - input method for touchscreen (both finger and stylus). All good things are three. This is my third demo and it uses three keys! goal * Be usable with one hand (hold phone and type with the thumb). - Reached in full. * Use little space on the screen. The application should have it! - Reached in full (take less space then the qwerty keyboard). * Be usable without visual contact (type in Your pocket). - Reached. * Reach all chars and functions and be extendable. - Reached in full, extendability not implemented in the demo. * Be usable without training, even if slow. - Reached, You should get it under one minute. * Reach descent speed, even if it takes training. - Reached, but takes allot of training and is still no high speed method. The speed is approximately twice as good with stylus vs one handed thumb writing. Two handed typing with one finger is somewhere in the middle. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New input method demo!
Vincent skrev: On 25/10/2007, *Zalunin Pavel* yeah, please let us see I've made a screencast: Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Robin Paulson skrev: on the other hand, we were specifically talking about the driver for the gps hardware, which is a receive only radio, and hence not covered by the same regulations as the gsm radio Yes. And I'm fully in suport for OpenMoko picking a new GPS unit with full os support. Butt... For the old GTA01, that have the old chip, and that will not be used in the future, it is completely sufficient with a binary driver accessible thru the same interface as the GTA02 phones (even if it needs to be some function limitations). That's what originally stated anyway. Not getting GPS functionality at all on GTA01 will make me a bit sad thou. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: List formatting request
Doug Parker skrev: Excuse my repeat request, but is there any way to add a blank newline after the SUBJECT: line in the email postings? It would make all of the lists a lot easier to scan. At first I'm just as confuse as Henryk, but, Doug... Do You mean in the digest of the list? I have no clue hove the digest look for this list, but for digests the request might make sense. Sometimes digest is made for being unpackable by the mail client, in that case it's still a client issue. But sometime they not, and then it might be a malinglist server issue. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is neo1973 dual boot possible?
Lorn Potter skrev: Krzysztof Kajkowski wrote: Hi! Is it possible to have both Qtopia and OM environments on one phone? One could be able to chooses system on startup (such as grub or lilo chooses Linux or Windows ;). That would be useful - you could use Qtopia env as a phone during day but at night you could reboot to OM and start hacking ;) No need to boot two systems. The way I originally ported Qtopia to the neo was putting Qtopia on the sd, symlinking /opt/Qtopia to that, stopping gsmd and all the x-server, and running the qtopia startup script. This probably could be a choice at init time, or some 'app' in Neo/Qtopia that does this. Is there any documentation on this? A wikipage or something. This is how I want to try/use Qtopia. Don't know any of OpenMokos init system (yet, my GTA01 is on the way ;-), but something equal to switching run level to switch forth and back between OpenMoko ui and Qtopia ui would be perfect! /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New TOP SECRET OM device??
Gabriel Ambuehl skrev: So what is HXD8 all about :P From what I herd it's 'not a phone'. But I got a strange feeling that I want it when it is reveald what it is :-) Damned, how shall we find time hacking on OpenMoko when we need spend all time on making more money? God news! My GTA01 have shipped: PHILADELPHIA, PA, US 10/05/2007 12:53 P.M. ARRIVAL SCAN Still a far way from Sweden :-/ /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Possible Input method -- press and drag
Derek Pressnall skrev: I've had an idea for a novel input method that would work on touch screen devices. The idea is to present a graphic that is similar to a standard phone keypad layout, with standard lettering and number positions. To enter a specific letter, you touch the button associated with that letter and drag your finger/stylus in a particular direction to indicate which letter to choose. For example, to enter an a, press the number 2, then drag to the left and release. A b would be press 2, drag upwards and release, and a c would be press 2, drag right then release. And so on. To enter the number 2, just press and release without dragging. To be easily usable, the method shouldn't require you to drag completely off the button, but should also require a minimum drag length. Take a look at the octakey.py demo in the key2key.tgz on: https://projects.openmoko.org/frs/?group_id=42 (You can find it in svn too). It's an adoption of http://www.micropp.se/openmoko/ without splash pop-up and with 8 drag directions. Sounds pretty the same. You need py-gtk and python to run. Feel free to play with it, I'm more working with key2key.py right now (slightly harder drag input - You have to hit other keys, not only drag in right direction. On the other hand You get more functions as any other key can be a secondary target). And finger-keyboard is a good project to join if You want to experiment with input methods. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Apple's heavy hand an opportunity for Linuxsmartphones likeOpenMoko
[EMAIL PROTECTED] skrev: This is not about style. This is about optimum human/device interaction form factors. It is the size and shape and layout of the iPhone that strongly influences the usability of the device. And...And...Who says you can't want style --AND-- freedom? Have not got my Neo jet (hope it's soon), but I think the form factor is good based on earlier use of a touch screen smart phone (Qtech 1010). I think the size and shape will make it fit nicely in one hand and be operated with the same hands thumb. Small (physical) screen reduce the need to stretch Your thumb to reach the whole screen, some space between the phones edge and the screens edge is good as my experience is it's hard to reach to close to the thumb (if you rest the phone natural in the hand). Two-hand operation will more or less always work almost any form factor. But the Q1010 is to big to be a comfortable one-hand device... Belive the Neo to be just right... Then... No size fits all. Anyway, it's too late to start from scratch and be ready in 6 month. Now is time to focus on getting the software and interface good. I'm experimenting with an input method, but right now I'm waiting until I receive my Neo... I really need to test it on a real device to get the feel of it (and hopefullyy the project site's svn is fixed by then). If we succeed at OpenMoko the software platform sure there will be loots of phone using it, from FIC and others, and probably some will use the 'iphone' form factor... Don't worry :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Josef Wolf skrev: On Wed, Sep 05, 2007 at 03:53:17AM +0200, Lars Hallberg wrote: Pretty simple, You have 12 key (3x4 array) and ether tap a key or press it and drag to any of the other 11 keys - 12 functions. It's extendible - If You add a column of keys You got 15 keys with 15 functions. Actually plan on letting the user (and possibly apps) customize the keyboard in part - that may include adding extra columns :-) Ah, OK. But don't this have the drawback that it is not possible to show the positions second-level characters in advance? So you have to guess which key to press to find out whether the character you look for is on the second level of the key you pressed. Yes, kind of. You can show the most common (letters, numbers). You can try to group them logically and show a mnemonic hint at what characters are there (ie ,. - punctuation) You can cancel a key press by dragging outside the keyboard to assist in searching. But in the end is all about learning. To be really fast You need to learn the secondary key position so You can start the 'stroke' at once. In practice it don't appear to be as much of a problem as it sounds :-) You learn what You use often fast and the rest is rare enough to not be too troubling. The key layout is not yet in any way optimal, and only in 'numlock' version. To ease learning I believe the difference between numlock and not should be minimal... Like swap the number and the most used letter on each key... Stuff away 1 and 2 on 1, and pulling up the two most used letters left to those positions. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (new versions)
Thanks Morten Lysgaard for letting me on the Finger Keyboard project. Files is now in subversion. Changes include: All program have now a short explanation in the textaria. key2key: https://svn.projects.openmoko.org/svnroot/finger-keyboard/key2key/trunc/ key2key.py - Try to make the slow update less intrusive if You know what keys to tap/drag to, curios on how this feels on the neo, please report. Include Henryk Plötz fix for python 2.5. keyscroll.py A test where all keyboard 'pages' is rendered and shown one at the time in a viewport. Probably won't be faster then this with stock gtk buttons and labels??? The extra page use pixbuf to compare sped with labels. Needs targ.xpm. Speed reports from the neo are welcome. octakey (new name for old keys.py): https://svn.projects.openmoko.org/svnroot/finger-keyboard/octakey/trunc/ Fixed to hopefully render more sane on the neo. Will not spam here any more. If Your interested, follow the project: http://projects.openmoko.org/projects/finger-keyboard/ Major updates will be announced in project news or forum. You are welcome to hack. And... Yes... not *so* important now, but assuming this is a real keyboard implementation. What license is best... LGPL or GPL... Do anything but the OS/standard lib need to link to the keyboard? /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Josef Wolf skrev: On Sun, Sep 02, 2007 at 07:49:43PM +0200, Lars Hallberg wrote: [ ... ] Not much faster I'm afraid, but a new version available at the same place: http://www.micropp.se/openmoko/res/key2key.py Lars, can you please explain what you mean how this new 12-chars-per-key system works? Pretty simple, You have 12 key (3x4 array) and ether tap a key or press it and drag to any of the other 11 keys - 12 functions. It's extendible - If You add a column of keys You got 15 keys with 15 functions. Actually plan on letting the user (and possibly apps) customize the keyboard in part - that may include adding extra columns :-) Over to Your problem. Your Python is probably to old. According to the python docs (3.6.1 String Methods) You need python 2.5: partition(sep) Split the string at the first occurrence of sep, and return a 3-tuple containing the part before the separator, the separator itself, and the part after the separator. If the separator is not found, return a 3-tuple containing the string itself, followed by two empty strings. New in version 2.5. It's probably more stuff that needs fresh versions. Sorry. /LaH I have tried to run this on my suse-box (no more neo's available :-(): [EMAIL PROTECTED]:~ ./key2key.py Traceback (most recent call last): File ./key2key.py, line 271, in ? tmfexample = Key2KeyKeyboardTest() File ./key2key.py, line 243, in __init__ l = self.build_label(k[i][j]) File ./key2key.py, line 100, in build_label (ll, sep, s) = l.partition(:) AttributeError: 'str' object has no attribute 'partition' [EMAIL PROTECTED]:~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Henryk Plötz skrev: Moin, Hmm, I just ran it on a Neo and seems to work okay. The biggest problem is that switching to the second set of displayed keys is awfully slow. Yes... I believe it's the text rendering. dreamingWish gtk.Label had a flag 'cash_rendering' and maybe a method 'pre_render' taking a win as argument so it usable even if the label is not attached to a top level window yet/dreaming Been looking at doing it myself. But I'm a bit of a newbie on the hole thing (gtk, pango, gdk). Have not really figured out how to render according to the gtk style at use. And I'm not sure have important speed is for a demo. Apart from that it's only missing some optimizations of the layout. (For example: Backspace absolutely needs to be a main key. Backspace is important... but a main key when it is only 12 main keys? Figured space and drag back was intuitive. Nobody needs ^ as a main key.) That key, and its 'page' is meant to be user definable, and possibly app dependent... so ju can put backspace there :-) Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Kristian 'kriss' Mueller skrev: Lars Hallberg wrote: This is a new one (Layout is 'numlock' one): http://www.micropp.se/openmoko/res/key2key.py Nice idea. Had to change the code a bit, as the UI of the current version fires up the keyboard if a text entry has the focus - see patch. I intentionally gave the text entry focus so the cursor was visible. But it's not worth the keyboard popping up :-) That means You tested it on OpenMoko? On a neo even? Very curious :-p For me it was hard to choose the right finger to tapping, so that a second one could be used for actual selection. It's better to just move one finger and release it at the needed key. Anyway I like the idea. That's the intended use. 'Two' in the subject means it was two demo's :-) I guess one could learn to write short texts quite fast with one hand that way. Yes... When one learn where the secondary keys are and can start the stoke immediately it should be pretty fast. The other demo, with 8 drag directions should be slightly faster as the drag target is closer and bigger. But the neighbouring keys should be OK (close), the keys at the screen edges (especialy the corners) should be ok (big). Some keys in the middle and top may be worse. A god layout should take this in account... The demo have only a quick and ugly layout thou. This key2key system have advantages to. The other demo have problems around the edges of the screen (drag going off screen) and less function per key (9 vs 12). I'm trying to speed it up so it be a while before Your fix comes out. Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. In the screen shots of 2007.2 the filer toolbar have 6 buttons... and a little free space. Everyone having phones with 2007.2 is that tool bar comfortably usable with fingers? If it is 6x3 is probably the best choice. Lifting the keys up a little from the bottom (maybe put modifier status indicators at the bottom) will add the side down alternative to the bottom keys changing the number of functions on the bottom row to: 4 6 ... 6 4 5x3 - 88 keys, 6x3 - 108 keys. . . . . . . The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Thinking 5/8 of a quickwriting wheel, so the 'neutral area' is in the bottom. Put it on the bottom of the screen You get tactile feedback from the screen bevel (may cut a small 'mark' in case at the middle). One such wheel give 25 'keys'. lay a row of keys at the bottom of the screen. press one key and slide to the middle to activate a wheel (the covers bevel can have small cuts to guide You to this buttons also). If the wheel is big enough the tactile feedback given by the screen edge should make 'blind' use comfortable. I'm not sure hove many button to use... but 3 - 5 (75 - 125 'keys')... However, some keys would probably be duplicated... one wheel for numbers and arithmetic, one for the most common letters... both of these want space for sure one for the least common letters and other less common symbols (can probably do without space) ... Then You probably want at least one more wheel for cursor control, enter, edit keys etc. This is far less intuitive and far less suited for the average user and a poor default, but the one handed blind use is good for walking in traffic or in the woods. And it us only one row of buttons att the bottom of the screen, leaving most for the apps. It's a good 'power option'. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Tim Newsom skrev: What about a continuously variable system which starts with the most commonly used letters and then adjusts itself based on user input. It could learn which letters a specific person uses to type and make them more prominent. Then, depending on modes the programming or web searching or other keyboards would automatically adapt to the best layout based on the users individual behavior. A main factor in speeding up typing is learning the layout, so a layout that change under the users fingertips is bad. But collecting usage statistics and have some function to assist the user in making there own layout at will might be good. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Josef Wolf skrev: On Sun, Aug 26, 2007 at 06:04:15PM +0200, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. It is perfect for the phone functions. But we don't want to stop at trivial functions. The phone function got it's own dialer keypad. But a numeric keypad may be useful for allot else... and I believe it to be most beginner friendly... And... I don't really think it's any big difference in hitting the main function or the secondary functions of a key. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. Sorry for my English... but I think I try to say about the same thing You did her :-) In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Ough, I don't really understand... You want up to 7 functions per key? One only press+release, then press and drag in one of six directions = 1 + 6 = 7. But the keys on the edge of the screen can't be dragged in off screen directions giving less 'functions'. As described in: http://www.micropp.se/openmoko/ Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. Too bad they are sold out :-( No chance to buy one :-(( Well, there will come new ones :-) The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Maybe 8 functions per key (instead of 6) would be a benefit? Only a guess. You can't tell unles you actually tried it. You mean 8 drag directions + just press+relese... 9 functions per key. Might work. Guess testing on the device is how to find out. But 6x5 keyboard with 8 drag directions give: 6 9 9 9 9 6 6 9 9 9 9 6 4 6 6 6 6 4 A total of 128 'keys'... Good *if* it works :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Mohammed Musallam skrev: I believe a simple two character per key would be more than enough as a start (where the current phones are 3 chars per key). A full qwerty is too dense, so cut the density in half by bundling 2 keys into one. The point with the design is not to use modifiers for the keys. You ether tap the key for main function, or press and drag on different directions for secondary functions. Making it almost as fast to reach the secondary function as the main functions. How many functions per key, and how many keys is factors to experiment with. Think ether 5x3 (like Your design) or 6x3 is the best number of keys. The number of function per key reasonable is on of: tap + drag up, down, left, right. 1+4 = 5 functions. The hexagon design 1 + 6 = 7 functions. The first but with added diagonal drag, 1 + 8 = 9 functions. Higher density and higher number of functions mean less need for modifiers to reach input functions. Lower density and fewer functions mean faster and less error prone input but more need for modifiers. Modifiers are harmful as they have to be inputted in serial.. not parallel like on a physical keyboard. Think it takes experimentation to find the optimum. One possibility is to us 5x3 but have an option to add one more column that can be used for user defined keys and app specific accelerators. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Richard Reichenbacher skrev: Is setting up a keyboard for programming really all that necessary? I for one is more likely to ssh out of the phone. My main drive to get a neo is: a) Make some good fun and use out of time wasted in places where there are no computer or net around. Think trapped in the tent some rainy days. b) Be able to spend more time in those places I like better (like the forest and the mountains, festivals and happenings). So... I want a keyboard god enugh to use any CLI/text app and gui tools like editors. If I can occasionally compile on the phone it's even better (need not be fast)! /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko future.
Sébastien Lorquet skrev: (This is a suite to laforge's message on gsmd-devel) hello, I'm a little disappointed about laforge's message :( Made me happy... I'm been a little worried by the expectation to sell 100 of thousand or even millions of units from the start. If they happy with geek sail then we geeks will get the time... whether it takes a half year or tree years... to make the OpenMoko platform and apps realy rock! That increase the likelihood of eventual word domination :-) While OpenMoko core team have to make a UI and framework good enough for geeks, that's the main aria where experimentation is needed so it can evolve into something that really rocks. Targetting geeks only will never help to make OpenMoko known. No, not outside the (pretty big) geek scene... but it makes it ready for being known :-) One important point is reputation. If openmoko is known to be a geek phone no one else will get interested in it. And exactly that will happen if it is pushed to the masses while not really good enough for the masses. Personally I think we will have something autumn 2008 or possibly even spring 2008... /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Product naming / wiki page naming / restructuring
Harald Welte skrev: Hi! Since we're now working on the phase 2 neo, i.e. what is now known officially as Neo1973 GTA02, I'd like to address one issue: For many information in the public wiki, it is not clear whether it is 1) general information about the openmoko 2007 software 1b) information about future software plans, unrelated to old software. So old software should be tagged as 'OpenMoko 2007 Software' or similar. 2) general information common to the Neo1973 phones 3) information specific to Neo1973 GTA01 4) information specific to Neo1973 GTA02 The main two pieces need sooner or later be more distinctly separated. A) OpenMoko the distribution. Your 1) and 1b) go there. Together with sours code, bugtracker, general info of what chipset and standards that is needed/supported. B) Products/targets using OpenMoko. B1) Produkts officaly supporting the use of OpenMoko. Neo1973 will so far be alone here, and 2), 3) and 4) shuld end up here. together with (links to) the neo1973-qemu, binarys for the neo, repro targeting the neo etc. B2) Produkts with hackers port of OpenMoko... At least a list with links. The right name for B) is hard... but if it's target, then anything Neo1973 related should go to: /Target/Neo1973/ And everything outside /Target/ is general OpenMoko stuff. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qemu trouble...
John Seghers skrev: Heh. Yeah, I was puzzled by that when I first read the web page that describes this. Basically, the ifconfig command is specifying the IP address for the Desktop's end of the USB connection. The QEMU side of the connection seems to be hardwired to 192.168.0.202. That worried me for a while. But it not more hardwired then a static rule in /etc/network/interfaces on the phone :-) Easy to change, easy to say dhcp instead of static :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why you won't find me in the forum much
Dr. H. Nikolaus Schaller skrev: i imagine this mail2forum provides some sort of [Subforum]-tag before each e-mail. To answer to a thread, simply answer the last mail of that thread. To start a new topic, just write [Subforum]New Topic Name as Subject of the mail. At least i would implement it this way. And if it isn't so, we could simply write ourselves something like that. I mean: we have plenty of developers in here. How do you make sure that the [Subforum] really exists when users type a message? How do they remember the list of tags? Does the sender get back a notice and has to send it again? A feature of forums, actually *the* feature that make allot of sub-forums possibly in the first place, is that moderators can move posts... email miss-post is not different from forum miss-post so this should be a no problem. If we fix so reply go right, make it possibly for power user to get first posting go right then moderators can take care of the rest. News might be a better 'backend' then mail. Can use equaly many subforums and mail can move as the moderator moves them. mail--news is then a simple step. Nothing (apart from moderators can't move miss-post) stops lists from being equally divided. can we subscribe to hierarchies (this forum and all present and future sub-forum) it would be OK. - - - I prefere a list... or a newsgroup really... that's how i read this list (gmane). Sometimes I use gmain web interface but I newer tried to post. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qemu trouble...
Jeff Rush skrev: Hi Jeff! As I said... I have build the neo1973 qemu... but 'by hand'... It's a small build vs the mokomakefile build everything that's huge. - Lars, Yes, the onscreen keyboard does work, as in the GUI keyboard you click on with the mouse. I click in the upper-left box (white area, not icon) and the onscreen keyboard comes up in my QEMU image. Did not have that white box... compiled qemu with alsa sound support... probably a mistake... Now, when I stopped esd before starting qemu the keyboard works :-) More strange... the today app got it's icons, did not have them before (?!?). Once the today app did not start on boot... it feels a little random. Probably should rebuild qemu with no extra. - I can say that the ability to 'ssh' into the QEMU does work here, but it requires a few steps in the QEMU monitor each time you use it re usb_add gadget:1 that cannot be automated. The usb networking seams to demand a rebuild of the host kernel... I'm not so keen on that. Did try the tun/tap and user network stuff... But I don't believe it will work. That expect to emulate a ethernet nic and neo don't have an ethernet nic. Could probably build a neo kernel with ethernet, but then I think u-boot most go for a 'normal' rootfs... OK for my us... but then I'm back at setting up a crosscompile env for moko... ether a lot of hard experiments or using mokomakefile that will kill my machine (and then I still have to figure out how to make changes). I really would like a solution that works with network 'out of the box'. Ether a rootfs and kernel with ethernet support, or a hack to neo1973 qemu so it emulate a 'built in' usb-ethernet device that in turn talk to qemu user network and tun/tap interface. But I'm not sure I have understand the problem correctly... If I was I file a wishlist bug on neo1973 qemu. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qemu trouble...
Not sure if this is dev or community... I manage to build the neo qemu and it works :-) Have made (flash.sh, downloaded the files manualt as download.sh did not work (no lynx)) a open moko image and it boots but... No on-screen keyboard makes it pretty useless. Anyone having the same problem or even a solution? Network don't work (qemu -net user)... Is this a limitation in the moko image, the neo qemu or my hostsystem (ubuntu 7.04)? Is it somehow solvable? Anyone successfully got network on there qemu moko systems, an in that case how? TIA /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qemu trouble...
Daniel Robinson skrev: Hey Lars, Huzzah to you, sir, for getting that far. I got my ubuntu system up yesterday, but I haven't gotten some of the other pieces working. I haven't used OpenEmbedded or bitbake before. I use perforce at work. I have not set up a complete build env (don't have room)... Just build the qemu according to Manual setup on: http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU And downloaded prebuilt kernel, rootfs and u-boot... all in the above instructions. The 'extra' preparation I did was: install gcc 3.4 and run: # apt-get build-dep qemu That probably will install gcc 3.4 to :-) Then add --gcc=gcc-3.4 to the .configure arguments. To 'flash' the image You need to install lynx (for download) and netpbm (for flashing). HTH /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Perfect set of Neo companion (and power questions).
1) A powered 4 port hub that accept 5-6V external power (hacked to power a usb host connection). The perfect charger for the neo.. and, well, a hub as extra function. 2) A 2.2A 5V power supply (4x500 mA = 2A + overhead). 3) A led flashlight powered by 4 D-cell (LR20) batteries that also can power the hub. (possibly also usable with 5 D-cell for rechargeable batteries (NiCd/NiMH) at 1.2V each). 4) usb keyboard and any other gadget... 5) An extra set of batteries :-) according to wikipedia, alkaline D-cell have a capacity of ~20 000 mAh... At 6V given 4 D-cell but I guess no more will come out of the hub at 5V. That's 16.7 times 1200 mAh... but how efficient is the charging of the phone... can one expect 1 or 5 or 10 full charges? And how much dose the phone consume over usb when already charged? Would be nice to be able to get a rough estimate on have long lifetime one can expect. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
David Duardo skrev: That's great that you have the dexterity to use your fingernails to poke at tiny buttons, but what about the wider audience? Do you think Aunt Jane or Uncle Leo would feel comfortable operating a phone with such tiny buttons? Is this even a relevant question? Is the phone being marketed to them? If not, then who? Before we dive in and start creating user interfaces from scratch we need to have some sort of basis of who will be using the phone and what they will be doing. Right now it is unclear which direction the community and FIC want to take. I have my personal ideas, but I want to get a consensus from everyone else. Initially I believe in some experimentation and choice. After that there is time to seek consensus on the default and guidelines for how to blend in with everything else. But stuff like input method should be easy to replace after taste... That's probably the most important part of the process, identify what should be easily replaced and what interface that needs. The Neo1973's LCD is 43mm x 58mm. I would like a high density input method... but You can come a long way with 3x3 buttons and two press entry. 9x9 = 81 input combinations. Alternatively... make that one stroke where start and end defines the two 'button press'. My favourite for main UI is a text input tool at the bottom, where you input a progressive search term, say we br... That might match: web browser (app) tux web broadcast (web bookmark, document) Werner Brown (contact) Wera Brooks (contact) Wera Brooks at the pub (photo, document) etc.. The matching object is shown on top and selectable. Size on those object can depend on number of matches and can be compacted in intelligent ways like: [contacts 3] [document 12] [apps 2] choosing one hides the input area and use the whole screen to show the chosen matches. Selecting one match show that with large buttons for appropriate actions. Gesture short cuts like select a contact and drag down to dial can speed the interface up. If no search term is entered these 3 categories (contacts, documents and apps) may be displayed for browsing rather then searching after what You want. Maybe there should be 3 modes/preferences the user can shoes and that all/most UI should obey (explicit choices like input method may override): Minimum UI element: Mode name 4x4mm: Small stylus interface 8x8mm: Big stylus/small finger interface 12x12mm: Big finger interface I'm pretty sure the neo can be made highly usable :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hardware/Software UI Relationship
David Duardo skrev: This is where I ran into trouble As high resolution as the the LCD is, it simply is too small to be used with a finger based user interface, which is what most people would want to use on a cellphone because it is most convenient. At the upper bound, with the Neo1973, you can have 3 columns by 4 rows of buttons that are of a comfortable size (.5x.5 inch^2). Actually, the buttons can be slightly smaller and more compact, but I'm estimating for people with slightly bigger fingers. You can see can see what I mean in the following image: My current phone have a touch screen and a UI designed for stylus. The QUERTY keyboard is 14 keys wide on a 55mm wide screen (and it has bevels). That makes 3.9 mm per key. It's a bit painful, but I use it with fingers all the time (fingernails rather). Keys twice that size should work just fine. 5 colums and 7 rows of buttons should be usable on the neo... however a clever UI should generally need less... but that's the density I would use for text input. ... And my fingers are not huge... but fairly big. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for openmoko - bugsafe?
David Lefty Schlesinger skrev: Okay, not to put too fine a point on it, but this is possibly the silliest reason ever for choosing one phone over another. Cell phone communications are transmitted via radio, and are trivial to eavesdrop on with the right equipment. I think the issue is if the phone can bug *any* conversation You have when the phone is around, not only phone conversations. That is a valid concern. And I believe Neo can be safe if we make sure to use the mixer to turn of the mic/speaker connection to the gsm chip while there is no active phonecall... That is... unless ti have a mic on the gsm chip :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 Update!
[EMAIL PROTECTED] skrev: the GPS daemon would need to be updated to allow for kallman filtering using those accelerometers, so that the GPS apps could continue pointing the phones location inside tunnels and stuff Unfortunately not. As already pointed out on that list, the accelerometers error would add up itself. But if it's as good as GPS for 10-15 sec it should be possible to interpolate 10 - 15 GPS measurements while on the move. Must move fast enough so the start vector can be known. But while moving so fast the accelerometers can be calibrated over time by GPS data cramming absolutely maximum accuracy from them! Maybe detect moving in and out of GPS echoes and compensate the results to. It will also add real time info on acceleration making it easier to detect shift of line, change in speed (warn if a speed limit is up ahead). While still or moving slowly - orientation will be lost :-( But for car navigation it will be a boost! And for games... Think flipper with tilt :-) Besides: Its only two accelerometers. You can do 2-dimensional 'navigating' with that, no more. No tilting/rotating. Thats assuming each accelerometer is a single point. But if the tree axes is measured with a small offset from each other? That would give more info so thats how I guess they are built. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crossroads
hank williams skrev: On 3/13/07, *Gabriel Ambuehl* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tuesday 13 March 2007 18:49:17 dimitris wrote: Sean, given the uncertainty surrounding Wifi drivers, would an externally-accessible SDIO slot be a better step for the next hw revision? I would very much welcome a standard SD slot anyhow. SD cards are available in bigger sizes than MicroSD. A slot would be great, but I dont think we should be encouraging to forget wifi and just let people buy a card. It is important that developers be able to assume wifi as a baseline standard. OpenMoko is a platform for (in the future) many devices... Don't think You can assume too much anyway. I'm happy with a sd slot (or even, but less happy, with one more but external micro sd slot). Supporting binary drivers for third party extensions is a lot less evil than including stuff that need binary drivers. ... but it depends on if it is realistic to get an external slot into the phone. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AGPS - protocol specs?
Nils Faerber skrev: Exactly. Also relative positioning can be made much more precise using the raw data (AFAIK in the range of cm not m). Wow! If this is true, speed and direction can be fairly accurate calculated even at low speed. This makes orienting a map with the moving direction towards the top of the screen useful when walking... a virtual compass! Also short distant measuring (a few meters) can be useful! Wish You all luck! PS This would somewhat compensate for the lack of accelerometer and gyro... but would on the other hand make them more useful as You at even low speed can calculate the 'start' vector and you would get more interesting stuff out of the 'realtime' data provided. ie, pointing at buildings etc with gesture should really work (if You move, but slow walking would be enough)! DS /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Lars Hallberg skrev: Gabriel Ambuehl skrev: I meant for the second level, where they are essentially already in a hexagonal shape... Yes, hexagons is better then yes.. just harder to mock up ;-) Thinking more on it... hexagons is not best... as the splash pops up in the center of the press, the middle button need not be big (just cover for accidental slip). Better to increase the drag targets (making it more of a drag vector thing. Updated: http://www.micropp.se/openmoko/ with new 'splash' design and more explanation. Thanks everyone for the feedback so far. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl skrev: On Monday 05 March 2007 03:21:15 Florent THIERY wrote: Yeah, it looks neat. I think I'd downscale the number of special chars though. I very much doubt you could actually read the characters on the Neo screen right now. Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special purpose :-) Hopefully, You soon learn where the keys are. And allot can be done to improve the graphics :-) But there's a problem i didn't find an answear to: - the neo will have a monopoint touchscreen (at least at first) - a finger is way bigger than a detectable area - What point will exactly be detected while pressing somewhere with a finger? I don't think those an issue here: you tap on the key (might want to scale it down to 6 keys, that still gives you 36 characters which is enough for just about any character based language I can think of), hold your finger, then move it towards the character you actually want. The phone doesn't actually need you to tap the character exactly, the direction of the vector of your fingers movement should be enough (with 6 adjacent characters, i.e. honeycomb [1] like layout, you still have a 60° field to hit)? Yes, it's that 'spalash' effect of adjacent keys that's the main concept, not the exact layout. However.. 36 keys may be good for entering contacts data... but I *want* a full-blown keyboard level of functionality. For me, a common use case is remote admin of servers with ssh... and any legacy terminal app may be used (completely unaware of 'mobile envirionment'). [1] which brings me to the point that maybe round buttons aren't the most efficient way of doing it? Round match hexagons well. Putting them in a square layout is suboptimal, but the screen is square anyway and i like the common looking keypad, with the 0 in unusual but still logical place. It's familiar in more ways... T9 users should fast pick up where the letters are. I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. Should make it usable in 'tumb' mode with one hand. The press areas should be smaller then the buttons anyway... It's not really that hard hitting a small target, what's hard in finger operation is avoiding adjacent targets. At least from my experiences with a Qteck (os name unrevealed to not hurt anyone innocent). One question is if the scroll wheel is needed simultaneous with the keyboard. That would else leave room for 4 buttons (24 keys) more. But in that case maybe 5*3 with 'space' on the sides so all buttons can have all 7 combinations would be better... 5*3*7 - 105 keys. And I'm unsure about the 3 boxes on top... maybe completion should go in the app area with 'normal' keyboard interface (enter, tab). reminder on link: http://www.micropp.se/openmoko/ /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl skrev: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... You can always take a closer look by pressing a button, and drag out of the 'splash' if it's wrong. Which gives rise to the question of how to best arrange them... Yes.. I'm most unhappy about esc and del, and I want to get PG Up and Pg Dn in there to. The numbers are OK, The letters reuse knowledges that T9 users have. The 3 buttons at the right feels OK, as do the cursorcontrolls. Add another button that allows to tap shortcuts (for example like it is done in some of the vnc clients). In general, I find I'm using LESS keys for terminal work than for text entry. YMMV. Is not this more the apps responsibility The messenger app know who I'm typing to, and can analyse what I usably type to that person. I meant for the second level, where they are essentially already in a hexagonal shape... Yes, hexagons is better then yes.. just harder to mock up ;-) I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. If you use drag vectors instead of actual taps on the buttons, you might get away with very short drags, really. To short drag might make it hard to just tap the 'central' button. But the splash should come up centered round the actual press point, not the pressed buttons center. That way ju can just strike your key... a reasonable right strike starting in the reasonable right spot will work. One question is if the scroll wheel is needed simultaneous with the keyboard. That would else leave room for 4 buttons (24 keys) more. But in that case maybe 5*3 with 'space' on the sides so all buttons can have all 7 combinations would be better... 5*3*7 - 105 keys. Do you really need all those keys? XHTML with embedded both javascript and embedded PHP with embedded SQL... Lots of strange chars... Then there's the editors. A lot of stuff use emacs key binding. Other 'windows' style (like press shift and move the cursor to mark)... ~90 should work. A lot of char may be changed when shift is pressed. And removing the 3 boxes frees 3 keys... but as the strokes still is slower than typing on a real keyboard, keeping the number of needed strokes down is good. so many keys is good. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Yet another finger keybord (gui mock-up).
a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
DSP, Yet Another HW wish list item :-)
Lurking her more than a while, I strangely not seen this HW request. A reasonably general digital signal processor on the phone. Opening possibility's for all kind of things. accelerated decoders/encoders for audio and video, voice recognition and fingerprint, 2D graphic acceleration, 3D graphic acceleration, accelerated image (think gimp filters) or just any advanced operation... or just making up for missing FPU. While probably more power hungry then respective dedicated chip, it's probably a lot more efficient then the ordinary CPU... and more powerful and flexible. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki Editing Guidelines
Harald Welte skrev: This is really important not to confuse users. Imagine somebody googling for GSM Phone and Wifi and he ends up in our wiki on a page that describes what wonderful things you can do with wifi on an [not explicitly marked as imaginary] OpenEZX phone. Now that person buys a device, to only then find out that this is some wishlist/dream of somebody. It's even more complicated... OpenMoko being a distribution. An idea may or may not be implemented in the distribution. May demand some hardware features of the device. Finally, different devices that physically have those features may or may not have these feature supported in the distribution. Marking things wishlist is a start, but listing needed hardware features is nest step, and when it matures and start being implemented, listing supported devices may be a good idea. But maybe a list of OpenMoke supported devices and what features are supported for those devices can replace a list of supported device for each application/idea. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Any alternative ideas to fullscreen popup-messages?
Jason Weathered skrev: With regards to accidental clicks, I have a couple of ideas: * Two taps at opposite corners or opposite edges to unlock. * A quick left/right/left triple tap or left-right-left drag action in the middle of the screen. * Apple's iPhone has a slide to unlock. A continuous left to right action over a certain region unlocks the phone. Since the display isn't pressure sensitive I'm not sure of that yet... resistive display can't do multi touch, but they might be pressure sensitive... or rather can do 'area pressed size', witch can translate to pressure for a soft tip like a finger. I think any of these options would probably work. Can we have all of them? :) Might be good enough... But choosing *one* limits the risk of 'false positive'. You could integrate it with some pin code function... You strike a self defined pattern to unlock the phone. Just as an example... split the screen 9 equal parts like a keypad. A strike starting at 3 and ending at 5 equals 35, a tap at 7 is a stroke starting and ending in 7 so equals 77. Than You can get a 4 digit pin in two strokes/taps. an 8 digit pin in four strokes. Say You have to enter the right strokes within 5 sec to unlock the phone. The phone unlock when You lift Your finger after the last stroke, so Your stroke can not interfere with any app runing. Now I start to feel safe that my pocket can't crack the phone :-) But the strokes must be possible to enter with one hand without visual contact... so the details might need to be different... Think I need to have the neo in my hand to really 'feel it out'. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Any alternative ideas to fullscreen popup-messages?
Michael 'Mickey' Lauer skrev: Let's distinguish two types of popup-dialogs: a) informative (i.e. battery low, incoming sms, sms sent) b) confirmative (Mickey calling. Answer / Ignore / Reject?, Do you want to remove all contacts?) Right now, we're leaning towards (ab)using the bottom status bar (in openmoko-language called 'footer') for informative dialogs and using half screen (480x320) popup dialogs for confirmative. Let's distinguish asynchronous and synchronous popup. Do you want to remove all contacts? is probably synchronous, a direct reply to a users actions. Then a floating modal popup is OK. But it should be slightly less then half screen and movable - so You can inspect the screen before answering. Avoiding one gui annoyance. For asynchronous popup, like incoming phone call, The footer notification aria is better. Along with the notification area could be a 'popup' botton showing more info and buttons for actions in a 'popup' aria sliding up from the footer. The aria should have short history (2 min?) navigation for when allot of notifications comes in fast. That is enough for most stuff (like incoming sms). No button pop up over user action unless the user ask to. Phone call *are* special on a phone :-) There should be one tap to answer the phone, and always in the same easy to find position. So, put the notification area in one side of the footer, the general popup button on the side facing away from the corner. When there is an incoming call, use the notification aria as usual, but put an 'answer' button in the corner end of the aria bar. The corner is easy locatable, it is a corner normally covered by the notification area so no user interaction should ever go there. And newer ever use that space for any other interaction! Games will want to brake this... So... give them an option to move the footer to the top of the screen (more rarely used fore game input)? Buttons to cancel the call should be on the popup like normal, together with all info on the caller. Wasting the complete footer for notifications sound expensive, but have the advantage that popup button also ends up in a corner. But I bet a keyboard button and a few more is more important. BTW: I'm not completely against phone call popup to popup automatically, but then any buttons in the popup must be disabled for 1/2 a second. Actually, it's not *too* bad having preferences for what event that should auto popup and not. Harder problem... What to do when the screen is off and a phone call comes in? Turning the screen on is OK, but I don't want the touch-interface to go on in my pocket... so what to do that's not completely awkward. See little choice but to use the 'hardware' buttons. But there position do not look optimal. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: collaborating on bluetooth audio
Brad Midgley skrev: Koen After reading the LCA slides on pulse-audio it seems to be the best choice for an audiorouting app FYI, I mocked up some diagrams including one that incorporates pulse. I am hoping to have some of these ideas validated, so let me know if you have any thoughts on it. http://bluetooth-alsa.sourceforge.net/future.html#pulse I like the use of D-bus for finding out whats there and hove to use it. But there really should be *one* audio connection manager. Were I can find a headset whether it is connected by usb or blutooth or anything else. And find out hove to connect to it (preferably in many ways, ie: hove to build a gst stream, hove to connect by pulse, hove to get a dsp interface, hove to get at it with alsa, hove to get at it by some lowlevel interface (eg: by blutooth directly). So an app can choose to connect the best way it know. For apps that don't care much for latency, it shuld be possible streaming the sound by D-bus, encoded with mimetype, or tell the D-bus service to play a file with (optionally?) given mimetype. Record to a file or D-bus stream into given mimetype. Then those apps only need to know hove to talk D-bus to get sound support. Don't need to know anything about encoders or conections, just ask the system what is supported. That gives a few D-bus services: General audio connection mgt, possably xfer agent. Blutooth audio device discovery agent. USB audio device discovery agent. Build audio connection service (possably several different 'protocol'/sources/targets). Support for mixer to? D-bus audio sink (passably several different for different formats - destinations). Support volume? D-bus audio source (passably several different for different formats - source). Support volume? This can be implemented in one demon, in several demons, inside other demons (like ones who discover other usb/blutooth devices). D-bus activation should let the app just talk to the D-bus interface the General audio connection manager point it to. Even pulse could be started on demand if we want :-) It need not be implemented in one shot ether. It's possably starting out supporting, say, only pulse and only main audio and blutooth. But USB shuld be a priority too. The D-bus audio sink/source may be left to more advanced media player apps/libs to implement. The audio connection mgr only need interface to register services and offer them. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: GNU, evangelizing, whining, rudeness, etc.
David Ford skrev: We overwhelmingly need a community-evangelize list of which I won't be subscribing to. This is a good suggestion. I'm actually interested in this topic, but refuse to take part in it on this list as it's so obviously of topic. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
qemu and images.
First: I understand if all developers are busy right now... But after February 11... Can we get a release of a kernel and disc image for qemu, and the repository so we can update our image. Then we can explore the environment, test not only our software, but our ipkg packaging. Hack not only on application but try out kernel patches. Well, got the feel for it! High on my wish list! Side note final release 9/11 Isn't that a poorly chosen date... Whatever You do it will piss someone off. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
