Re: connect freerunner with debian to a windows-PC

[matthias]

Bastian Muck schrieb:
> Gothnet schrieb:
> > This isn't going to help you but...
>
> > The windows driver seems dodgy. The 5th of december Android image made
> > windows bluescreen when you plugged the FR into a machine with the
> driver
> > installed.
>
> > Linux is your friend, though of course that's not always possible.
> I don't know what your problem is. I conected my fr often to my
> Windows XP and never had problems. I tried 2007.X, 2008.X and Qt Extended.
>
> Greetings Bastian
But is there anyone who tried it with debian?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: connect freerunner with debian to a windows-PC

[Bastian Muck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Gothnet schrieb:
> This isn't going to help you but...
>
> The windows driver seems dodgy. The 5th of december Android image made
> windows bluescreen when you plugged the FR into a machine with the driver
> installed.
>
> Linux is your friend, though of course that's not always possible.
I don't know what your problem is. I conected my fr often to my
Windows XP and never had problems. I tried 2007.X, 2008.X and Qt Extended.

Greetings Bastian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFJZDvPlYiDScJJ+7QRAupGAJ9N98wl3JMQF/1Tj47XdUQnzUdb4QCePexM
Etduiuh03u01aCpxgQeRaKk=
=YG52
-END PGP SIGNATURE-


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[Timo Juhani Lindfors]

Brock  writes:
> You could also check out the 'watch' command.

It only shows the latest number, I want to see the trend with as much
history as possible.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

is there an effort to port ubuntu to openmoko?

[Harry L. Lee]

-- 
ha...@jonesnose.com
Harry L Lee (via gmail)
chief cook and bottle washer
http://jonesnose.com
mailto:ha...@jonesnose.com
207-384-8030 (email preferred)
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Dying battery

[The Digital Pioneer]

GTA02 with SHR and mwester kernel. How often does mwester release a new
kernel? Maybe it could use updating...

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: connect freerunner with debian to a windows-PC

[Vasili Sviridov]

Gothnet wrote:
> This isn't going to help you but...
>
> The windows driver seems dodgy. The 5th of december Android image made
> windows bluescreen when you plugged the FR into a machine with the driver
> installed.
>
> Linux is your friend, though of course that's not always possible.
>   
Everything is possible with LiveCD/LiveUSB Stick :D

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Dying battery

[Brock]

On 2009.01.06.19.31, The Digital Pioneer wrote:
| OK, I just don't get how this can be... Why is it that I can have my phone
| in my pocket all day, I don't touch it, and when I check it, it has 3/4 of
| the battery monitor still; and then an hour later it's dead? Can someone
| explain this to me please? It's completely illogical to me.

Perhaps this is the Bouncing Calypso bug, in which the GSM registers and
unregisters a whole lotta times.

  http://docs.openmoko.org/trac/ticket/1024

It appears that most or all distributions have a work-around? You didn't
mention what flavor you're running...

--Brock


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[Brock]

On 2009.01.06.18.30, Timo Juhani Lindfors wrote:
| my ~/bin/loop does
| 
| #!/bin/sh
| while true; do
| $1
| sleep 2
| done
| 
| so I can just "loop gsm-strength", "loop energy", "loop
| temperature" or "loop consumption".

You could also check out the 'watch' command.

--Brock

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: stupid networking question

[Joel Newkirk]

On Tue, 6 Jan 2009 20:09:14 -0500, "Harry L. Lee" 
wrote:
> I have an  eeepcwifi'd into the Net, running ubuntu,but when i plug the
> openmoko into one of its usb ports it goes into wifi reconnection. halp!
> 
> --
> ha...@jonesnose.com

What Ubuntu version and flavor?  Network Manager has issues under
8.10/Intrepid - I've only had reliable networking (with multiple
interfaces) when I disabled NM and wrote manual config.

j


-- 
Joel Newkirk
http://jthinks.com  (blog)
http://newkirk.us/om (FR stuff)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Dying battery

[The Digital Pioneer]

OK, I just don't get how this can be... Why is it that I can have my phone
in my pocket all day, I don't touch it, and when I check it, it has 3/4 of
the battery monitor still; and then an hour later it's dead? Can someone
explain this to me please? It's completely illogical to me.

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

stupid networking question

[Harry L. Lee]

I have an  eeepcwifi'd into the Net, running ubuntu,but when i plug the
openmoko into one of its usb ports it goes into wifi reconnection. halp!

-- 
ha...@jonesnose.com
Harry L Lee (via gmail)
chief cook and bottle washer
http://jonesnose.com
mailto:ha...@jonesnose.com
207-384-8030 (email preferred)
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Wed, 7 Jan 2009 00:33:41 +0100 "Laszlo KREKACS"
 babbled:

> > this is be doable. keyboard application can receive message for client,
> > message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> > and message data is one of:
> 
> Is it also possible to change the dictionary on the fly too? (if I
> understand correctly, you are changing the layout ofthe keyboard)
> 
> 
> Thank you for the pointer, I will digg it more!

no - dict isnt changeable - not by app. as such i havent addressed this beyond
"kind of input" that doesnt specifically require a layout or dict to be used -
but hints on input. it's up to the keyboard to do what it thinks it best there.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: connect freerunner with debian to a windows-PC

[Gothnet]

This isn't going to help you but...

The windows driver seems dodgy. The 5th of december Android image made
windows bluescreen when you plugged the FR into a machine with the driver
installed.

Linux is your friend, though of course that's not always possible.
-- 
View this message in context: 
http://n2.nabble.com/connect-freerunner-with-debian-to-a-windows-PC-tp2118647p2120195.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Laszlo KREKACS]

> this is be doable. keyboard application can receive message for client,
> message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> and message data is one of:

Is it also possible to change the dictionary on the fly too? (if I
understand correctly, you are changing the layout ofthe keyboard)


Thank you for the pointer, I will digg it more!

Best regards,
 Laszlo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[The Rasterman]

On Tue, 6 Jan 2009 17:28:30 +0100 "Olof Sjobergh"  babbled:

> On Tue, Jan 6, 2009 at 11:57 AM, The Rasterman Carsten Haitzler
>  wrote:
> > sort -f i think does it... i think...
> 
> Thanks, that seems to work.
> 
> I created a package and uploaded to
> http://www.opkg.org/package_90.html for anyone who is interested. The
> source is hosted at http://github.com/olofsj/swedish-illume.
> 
> > hmm interesting i was just going of german/french and portuguese on this
> > where i thought i could get away with simple normalisation and a basic
> > qwerty layout
> > - with selecting the matches (Vogel/Vögel for example). making the table
> > part of the dictionary does make a lot of sense of course. the dict format
> > does need to change to make it a lot faster and intl-char friendly. i
> > avoided this at the time as i'd need to efficiently encode a b-tree in the
> > file and be able to mmap () it efficiently and use it.
> 
> I understand it would make the dictionary format more complicated.
> Maybe it could be split into 2 files, one with general configuration
> data such as a normalisation table, an icon etc, and then a raw
> dictionary file like there is now.

it could be - but there needs to be a redo of the dict format. i need to at
least add the following:

1. actual match sting and display string should be different. i.e.:
(german) vogel -> Vogel,Vögel
(japanese) sakana -> さかな,サカナ,魚,肴,茶菓な

yes japanese is a silly example as there is no way to "type" matches in kanji
(chinese chars) - you NEED an input method (this is where vkbd and xim etc.
need to tie in eventually).

2. something much faster to just mmap() and use dynamically. it currently is
mmaped with a small lookup table built for faster access - but it still need to
parse whole lines on the fly to do matching currently even tho it's mmaped. so
if the format changes - then it doesn't matter much.

so the above ability to map 1 input match to multiple possible outputs (that
could even be radically different) would negate the need for a mapping table :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 13:28:44 -0600 "The Digital Pioneer"
 babbled:

> I also am somewhat surprised by the lack of an excellent code-friendly
> keyboard. I use QWO because it actually has the capability of syntactical
> symbols and is relatively finger-friendly. Still, sometimes you just can't
> beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that
> takes up the entire screen with just a little space at the top to see what
> you're typing, and once you've finished you can dump the whole mess into
> whatever textbox is focused. A lot more real-estate that way. It doesn't
> have to be transparent either.
> 
> I read most of the explanation of Illume's error-corrective keyboard, and it
> sounded so great, I went and tried it. However, when everything except
> "Hello" was listed when I typed "hdllo" and "hwllo" I gave up on it. :(
> Also, it DESPERATELY needs a reset button to start over on the word, if it's
> not in the list.

yeah - deleting 1 char at a time is nasty. and yes. it seems not to find hello
in the dic - i suspect a bug or 2 in dict matching and stopping a search too
early. again loop around back to "need a better dic format" :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[The Rasterman]

On Tue, 06 Jan 2009 15:58:55 +0100 Pander 
babbled:

> Pander wrote:
> ...
> > However it would be desirable that each .kbd file can indicate:
> > - predictive mode is not possible, e.g. for numeric keyboards. I don't
> > want it to remember my PIN, credit card number, etcetera. (numeric
> > keyboard, a real one, without the é, ë, ..)
> > - predictive mode is default on, but user can temporarily disable it,
> > e.g. when going into a shell (alpha keyboard)
> > - predictive mode is defaul off, but user can temporarily enable it,
> > e.g. when typing proza inside a shell (terminal keyboard)
> >
> >
> >
> >>
> >
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> 
> I think the functionality described above is already partly implemented for:
> - type NUMERIC
> - type ALPHA
> - type TERMINAL
> settings in the .kbd file. But what behaviour is exactly enabled by the
> above types?

none. it's a "hint". for example if the app requests "you're in a numeric input
field - as the keyboard for a numeric mode" for the keyboard code to switch
layouts to that layout. it's to hook with the hints from apps.

> Could TERMINAL and NUMERIC by default also be non-predictive?

they are both non predictive. remember the kbd only puts strings through the
dict - keysyms (raw key names) it doesn't.

> It is not clear for me from
> http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd.c
> and
> http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd_int.c
> what effect it has on predictive mode. Also There are many more modes
> available like HEX, PASSWORD etc.

dictionary use is implied by how the key outputs a char. i.ie using "!" instead
of exclam (for exlamation mark) puts ! thru the dict, but exclam goes straight
to the app - no dict involved. thats whhy terminal.kbd doesnt go through the
dictionary prediction at all - as no keys there output a string.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[The Rasterman]

On Tue, 06 Jan 2009 15:43:35 +0100 Pander 
babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 6 Jan 2009 11:49:55 +0100 "Olof Sjobergh" 
> > babbled:
> > 
> >> Hi,
> >>
> >> I'm working on a Swedish dictionary and keyboard for Illume, but I'm
> >> having some trouble with sorting of utf8 chars in the dictionary. I
> >> can't seem to get the sorting right. Looking at the code, Illume sorts
> >> the dictionary after first normalizing the strings according to the
> >> internal normalization table. Is there any way to reproduce this
> >> sorting with the sort command? I've tried with a few different locales
> >> (C, en_US.utf8) which all make the unix sort command work differently.
> >> But no matter what I try words don't show up correctly.
> > 
> > sort -f i think does it... i think...
> > 
> >> Another issue I found is that the built in normalization table is not
> >> very good for typing Swedish text. On a standard Swedish qwerty
> >> layout, we have three additional letters (å, ä and ö). These are used
> >> very frequently in Swedish and there are many common words that have
> >> different meanings if spellt with a, å or ä (for example har, här and
> >> hår are all very common words). But in Illume these are all normalized
> >> to a. Writing Swedish with a US qwerty layout and then having to
> >> select aåä manually after the dictionary lookup is a pain, since many
> >> common words will have to be selected from the lookup list each time.
> >>
> >> Instead, what you want is a Swedish qwerty layout (which is very
> >> simple to implement as a .kbd file), and not normalize åäö for the
> >> Swedish dictionary lookup. So the normalization table would really
> >> need to be configurable, either as a part of the dictionary or the
> >> .kbd file. I suppose this problem exists for other languages as well.
> >> If I were to work on such a change, what would be the best approach?
> > 
> > hmm interesting i was just going of german/french and portuguese on this
> > where i thought i could get away with simple normalisation and a basic
> > qwerty layout
> > - with selecting the matches (Vogel/Vögel for example). making the table
> > part of the dictionary does make a lot of sense of course. the dict format
> > does need to change to make it a lot faster and intl-char friendly. i
> > avoided this at the time as i'd need to efficiently encode a b-tree in the
> > file and be able to mmap () it efficiently and use it.
> 
> Mapping of cafe to café (French) and Vogel to Vögel (German) is indeed
> handy, this funcitonality would be handy internationally for most languages.
> 
> What about mapping Koeln to Köln etcetera? This would be handy for
> German only. Like the above story is (maybe) specific for Swedish.

yup. i've gone over this before. i think the solution is a dict change. you
have a match string and a list of possible outputs:

vogel -> Vogel,Vögel
koln -> Köln
koeln -> Köln

etc. etc. - this allows arbitrary mappings from 1 string to any other. should
cover a whole HOST of languages (japanese, chines and korean included if using
the romanised input methods of these languages). again - whole dict format
change would be needed and it'd be much harder to crate dicts.

> Perhaps an optional config file can be provided for the dictionaries
> that need one. Keeping this info outside the dict itself eases sorting
> of the dict and upgrading dicts. I would keep this optional config
> surely independent of the .kbd keyboard configs.
> 
> Raster, the dicts I'm making for Dutch will be a large version (250.000
> words) and a small version. Do you have an indication how many words is
> advisable for the small version?

you don't really need a small one - the small english one i used 1. because it
was simpler to check my match results in a small set of data and it used less
ram in my initial "in memory only" dict code. in the end there likely need a
major dict format and data content change to basically support all this stuff.
but once done it should cover a whole slew of languages.

> However it would be desirable that each .kbd file can indicate:
> - predictive mode is not possible, e.g. for numeric keyboards. I don't
> want it to remember my PIN, credit card number, etcetera. (numeric
> keyboard, a real one, without the é, ë, ..)

outputting keysyms instead of strings (like Terminal.kbd) bypasses the dict. so
this is how it is effectively turned off.

> - predictive mode is default on, but user can temporarily disable it,
> e.g. when going into a shell (alpha keyboard)

that's what Terminal.kbd is for... ?

> - predictive mode is defaul off, but user can temporarily enable it,
> e.g. when typing proza inside a shell (terminal keyboard)

of course this can be done - the problem is - where do i "conveniently" attach
all the controls. i guess if no word is composed currently ^ on the top-left
can pop up a control panel.

but for now - kbd is not on my radar - got other things to do at the moment. :(

-- 
---

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 15:14:56 +0100 Mathieu Rochette  babbled:

> Laszlo KREKACS wrote:
> > Hi!
> >
> >>> First and foremost, it is us
> >>> hackers that use this device for now and are supposed to make apps for
> >>> freerunner and all, and we don't have a damn keyboard;). All this
> >>> fancy pancy dictionary based guessing is maybe good for normal people
> >>> writing crappy SMS messages, but not for the current user base, in my
> >>> opinion.
> >> you do - Terminal.kbd layout - it ships with illume. i designed the kbd
> >> engine in illume to allow for straight-through pushing of key presses
> >> without a dict int he way. the Terminal.kbd bypasses dict lookup by just
> >> emitting keysyms as opposed to strings. don't like the keys on that .kbd?
> >> edit the .kbd file. change it yourself! its just text!
> >
> > Im planning to develop an application, where is a table, and in each column
> > I want different keyboard layout with different dictionary.
> >
> > Is it possible to change layout and dictionary on the fly? (ie.
> > entering in another text input field).
> >
> > The application would be something, in the first column is only
> > numbers, so I want a keyboard
> > with [0..9-.] buttons, and accept only numbers. In the second column I
> > want to write down what I see (microwave, lamp, soldering iron, etc)
> > and in the third column I want to write the trademark of it (sony,
> > samsung, philips, weller, etc) so I want to change the keyboard
> > between
> > numeric and qwerty, and I want to change the dictionary as of input text
> > field.
> >
> > Is it doable? If so where to start? I know python, and would be glad
> > to see some debian/ubuntu guide how to start programming in efl. (or
> > is it a complete development virtualbox/qemu image? it was discussions
> > about some time ago).
> 
> this is be doable. keyboard application can receive message for client,
> message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
> and message data is one of:
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA
>   - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL
>   - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD
> 
> (I don't know where this list came from, is there some specification or 
> recommendation for virtual keyboard application implementation?)

well ecore_x has a small wrapper for this stuff - but its basically simple x
properties and atoms - i just came up with a list of types of input fields i
could think of and put them in the list. this can be expanded without problems.

> so, the application just have to send one of those messages when 
> entering a field or another.

it's actually a property on the window - but yes. just asking for a "kind of
keyboard" is what the app can do - then the keyboard need to do whatever it
sees fit to honor that request. you cant explicitly select a dictionary though.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Paul Fertser]

Fox Mulder  writes:
> Could it be that i have to issue some command which produces the modules
> tar.gz file?

Oh, man... If you don't want to read ``build'' then please do it by
hand in the root of the build:

rm -rf staging
mkdir -p staging
make ARCH=arm modules_install INSTALL_MOD_PATH=staging
cd staging
tar czf ../modules-whatever.tar.gz .
cd ..

And then scp your modules-whatever.tar.gz to FR and untar to /.

HTH
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Rui Miguel Silva Seabra]

On Tue, Jan 06, 2009 at 12:34:28PM +0100, leona...@lilik.it wrote:
> Hi Raster,
> thanks for the explanation.
> 
> > anyway. i hope this helps people understand how it works. someone can throw
> > this onto the wiki if they like. this is the code i wrote for the illume kbd
> 
> I've summarized this in a page:
> 
> http://wiki.openmoko.org/wiki/Illume_keyboard
> 
> it's cool, you should really patent it!
> :-)))

Please die a slow and painful death for suggesting that. [1]

Rui

[1] unless you were really just making a very bad taste joke :)

-- 
Or is it?
Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Rui Miguel Silva Seabra]

On Tue, Jan 06, 2009 at 04:17:06PM +1100, Carsten Haitzler wrote:
> > All of them have nice big buttons and share a simple layout. The FR's 
> > screen is big enough even in portrait mode to accommodate a keyboard 
> > like this. The Illume keyboard, as excellent as it is (thanks Raster!!), 
> > is fiddly to use without a stylus. I would like to not have to use a 
> > stylus to compose notes/emails/sms. For terminal use (and using VI) a 
> > more complete k/b is of course justified, but for everyday use we need a 
> > nice finger keyboard.
> 
> with dictionary correction the illume keyboard (and the qtopia one) in normal
> plain qwerty for writing notes and emails and sms's work just great - i've 
> used
> them walking down the street and i can type better on it than i can on my rokr
> e6 WITH a stylus. in fact my n800 with a landscape 4.3" screen is almost
> equivalent in usability (it doesnt dictionary correct).

I agree, I used it today to take notes at a meeting. In vi :)

Rui

-- 
Keep the Lasagna flying!
Today is Sweetmorn, the 6th day of Chaos in the YOLD 3175
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Fox Mulder]

Paul Fertser wrote:
> Hi,
> 
> Fox Mulder  writes:
>> I installed the om toolchain and compiled the 2.6.28 kernel after some
>> help of [1] and google with "./build dummy". After i compiled the kernel
>> i got "dummy/uImage-GTA02.bin" what looks quite good so far.
>> But how do i extract the compiled modules from the dummy directory to
>> package them for transfer to the freerunner?
> 
> You gave a parameter to the build script, so it should have installed
> the modules to the "staging" directory and made a file named
> modules$VERSION.tar.gz . Just scp it to your FR and untar to / .
> 
That's what is also described on the wiki page but there is no modules
tar.gz file. I searched the whole linux-2.6 directory with all subdirs
without luck.

I did a "./build dummy" again and i see that at some point it shows
"Building modules, stage 2.". And after that all modules are listed with
extension *.ko which is correct. After i took a closer look i can see
that within dummy and all these other files are the wanted *.ko files.
But it doesn't exist any archive with all of them in it. Now i could
search for every *.ko file and extract it out of dummy, but i don't
think this is normal. :/

Could it be that i have to issue some command which produces the modules
tar.gz file?

Ciao,
 Rainer

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Digital Pioneer]

>
>  Maybe it would be better to have a full-screen input mode where you can
> see what will be typed (maybe keep the rightmost 20-30 characters of the
> string visible in the keyboard app, then actually pass it to the program
> when leaving 'full-screen' mode or pressing 'enter', etc). That still allows
> you to see what you are typing with a full-screen keyboard (which is what it
> seems most people are wanting from the transparency).
>
I think that would be good, though things like tab-completion have to be
considered when inputting to a separate field and dumping the result when
finished.

>From Petr:

> actually i tried it now and even with pure "h e l l o" i got to see
> "Gallo, jello, troop, tempo" and was puzzled as you did... then i
> pressed the ^ icon on the left and learned (again) something new :) try
> it!

Unfortunately, that's the list I was referring to. :( I scrolled through the
entire list (there were probably 15 words) and Hello was not present. Seeing
as the letters I hit wrong were adjacent to the target letter, and I would
say "Hello" is far more common than "Gallo", I was really stunned.
Nevertheless, as has been pointed out... Keyboards like that are excellent
for SMS and whatnot... But when it comes to using a terminal, they are
really not very useful.
On a slightly other topic, I've noticed the programs in my phone stack (such
as creating contacts) are smart about when to have the keyboard up. They
automatically bring it up when you visit a page with text inputs. The
terminal needs this feature badly, but many other apps could use this little
bit of intuitiveness as well.

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Paul Fertser]

Hi,

Fox Mulder  writes:
> I installed the om toolchain and compiled the 2.6.28 kernel after some
> help of [1] and google with "./build dummy". After i compiled the kernel
> i got "dummy/uImage-GTA02.bin" what looks quite good so far.
> But how do i extract the compiled modules from the dummy directory to
> package them for transfer to the freerunner?

You gave a parameter to the build script, so it should have installed
the modules to the "staging" directory and made a file named
modules$VERSION.tar.gz . Just scp it to your FR and untar to / .

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Eldon Koyle]

On  Jan 06 16:59+0100, kimaidou wrote:
> Hi Kieran,
> +1 for your idea : a toggle fullscreen button would be a great improvement.
> I still consider a transparent keyboard will be a good stuff too. By
> transparent, I don't mean "you can click on the interface under" , I mean
> "you can see what you are writting under the keyboard, but cannot have an
> action on the things under". With you "toggle fullscreen" button, the
> transparent keyboard would be an improvement.


  A 'transparent' keyboard would have a high 'coolness' factor, but I
think it would be hard to really see what you are typing (not to mention
the technical limitations pointed out by rasterman).

  Maybe it would be better to have a full-screen input mode where you
can see what will be typed (maybe keep the rightmost 20-30 characters of
the string visible in the keyboard app, then actually pass it to the
program when leaving 'full-screen' mode or pressing 'enter', etc). That
still allows you to see what you are typing with a full-screen keyboard
(which is what it seems most people are wanting from the transparency).

  Extra points could be awarded for allowing applications to give the
keyboard app a description of the 'active' field to be displayed
in a 'full-screen' mode.

-- 
Eldon Koyle
-- 
The graveyards are full of indispensable men.
-- Charles de Gaulle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Petr Vanek]

of the explanation of Illume's error-corrective keyboard,
>and it sounded so great, I went and tried it. However, when everything
>except "Hello" was listed when I typed "hdllo" and "hwllo" I gave up
>on it. :( Also, it DESPERATELY needs a reset button to start over on
>the word, if it's not in the list.

actually i tried it now and even with pure "h e l l o" i got to see
"Gallo, jello, troop, tempo" and was puzzled as you did... then i
pressed the ^ icon on the left and learned (again) something new :) try
it!


Petr



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Fox Mulder]

Fox Mulder wrote:
> Paul Fertser wrote:
>> Hi,
>>
>> Fox Mulder  writes:
 Actually, you can try to change from 2.6.24 after applying an ad-hoc
 patch from http://trac.freesmartphone.org/ticket/293 even on old
 version that's provided by Debian (that's exactly what i did a month ago).

>>> Ok.
>>> I downloaded the fso-frameworkd source, copied the patch into it and
>>> applied it without any problems. Now do i install the fso-frameworkd
>>> with "./setup.py install" ?
>> That's distribution-dependent. I'd suggest to apply the patch to the
>> frameworkd you have already installed and change
>> /etc/freesmartphone/oevents/rules.yaml by hand.
>>
>> Or if you want to try to install from source, you probably don't need
>> any patches at all, as you can install a version recent enough (though
>> it's possible that some SHR apps are not ready yet).
>>
>>> But i have the problem that on [1] only the 2.6.28 kernel but no modules
>>> are online. Where do i get the corresponsing modules for this kernel?
>>> Last time i checked there was an older kernel with a modules package but
>>> no more.
>> I think it's assumed that everything you need for everyday work is
>> compiled-in. If you want to use some webcams or other unusual devices,
>> just compile a kernel yourself from git, it's not hard. Or ask Andy to
>> provide all the modules ;)
>>
> I don't think that all modules are compiled in because the current
> kernel is only 896K in size. And the OM kernels are ~1,7M.
> I already though about compiling the freerunner kernel myself having a
> bit knowledge about normal pc linux kernel compilation.
> But for this i have to set up cross compile what i never did before. So
> first i have to find a good how-to which describes how i fetch the
> kernel with git (never used it) and how to cross compile it for my
> freerunner on my pc.
> It would be much easier if i got a working kernel and modules. Maybe
> andy has a bit spare time to update his website. Else i have to jump in
> the cold water and do this on my own. :/

I installed the om toolchain and compiled the 2.6.28 kernel after some
help of [1] and google with "./build dummy". After i compiled the kernel
i got "dummy/uImage-GTA02.bin" what looks quite good so far.
But how do i extract the compiled modules from the dummy directory to
package them for transfer to the freerunner?
On my pc i just would do "make modules_install" to copy the compiled
modules to the right place. And in the subdirectories of the dir "dummy"
are predominantly *.cmd and *.o files but modules normally end with
*.ko. So i don't know what to to at this point to get the modules out of it.

I hope someone can help me a bit. :)

Ciao,
 Rainer


[1]
http://wiki.openmoko.org/wiki/Toolchain#Building_Openmoko_Kernel_from_git_repo_using_Toolchain

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Digital Pioneer]

I also am somewhat surprised by the lack of an excellent code-friendly
keyboard. I use QWO because it actually has the capability of syntactical
symbols and is relatively finger-friendly. Still, sometimes you just can't
beat good ol' fashioned QWERTY. I like the idea, though, of a keyboard that
takes up the entire screen with just a little space at the top to see what
you're typing, and once you've finished you can dump the whole mess into
whatever textbox is focused. A lot more real-estate that way. It doesn't
have to be transparent either.

I read most of the explanation of Illume's error-corrective keyboard, and it
sounded so great, I went and tried it. However, when everything except
"Hello" was listed when I typed "hdllo" and "hwllo" I gave up on it. :(
Also, it DESPERATELY needs a reset button to start over on the word, if it's
not in the list.

-- 
Thanks,

The Digital Pioneer
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Strength int to bar conversion

[George Brooke]

On Monday 05 January 2009 23:07:39 arne anka wrote:
> not sure if feasible, but what about making it configurable to have either
> the bar chart or the number itself shown?
> the number still could be coloured depending on the level (red to green or
> so, drawing a string in different colours shouldn't be that expensive,
> shouldn't it?).
>
You could even have a number of 'faded in' versions of each of the four bars 
to get a higher number different states.

solar.george


signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Neo / FreeRunner 'stand'

[Pander]

I'm planning to make an open hardware design for something like this and
have it manufactured by a 3D printer. Anyone can have it manufactured at
a place like http://www.shapeways.com/

At the moment I'm waiting to get some help to get started, see
http://lists.openmoko.org/pipermail/community/2008-December/038598.html

Christopher Friedt wrote:
> Wouldn't it be great to have a moulded plastic stand that would just
> clip into place on the back of the FreeRunner or Neo1973, so that you
> could rest it on a table in widescreen mode, and have it sit at a
> comfortable angle?
> 
> Maybe it's a good 'extra' to include int the box for GTA03 :)
> 
> Nokia has had a 'desk stand' on their internet tablets since the N770.
> 
> In the mean time, I'm sure I can work out something using a small
> triangular piece of wood, crazy glue, a slice from my girlfriend's
> yoga mat, and velcro :)
> 
> C
> 
> ___
> devel mailing list
> de...@lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [2008.12] Mediaplayer

[Dylan Reilly]

Well, FWIW, I have both running on my system concurrently: qtopia for
the phone-kit and frameworkd for all the system level stuff.

On Tue, Jan 6, 2009 at 4:07 AM, Timo Jyrinki  wrote:
> 2009/1/6 Dylan Reilly :
>> To tell you the truth, I am not sure. I have always been running the
>> testing distribution, but 2008.12 *should* be more or less the same as
>> testing.
>
> No. There were two types of testing image, one using the 2008.12-like
> qtopia stuff and one using freesmartphone.org. 2008.12 is not using
> frameworkd, but the qtopia daemons like qpe and qtopia-x11
> messaging/dialing/etc. software.
>
> 2008.12 does not include the profile switching feature, but like said
> there are scripts for it. I simply have a python app with a few
> buttons I can use to switch between profiles for music playback
> (phone, loudspeakers, headphones).
>
> -Timo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
Dylan Maxwell Reilly

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

connect freerunner with debian to a windows-PC

[VanInwagen]

Hi, all,
is there anyone who can help me?
I've got debian installed on my freerunner and now i try to connect to a
windows xp machine.
my debian is quite naked, but in general it's the debian built by the
official script linked in the wiki, you surely know.
The rndis-windows driver has been taken from here:

http://users.informatik.uni-halle.de/~rabe/neo/Neo1973.inf

connecting the freerunner with om2008.12 installed works just fine,
with debian the driver on xp says he could not connect and gives an
error-code 10.

anyone knows whats up?

and: i know i shouldn't use windows and i should take a linux-distribution
instead. Well, i would if i could, you know? please help me!
thank you very much
-- 
View this message in context: 
http://n2.nabble.com/connect-freerunner-with-debian-to-a-windows-PC-tp2118647p2118647.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Buzz fix attempt, tomorrow

[Fox Mulder]

Yoann ARNAUD wrote:
> kimaidou a écrit :
> 
>>> Tommorow, I (my colleague, actually) will try to fix the buzz of my OM
>>> version A5 according to the manual of Joerg.
> 
> Since I was asked, here is the documentation I will use :
> 
> http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf
> 
http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP_rc2.pdf
is the newer version. Don't know what changed but DRAFT3 is the first
public version available and rc2 the latest.

Ciao,
 Rainer

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Seeling my Freerunner on Ebay

[feydreva]

Hello,

I just bought an another phone, so I am selling my Freeruner on ebay.

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MESELX:IT&item=270326829135

Starting bid is 100$, no reserve, free shipping.

Phone is like new, it always had a zack invisible shield for the full
body and for the screen.
Headset have never been used, and it comes with the pouch. (i lost the
stylus long time ago).

I can provide more picture and more info in request.
At the moment, it is loaded with the 2008.12 version of software.

Regards
Philippe



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[kimaidou]

Hi
I just tested, and it worked like a charm ! Just don't forget to chmod +x
the 2 scripts
Thanks a lot !

2009/1/6 kimaidou 

> Hi !
> thanks for your help
>
> So basically, I need 2 files :
> * one ~/bin/loop as described in your email :
>
> #!/bin/sh
> while true; do
>$1
>sleep 2
> done
>
> * And one "monitorgsm" with only the complete line (not splitted) such as:
>
> #!/bin/sh
> mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
> org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n"|tr "'" '\n'|grep
> ^\+CSQ:|cut -d, -f1|cut -d' ' -f2
>
> then I can do in the terminal :
> loop monitorgsm
>
> ?
>
>
>
>
> 2009/1/6 Timo Juhani Lindfors 
>
>> kimaidou  writes:
>>
>> > mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
>> > org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep
>> > ^\+CSQ:|cut -d, -f1|cut -d' ' -f2
>>
>> Just make sure this is a complete line and not split to multiple lines
>> as it was in your mail.
>>
>> > I think a loop must be added...
>>
>> my ~/bin/loop does
>>
>> #!/bin/sh
>> while true; do
>>$1
>>sleep 2
>> done
>>
>> so I can just "loop gsm-strength", "loop energy", "loop
>> temperature" or "loop consumption".
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[kimaidou]

Hi !
thanks for your help

So basically, I need 2 files :
* one ~/bin/loop as described in your email :

#!/bin/sh
while true; do
   $1
   sleep 2
done

* And one "monitorgsm" with only the complete line (not splitted) such as:

#!/bin/sh
mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
org.freesmartphone.GSM.Debug.DebugCommand AT+CSQ\r\n"|tr "'" '\n'|grep
^\+CSQ:|cut -d, -f1|cut -d' ' -f2

then I can do in the terminal :
loop monitorgsm

?




2009/1/6 Timo Juhani Lindfors 

> kimaidou  writes:
> > mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
> > org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep
> > ^\+CSQ:|cut -d, -f1|cut -d' ' -f2
>
> Just make sure this is a complete line and not split to multiple lines
> as it was in your mail.
>
> > I think a loop must be added...
>
> my ~/bin/loop does
>
> #!/bin/sh
> while true; do
>$1
>sleep 2
> done
>
> so I can just "loop gsm-strength", "loop energy", "loop
> temperature" or "loop consumption".
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Buzz fix attempt, tomorrow

[Yoann ARNAUD]

kimaidou a écrit :

>> Tommorow, I (my colleague, actually) will try to fix the buzz of my OM
>> version A5 according to the manual of Joerg.

Since I was asked, here is the documentation I will use :

http://people.openmoko.org/joerg/GSM_EMI_noise/big-C_rework_SOP__DRAFT3__.pdf

-- 
Yoann ARNAUD
Nantes, France.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[Timo Juhani Lindfors]

kimaidou  writes:
> mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
> org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep
> ^\+CSQ:|cut -d, -f1|cut -d' ' -f2

Just make sure this is a complete line and not split to multiple lines
as it was in your mail.

> I think a loop must be added...

my ~/bin/loop does

#!/bin/sh
while true; do
$1
sleep 2
done

so I can just "loop gsm-strength", "loop energy", "loop
temperature" or "loop consumption".

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[Olof Sjobergh]

On Tue, Jan 6, 2009 at 11:57 AM, The Rasterman Carsten Haitzler
 wrote:
> sort -f i think does it... i think...

Thanks, that seems to work.

I created a package and uploaded to
http://www.opkg.org/package_90.html for anyone who is interested. The
source is hosted at http://github.com/olofsj/swedish-illume.

> hmm interesting i was just going of german/french and portuguese on this where
> i thought i could get away with simple normalisation and a basic qwerty layout
> - with selecting the matches (Vogel/Vögel for example). making the table part
> of the dictionary does make a lot of sense of course. the dict format does 
> need
> to change to make it a lot faster and intl-char friendly. i avoided this at 
> the
> time as i'd need to efficiently encode a b-tree in the file and be able to 
> mmap
> () it efficiently and use it.

I understand it would make the dictionary format more complicated.
Maybe it could be split into 2 files, one with general configuration
data such as a normalisation table, an icon etc, and then a raw
dictionary file like there is now.

Best regards,

Olof Sjöbergh

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Report] - Buzz fix

[David Zwarg]

Greetings,

I have been following the developments of OM, and I, too would like to know
when I can expect to see GTA02 with buzz fix available commercially.  Thanks
for any updates,

z

On Tue, Jan 6, 2009 at 8:35 AM, Xavier Cremaschi wrote:

> The .pdf says this hardware fix transforms a GTA02v5 with buzz into a
> GTA02v7-equivalent (without buzz).
>
> But is the GTA02v7 currently produced and/or sold ?
>
> The wiki seems to stop at GTA02v6 (for which buzz is still a possibility).
>
> Xavier.
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[kimaidou]

Hi Timo

Thanks for your feedback on monitoring the reception quality. Is it possible
to create a script which display the number each 5 seconds, so that we can
actually see the evolution of the reception as moving the phone ?
I am no coder, so I don't know how to do it. The best would be to display
the value fullscreen in big size.

Anyone can please code this ?
Here is my very small start

#!/bin/sh
mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep
^\+CSQ:|cut -d, -f1|cut -d' ' -f2

I think a loop must be added...

Thanks anyway

Kimaidou

2009/1/6 Timo Juhani Lindfors 

> "Christ van Willegen"  writes:
> > The last few days, people have constantly complained about a loud,
> > high-pitched noise when I call them. I presume it's the 'ahrdware
> > buzz' we're talking about here.
>
> The buzz seems to be proportional to the transmit power which itself
> seems to be proportional to the reception quality I can monitor with
>
> mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device
> org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep
> ^\+CSQ:|cut -d, -f1|cut -d' ' -f2
>
> According to specs these units are
>
> # 0-113 dBm or less
> # 1-111 dBm
> # 2...30   -109... -53 dBm
> # 31   -51 dBm or greater
> # 99   not known or not detectable
>
> and when it is around 26 or more the recipient does not hear the buzz
> here anymore. Thus, to mitigate the effect I can monitor the reception
> quality during call and align myself so that the quality is as high as
> possible (just going near a window helps a lot).
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi Kieran,
+1 for your idea : a toggle fullscreen button would be a great improvement.
I still consider a transparent keyboard will be a good stuff too. By
transparent, I don't mean "you can click on the interface under" , I mean
"you can see what you are writting under the keyboard, but cannot have an
action on the things under". With you "toggle fullscreen" button, the
transparent keyboard would be an improvement.

2009/1/6 Kieran Fleming 

>
> The most interesting thing about this mockup for me is that it doesn't
> try to make the rest of the UI usable. It reminds me of this keyboard:
> http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png
> Where the entire screen is a keyboard.
> Perhaps a good way to get this idea working would be to have a
> fullscreen button on the existing keyboard so you can toggle it when you
> want to.
>
> Kieran Fleming
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Buzz fix attempt, tomorrow

[kimaidou]

Hi
Oh yes, please take pictures and give feedback to help people understand the
process and evaluate its feasibility. Thanks in advance :D

2009/1/6 Yoann ARNAUD 

> Hello Community,
>
> Tommorow, I (my colleague, actually) will try to fix the buzz of my OM
> version A5 according to the manual of Joerg.
>
> If any of you have some last minute advice to give me, I take :)
>
> I can take pictures and make a report of my experience if you think
> that's necessary. I don't know so just tell me.
>
> Bye.
>
> --
> Yoann ARNAUD
> Nantes, France.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Questions and Answers

[The Rasterman]

On Sat, 03 Jan 2009 02:13:45 +0100 "Marco Trevisan (Treviño)" 
babbled:

> > Let me give everyone a bit more background into the keypad issue. We
> > first saw the Qtopia predictive keypad back in February of 2008, and
> > became extremely exited. This keypad, we believed, had the potential to
> > become better than anything on the market.
> 
> Yes, it was...
> 
> > We asked Raster to integrate this keypad into Om 2008 and extend it to
> > make it more hacker friendly (i.e., usable from places like the
> > terminal). After two months of more or less silence he showed us his own
> > version, written from scratch. The design was a work in progress. And 
> > the dictionary was far inferior to what Qtopia had already. An internal 
> > battle started that lasted until one month before Om 2008 was set to be 
> > released when our product manager, Will Lai, couldn't take it anymore. 
> > He asked another engineer to just get the Qtopia keypad working.
> 
> Ok, I understand this. But, why have you asked Raster to improve a thing
> (like qtopia-x11) that should have been only a kind of placeholder?
> Wasn't it considered in a such way at that time? I always thought that
> the future of Openmoko was going to reach the Framework, and also if
> qtopia could be adapted to use it, we all know that its performances
> under X aren't the ones that we can bear.
> 
> > At that point Raster's keypad was getting stable. It had many new
> > features. But basic text entry was still not as good as Qtopia's. Major
> > parts of Om 2008, in the meantime, were still not finished (like the
> > Glamo or network manager).
> > 
> > Openmoko (the company) needs to focus on simplifying. We need to limit
> > ourselves to building what doesn't already exist. We cannot constantly
> > try to build better components from scratch. Our resources are just too
> > limited for that. Openmoko is trying to repackage the essentials (just
> > enough) to make people feel inspired. What's not there is often times
> > more inspiring than what is there.
> >
> > I emailed Raster, the other day, asking if my current perspective 
> > corresponds with his. The main motivation for writing a new keypad from 
> > scratch, he said, had to do with his ability to (easily) extend Qtopia's 
> > code. C++ and qt were not familiar to him. And he wanted something with 
> > more configuration options. To get there with Qtopia, he thought, would 
> > take more time then writing a new one from scratch.
> 
> So reading this I only think that what Raster said was not only true
> about the implementation difficulties, but also about the fact that at
> that time we needed something that should have survived to Om2008. The
> keyboard he wrote is actually what the future seems to reserve to us and
> also if it has some issues with accented words (maybe fixed in svn
> r38274?!?) and it performs worse with big dictionaries than the Qtopia
> predictive, I figure that he did the right move.
> 
> So maybe what happened wasn't in the spirit of the "backs to the
> basics", but he lead us the best input method available today.

since what i wrote really got distilled down and lost a lot of details and info
- i'll quote myself here on the keyboard issue:


"ok - here's my take:

looked at qtopia keyboard code. it's c++ and qt - not too familiar with qt but
readable. looked at code (very much qt/qws centric) and its all integrated into
the 1 big qpe process. it has no ability to change layout from config nor
anything to support using a terminal. we also will depend on a external app
that does phone handling for the most rudimentary of things. while it worked
well for english text input ONCe you learnt how to use it (someone told you the
tricks) it lacked: ease of discoverability (how do i enter space? how do i
type the return key? where are numbers? what happened to ctrl and alt? how do i
do backspace? etc.) there were a list of ui issues that i knew would be top of
the complaints list - they were already on the top of mine. now figuring the
work needed to add all of this and fix it vs. re-implementing - i chose to
re-implement given all the above concerns (it only took about 3 weeks for the
first cut - i was busy doing all sorts of other things at the same time, not
just keyboard).

so the work to fix it vs. the code to re-implement with all the other bits
"done better". i chose the latter as i saw it as a faster way to get to thew
right solution. in the end qtopia was meant to be a TEMPORARY solution until
FSO was done - and thus there would need to be a new keyboard implemented
anyway later so work would be duplicated probably by the same person - me. so
instead of doing it twice - did it once. there were enough other unsolved
problems at the time - like "how do i request a keyboard as an app properly?
(the matchbox protocol had holes you can drive a truck through to cause
problems so i ended up implementing that for compatibility, but also a newer
protocol involving properties). als

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Fox Mulder]

Paul Fertser wrote:
> Hi,
> 
> Fox Mulder  writes:
>>> Actually, you can try to change from 2.6.24 after applying an ad-hoc
>>> patch from http://trac.freesmartphone.org/ticket/293 even on old
>>> version that's provided by Debian (that's exactly what i did a month ago).
>>>
>> Ok.
>> I downloaded the fso-frameworkd source, copied the patch into it and
>> applied it without any problems. Now do i install the fso-frameworkd
>> with "./setup.py install" ?
> 
> That's distribution-dependent. I'd suggest to apply the patch to the
> frameworkd you have already installed and change
> /etc/freesmartphone/oevents/rules.yaml by hand.
> 
> Or if you want to try to install from source, you probably don't need
> any patches at all, as you can install a version recent enough (though
> it's possible that some SHR apps are not ready yet).
> 
>> But i have the problem that on [1] only the 2.6.28 kernel but no modules
>> are online. Where do i get the corresponsing modules for this kernel?
>> Last time i checked there was an older kernel with a modules package but
>> no more.
> 
> I think it's assumed that everything you need for everyday work is
> compiled-in. If you want to use some webcams or other unusual devices,
> just compile a kernel yourself from git, it's not hard. Or ask Andy to
> provide all the modules ;)
> 
I don't think that all modules are compiled in because the current
kernel is only 896K in size. And the OM kernels are ~1,7M.
I already though about compiling the freerunner kernel myself having a
bit knowledge about normal pc linux kernel compilation.
But for this i have to set up cross compile what i never did before. So
first i have to find a good how-to which describes how i fetch the
kernel with git (never used it) and how to cross compile it for my
freerunner on my pc.
It would be much easier if i got a working kernel and modules. Maybe
andy has a bit spare time to update his website. Else i have to jump in
the cold water and do this on my own. :/

Ciao,
 Rainer

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FSO/Illume] Program icons not showing up

[Ingvaldur Sigurjonsson]

Helge Hafting wrote:
> Michael 'Mickey' Lauer wrote:
>> This always happens when we're starting to stabilize for a release. Last 
>> time 
>> it was something with a missing mimetypes postinst. Raster, any idea what it 
>> can be this time?
>>
> There is definitely a problem with whatever parses the .desktop files.
> Try installing a third party app like openmoocow.
> You get no icon, although the icon file exists.
> Then, remove openmoocow.desktop and recreate it. Use some other
> .desktop file as a template, and enter the correct filename,
> name and icon name. Then you get an icon.
> 
> a problem with "categories" will certainly make an icon disappear,
> but that is not the only way. Enter the options in a different
> order or omit something else, and it may still fail.
> 
> I haven't researched _exactly_ what works, so far I have concentrated
> on making the icons show up when they doesn't.
> 
> Helge Hafting

The problem went away when a new build of e-wm was available i.e.
   'e-wm - 0.16.999.050+svnr38352-r0'

Which build of e-wm do you have ?

Also in previous version of e-wm - *+svnr37988* changing the 'Display 
Type' from 'Icons -> Slider' in 'Illume: Wrench->Launcher' displayed the 
various icons, very strected that is...

- Ingi


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[Pander]

Pander wrote:
...
> However it would be desirable that each .kbd file can indicate:
> - predictive mode is not possible, e.g. for numeric keyboards. I don't
> want it to remember my PIN, credit card number, etcetera. (numeric
> keyboard, a real one, without the é, ë, ..)
> - predictive mode is default on, but user can temporarily disable it,
> e.g. when going into a shell (alpha keyboard)
> - predictive mode is defaul off, but user can temporarily enable it,
> e.g. when typing proza inside a shell (terminal keyboard)
>
>
>
>>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

I think the functionality described above is already partly implemented for:
- type NUMERIC
- type ALPHA
- type TERMINAL
settings in the .kbd file. But what behaviour is exactly enabled by the
above types?

Could TERMINAL and NUMERIC by default also be non-predictive?

It is not clear for me from
http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd.c
and
http://trac.enlightenment.org/e/browser/trunk/e/src/modules/illume/e_kbd_int.c
what effect it has on predictive mode. Also There are many more modes
available like HEX, PASSWORD etc.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FSO/SHR/Debian] Update to BtGPS.py

[Angus Ainslie]

I'll try to put an opkg together today.

Anyone talented with the gimp feel like making an icon for it ?

Angus
-- 
Angus Ainslie
http://www.handheldshell.com/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[Pander]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 6 Jan 2009 11:49:55 +0100 "Olof Sjobergh"  babbled:
> 
>> Hi,
>>
>> I'm working on a Swedish dictionary and keyboard for Illume, but I'm
>> having some trouble with sorting of utf8 chars in the dictionary. I
>> can't seem to get the sorting right. Looking at the code, Illume sorts
>> the dictionary after first normalizing the strings according to the
>> internal normalization table. Is there any way to reproduce this
>> sorting with the sort command? I've tried with a few different locales
>> (C, en_US.utf8) which all make the unix sort command work differently.
>> But no matter what I try words don't show up correctly.
> 
> sort -f i think does it... i think...
> 
>> Another issue I found is that the built in normalization table is not
>> very good for typing Swedish text. On a standard Swedish qwerty
>> layout, we have three additional letters (å, ä and ö). These are used
>> very frequently in Swedish and there are many common words that have
>> different meanings if spellt with a, å or ä (for example har, här and
>> hår are all very common words). But in Illume these are all normalized
>> to a. Writing Swedish with a US qwerty layout and then having to
>> select aåä manually after the dictionary lookup is a pain, since many
>> common words will have to be selected from the lookup list each time.
>>
>> Instead, what you want is a Swedish qwerty layout (which is very
>> simple to implement as a .kbd file), and not normalize åäö for the
>> Swedish dictionary lookup. So the normalization table would really
>> need to be configurable, either as a part of the dictionary or the
>> .kbd file. I suppose this problem exists for other languages as well.
>> If I were to work on such a change, what would be the best approach?
> 
> hmm interesting i was just going of german/french and portuguese on this where
> i thought i could get away with simple normalisation and a basic qwerty layout
> - with selecting the matches (Vogel/Vögel for example). making the table part
> of the dictionary does make a lot of sense of course. the dict format does 
> need
> to change to make it a lot faster and intl-char friendly. i avoided this at 
> the
> time as i'd need to efficiently encode a b-tree in the file and be able to 
> mmap
> () it efficiently and use it.

Mapping of cafe to café (French) and Vogel to Vögel (German) is indeed
handy, this funcitonality would be handy internationally for most languages.

What about mapping Koeln to Köln etcetera? This would be handy for
German only. Like the above story is (maybe) specific for Swedish.

Perhaps an optional config file can be provided for the dictionaries
that need one. Keeping this info outside the dict itself eases sorting
of the dict and upgrading dicts. I would keep this optional config
surely independent of the .kbd keyboard configs.

Raster, the dicts I'm making for Dutch will be a large version (250.000
words) and a small version. Do you have an indication how many words is
advisable for the small version?

However it would be desirable that each .kbd file can indicate:
- predictive mode is not possible, e.g. for numeric keyboards. I don't
want it to remember my PIN, credit card number, etcetera. (numeric
keyboard, a real one, without the é, ë, ..)
- predictive mode is default on, but user can temporarily disable it,
e.g. when going into a shell (alpha keyboard)
- predictive mode is defaul off, but user can temporarily enable it,
e.g. when typing proza inside a shell (terminal keyboard)



> 
> 


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hardware buzz - can OpenMoko help?

[Timo Juhani Lindfors]

"Christ van Willegen"  writes:
> The last few days, people have constantly complained about a loud,
> high-pitched noise when I call them. I presume it's the 'ahrdware
> buzz' we're talking about here.

The buzz seems to be proportional to the transmit power which itself
seems to be proportional to the reception quality I can monitor with

mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device 
org.freesmartphone.GSM.Debug.DebugCommand "AT+CSQ\r\n"|tr "'" '\n'|grep 
^\+CSQ:|cut -d, -f1|cut -d' ' -f2

According to specs these units are

# 0-113 dBm or less
# 1-111 dBm
# 2...30   -109... -53 dBm
# 31   -51 dBm or greater
# 99   not known or not detectable

and when it is around 26 or more the recipient does not hear the buzz
here anymore. Thus, to mitigate the effect I can monitor the reception
quality during call and align myself so that the quality is as high as
possible (just going near a window helps a lot).


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Mathieu Rochette]

Laszlo KREKACS wrote:
> Hi!
>
>>> First and foremost, it is us
>>> hackers that use this device for now and are supposed to make apps for
>>> freerunner and all, and we don't have a damn keyboard;). All this
>>> fancy pancy dictionary based guessing is maybe good for normal people
>>> writing crappy SMS messages, but not for the current user base, in my
>>> opinion.
>> you do - Terminal.kbd layout - it ships with illume. i designed the kbd 
>> engine
>> in illume to allow for straight-through pushing of key presses without a dict
>> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
>> opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
>> change it yourself! its just text!
>
> Im planning to develop an application, where is a table, and in each column
> I want different keyboard layout with different dictionary.
>
> Is it possible to change layout and dictionary on the fly? (ie.
> entering in another text input field).
>
> The application would be something, in the first column is only
> numbers, so I want a keyboard
> with [0..9-.] buttons, and accept only numbers. In the second column I
> want to write down what I see (microwave, lamp, soldering iron, etc)
> and in the third column I want to write the trademark of it (sony,
> samsung, philips, weller, etc) so I want to change the keyboard
> between
> numeric and qwerty, and I want to change the dictionary as of input text 
> field.
>
> Is it doable? If so where to start? I know python, and would be glad
> to see some debian/ubuntu guide how to start programming in efl. (or
> is it a complete development virtualbox/qemu image? it was discussions
> about some time ago).

this is be doable. keyboard application can receive message for client,
message type is ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_STATE
and message data is one of:
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_OFF
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_ON
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_ALPHA
  - ECORE_X_ATOM_E_VIRTUAL_KEYBOARD_NUMERIC
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PIN
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PHONE_NUMBER
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_HEX
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_TERMINAL
  - ECORE_X_VIRTUAL_KEYBOARD_STATE_PASSWORD

(I don't know where this list came from, is there some specification or 
recommendation for virtual keyboard application implementation?)

so, the application just have to send one of those messages when 
entering a field or another.

Mathieu.
>
> Thank you in advance.
>
> Laszlo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Hardware buzz - can OpenMoko help?

[Christ van Willegen]

To whom this may concern...

I've been using my FreeRunner for some time now, and although some
points keep irking me (esp. sound and accelerometers after
suspend/resume), it's more and more a daily phone. Except for the
buzz.

The last few days, people have constantly complained about a loud,
high-pitched noise when I call them. I presume it's the 'ahrdware
buzz' we're talking about here.

I am unable to do the hardware fix for this, myself, and I find it
troublesome to go somewhere and get my (still expensive!) phone
'fixed'.

I'd rather have an OpenMoko (or FIC) engineer fix this for me, but
shipping would be prohibitively expensive, I guess.

Here's a thought... on Februari 7th and 8th there will be the Fosdem
event, in Brussels, Belgium. Would it be possible to send someone over
with an SMD soldering iron, a boatload of capacitors and other stuff
needed to do the SD-card cap and buzz cap fix? I'd gladly pay a couple
of euro's (10? 20?) to get this fixed in a way that I know it will be
done correctly.

If enough geeks show up with their phones, paying 10 or 20 euro... I
have no idea how many phones were sold in Europe, and how much time it
takes to do the fix, so I can't calculate costs vs. money, but perhaps
this would be a way to help us users from 'far away'.

Thoughts?

Christ van Willegen
-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Buzz fix attempt, tomorrow

[Yoann ARNAUD]

Hello Community,

Tommorow, I (my colleague, actually) will try to fix the buzz of my OM
version A5 according to the manual of Joerg.

If any of you have some last minute advice to give me, I take :)

I can take pictures and make a report of my experience if you think
that's necessary. I don't know so just tell me.

Bye.

-- 
Yoann ARNAUD
Nantes, France.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Paul Fertser]

Hi,

Fox Mulder  writes:
>> Actually, you can try to change from 2.6.24 after applying an ad-hoc
>> patch from http://trac.freesmartphone.org/ticket/293 even on old
>> version that's provided by Debian (that's exactly what i did a month ago).
>> 
> Ok.
> I downloaded the fso-frameworkd source, copied the patch into it and
> applied it without any problems. Now do i install the fso-frameworkd
> with "./setup.py install" ?

That's distribution-dependent. I'd suggest to apply the patch to the
frameworkd you have already installed and change
/etc/freesmartphone/oevents/rules.yaml by hand.

Or if you want to try to install from source, you probably don't need
any patches at all, as you can install a version recent enough (though
it's possible that some SHR apps are not ready yet).

> But i have the problem that on [1] only the 2.6.28 kernel but no modules
> are online. Where do i get the corresponsing modules for this kernel?
> Last time i checked there was an older kernel with a modules package but
> no more.

I think it's assumed that everything you need for everyday work is
compiled-in. If you want to use some webcams or other unusual devices,
just compile a kernel yourself from git, it's not hard. Or ask Andy to
provide all the modules ;)

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Report] - Buzz fix

[Xavier Cremaschi]

The .pdf says this hardware fix transforms a GTA02v5 with buzz into a 
GTA02v7-equivalent (without buzz).

But is the GTA02v7 currently produced and/or sold ?

The wiki seems to stop at GTA02v6 (for which buzz is still a possibility).

Xavier.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Fox Mulder]

Paul Fertser wrote:
> Hi,
> 
> Fox Mulder  writes:
>> Paul Fertser wrote:
>>> Sander van Grieken  writes:
> So the question is, when will the default kernel be replaced by the new
> 2.6.28 andy kernel so that userspace tools could be adapted to it?
 That would be my question as well. 

 I only care for userspace to be adapted to test the suspend/resume 
 functionality (on FSO, only frameworkd?).
>>> frameworkd newer than 31 Dec should properly support both kernels. I'm
>>> afraid it's not included in any images yet (please correct me if i am 
>>> wrong).
>> Latest fso-frameworkd in debian is 0.8.4.3-20081215-1 which is older
>> than 31 dec i would guess.
>> I hope a new version comes very soon so i can try to change from 2.6.24
>> to the new 2.6.28 kernel. :)
> 
> Actually, you can try to change from 2.6.24 after applying an ad-hoc
> patch from http://trac.freesmartphone.org/ticket/293 even on old
> version that's provided by Debian (that's exactly what i did a month ago).
> 
Ok.
I downloaded the fso-frameworkd source, copied the patch into it and
applied it without any problems. Now do i install the fso-frameworkd
with "./setup.py install" ?
But i have the problem that on [1] only the 2.6.28 kernel but no modules
are online. Where do i get the corresponsing modules for this kernel?
Last time i checked there was an older kernel with a modules package but
no more.


Ciao,
 Rainer

[1] http://people.openmoko.org/andy/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Marc Bantle]

Carsten Haitzler (The Rasterman) schrieb:
>>> ok. let me draw u a keyboard (or part of it):
>>>
>>>   q w e r t y u i o p
>>>a s d f g h j k l
>>> z x c v b n m
>>>   
>> Excellent! Better than any info currently on the WIKI (I could only find
>> reference to the qtopia keyboard and it's usage). Would you mind if I or
>> somebody else put this into the WIKI?
>> 
>
> someone just did... leonardo:
>
> http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - 
> feel
> free to just copy and paste it out or re-type/edit/whatever as i said at the
> bottom - throw it up on the wiki :) i'm just here to spew forth mindless 
> babble
> about what i know of the internals of code i wrote. :) you guys can make it
> into some usable document! that's teamwork! i babble incoherently. you guys
> make it coherent :)
>   
And please don't miss to merge and link it with [1] to avoid redundancy 
or conflicts.

Thanks, Marc


[1] 
http://wiki.openmoko.org/wiki/Illume#How_to_use_.28Raster.27s.29_keyboard_.3F

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Kieran Fleming]

On Tue, 2009-01-06 at 01:51 +0100, Pascal d'Hermilly wrote:
> With 2008.12 release, a well working finger-friendly keyboard is the 
> most critical missing feature for me.
> I've made a mockup of a keyboard that I think would make things a lot 
> easier to type.
> http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> 
> I don't have the skills to code this, but please. I really need a good 
> keyboard to be able to use my openmoko.
> 
> Best regards from Pascal, Denmark
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

The most interesting thing about this mockup for me is that it doesn't
try to make the rest of the UI usable. It reminds me of this keyboard:
http://www.spbsoftwarehouse.com/products/keyboard/screenshots/100.png
Where the entire screen is a keyboard.
Perhaps a good way to get this idea working would be to have a
fullscreen button on the existing keyboard so you can toggle it when you
want to.

Kieran Fleming


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Laszlo KREKACS]

Hi!

>> First and foremost, it is us
>> hackers that use this device for now and are supposed to make apps for
>> freerunner and all, and we don't have a damn keyboard;). All this
>> fancy pancy dictionary based guessing is maybe good for normal people
>> writing crappy SMS messages, but not for the current user base, in my
>> opinion.
>
> you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
> in illume to allow for straight-through pushing of key presses without a dict
> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
> opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
> change it yourself! its just text!

Im planning to develop an application, where is a table, and in each column
I want different keyboard layout with different dictionary.

Is it possible to change layout and dictionary on the fly? (ie.
entering in another text input field).

The application would be something, in the first column is only
numbers, so I want a keyboard
with [0..9-.] buttons, and accept only numbers. In the second column I
want to write down what I see (microwave, lamp, soldering iron, etc)
and in the third column I want to write the trademark of it (sony,
samsung, philips, weller, etc) so I want to change the keyboard
between
numeric and qwerty, and I want to change the dictionary as of input text field.

Is it doable? If so where to start? I know python, and would be glad
to see some debian/ubuntu guide how to start programming in efl. (or
is it a complete development virtualbox/qemu image? it was discussions
about some time ago).

Thank you in advance.

Laszlo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 12:28:09 - (UTC) "Jan Henkins" 
babbled:

> Hello Raster,
> 
> 
> On Tue, January 6, 2009 09:56, Carsten Haitzler wrote:
> 
> > ok. let me draw u a keyboard (or part of it):
> >
> >   q w e r t y u i o p
> >a s d f g h j k l
> > z x c v b n m
> 
> 
> Excellent! Better than any info currently on the WIKI (I could only find
> reference to the qtopia keyboard and it's usage). Would you mind if I or
> somebody else put this into the WIKI?

someone just did... leonardo:

http://wiki.openmoko.org/wiki/Illume_keyboard (well he put a link to it) - feel
free to just copy and paste it out or re-type/edit/whatever as i said at the
bottom - throw it up on the wiki :) i'm just here to spew forth mindless babble
about what i know of the internals of code i wrote. :) you guys can make it
into some usable document! that's teamwork! i babble incoherently. you guys
make it coherent :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Jan Henkins]

Hello Raster,


On Tue, January 6, 2009 09:56, Carsten Haitzler wrote:

> ok. let me draw u a keyboard (or part of it):
>
>   q w e r t y u i o p
>a s d f g h j k l
> z x c v b n m


Excellent! Better than any info currently on the WIKI (I could only find
reference to the qtopia keyboard and it's usage). Would you mind if I or
somebody else put this into the WIKI?

-- 
Regards,
Jan Henkins


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Alberto Morales]

El Martes, 6 de Enero de 2009, Carsten Haitzler escribió:
> [...] my bet is more people are more proficient at qwerty than
> at abcdefgh... (those really proficient at abcdefgh are ALSO likely
> to be really good at qwerty too - the teenagers and young people
> totally addicted to smsing eachother on their phones probably also
> are pretty good at tapping away on their instant messengers on their
> laptops/desktops - but thats just my bet on the audience).

I agree. I feel better with something like this... but using two 
fingers.

[ q w e ]  [ r t ]  [ y u ]  [ i o p ]
[ a s d ]  [ f g ]  [ h j ]  [ k l ; ]
[ z x c ]  [ v b ]  [ n m ]  [ , . / ]
   [space ]  

This one is quicker than previous, but the number of dictionary 
suggestions has to be studied.

[ q w e r t ]  [ y u i o p ]
[ a s d f g ]  [ h j k l ; ]
[ z x c v b ]  [ n m , . / ]
  [space ]

For example, the word "house"... not too bad results.

$ egrep "^[hjkl;][yuiop][yuiop][asdfg][qwert]$" 
/usr/share/dict/american-english 
hoist
house
joist
joust
loose
louse

Perhaps this one would be better for one finger only:

[ q w e ]  [ r t y u ]  [ i o p ]
[ a s d ]  [ f g h j ]  [ k l ; ]
[ z x c ]  [ v b n m ]  [ , . / ]
[space ]  

$ egrep "^[fghj][iop][rtyu][asd][qwe]$" /usr/share/dict/american-english 
gorse
horde
horse
house

-- 

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Offer to write some neat programs for the Freerunner

[Timo Juhani Lindfors]

"Sargun Dhillon"  writes:
> IMAP IDLE is not a push mechanism... SMS is a push mechanism.
> Something that doesn't require the FR to be out of suspend mode before

You can be in suspend with GPRS connected. The only trouble is that
port scanners will wake up your phone all the time.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FSO/SHR/Debian] Update to BtGPS.py

[kimaidou]

If you suggest me to enter the application in opkg, i will say why not, but
I think the author is the best person to do it. This way he can give the
link to website, better explain the app, and give a link to an .ipk file
instead of a python file if he wants to. Not having yet the knowledge for
creating a package, I cannot do it. But I got your point, and I think you
are right.

2009/1/6 Minh Ha Duong 

> Le mardi 06 janvier 2009, kimaidou a écrit :
> > Hi Angus
> > What about putting this app on the opkg.org website, so people would
> easily
> > find it ?
> > Thanks anyway for sharing your work
>
>   I would like to kindly share my recent experience with opkg.org.
> Entering or
> updating an application page is really simple. Just fill a form with half a
> dozen fields. Anybody can do it, it does not need to be done by the author.
> I
> recon it is not as simple as writing an email to ask someone else to do it,
> but almost ;) ...
>
> Yours,
> Minh
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 12:46:41 +0100 kimaidou  babbled:

> SorrI just sent it to fast: here is the end of my message :
> 
> 2009/1/6 kimaidou 
> 
> > Hi
> >
> > I like the idea to create a new layout with the well known phone
> > arrangement :
> > [] [abc] [def]
> > [ghi] [jkl] [mno]
> > [pqrs] [tuv] [wxyz]
> 
> 
> Do you think it will help to type faster with illume keyboard ?

no. as its the same # of keys - same letters, simply laid out differently.
those used to phone keypads who like them much more than qwerty may prefer it -
those used to qwerty will do nothing but swear and curse. my bet is more people
are more proficient at qwerty than at abcdefgh... (those really proficient at
abcdefgh are ALSO likely to be really good at qwerty too - the teenagers and
young people totally addicted to smsing eachother on their phones probably
also are pretty good at tapping away on their instant messengers on their
laptops/desktops - but thats just my bet on the audience).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

SorrI just sent it to fast: here is the end of my message :

2009/1/6 kimaidou 

> Hi
>
> I like the idea to create a new layout with the well known phone
> arrangement :
> [] [abc] [def]
> [ghi] [jkl] [mno]
> [pqrs] [tuv] [wxyz]


Do you think it will help to type faster with illume keyboard ?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Hi

I like the idea to create a new layout with the well known phone arrangement
:
[] [abc] [def]
[ghi] [jkl] [mno]
[pqrs]
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 12:34:28 +0100 "leona...@lilik.it" 
babbled:

> 
> Hi Raster,
> thanks for the explanation.
> 
> > anyway. i hope this helps people understand how it works. someone can throw
> > this onto the wiki if they like. this is the code i wrote for the illume kbd
> 
> I've summarized this in a page:
> 
> http://wiki.openmoko.org/wiki/Illume_keyboard
> 
> it's cool, you should really patent it!
> :-)))

i'd rather not. 1. trollt.. err.. nokia deserve thanks for the core inspiration
and initial work on their one - i didn't know how the code worked until later
but i nutted out how it probably should work just by poking at it. so if anyone
deserves a patent - it's them. 2. i'd rather this be well publicised and "out
there" code in the public eye - so the idea is widespread and well known - thus
serves as prior art pretty much making it impossible for someone to come along
and patent the idea and make things a pain. get the ideas out there in code -
in the public eye with a trail of history so it's available for everyone to see
and use. if someone implements a better kbd but steals the same idea - i'm
sticking my thumbs up going "good on-ya mate!" i want users and the community
to benefit. 3. i fundamentally disagree with software patents - or at least the
way they have been implemented. the vast majority i have seen are neither novel
nor "non-obvious to someone skilled in the art". most are incredibly mundane
straightforward things to "someone skilled in the art" and the system has been
abused to further greed and misplace credit in the hands of those with more
lawyers, not those who innovate the most or the best. be that as it may - the
system is there and we are stuck with it. i'm not a crusader trying to bring it
down - i don't have the time. got code to write and ideas to make happen :) but
i hope in my little way i can shake my fist at the system and go "here... prior
art. take that!". i'll let others fight the good fight in trying to reform the
patent system. i'm just rattling my chains and moaning in my corner...
'brains! brains! braiins! need moore brains!' :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Default IP Address on All Distributions

[Thomas Otterbein]

Hi Helge,

I largely agree with you. Yes of course every needs to be widely configurable. 
To me the phone be able to be confiured to a range starting from fixed IP and 
just sitting there waiting for it's masters orders to booking automatically 
into known WLANs and downloading updates without any user interaction. Between 
these two extremes there are numerous layers of asking for 
permission/confirmation, just notifying me of something, etc., which of course 
should also be configurable.

Probably a standard for "convenience levels" would help to describe what the 
phone should do or not do. Or usage scenarios like "I'm just a user on 
holiday, trying to find the next free wifi hotspot" or "I'm the companies 
administrator and believe me I know what I'm doing". Applications or the phone 
as such could adhere to this and behave appropriate.

Regards
  thomas

On Tuesday 06 January 2009 12:03 Helge Hafting wrote:
> Thomas Otterbein wrote:
> > Now when it comes to "real users" I believe the discussion about the best
> > fixed IP-Number or a pool of dynamic numbers is far too short-sighted. As
> > a true linux user by hard for many year now I have no problem in running
> > a couple of commands to connect my Freerunner to my machine and configure
> > it's internet connection to get some updates. However on the long run, if
> > I will have to continue doing it like that I consider it a confession of
> > failure.
>
> Sure. The default should "just work". And there should be
> configurability for those with different needs. Such as updating 30
> company phones all connected to the same usb hub...
>
> > M$ and Apple are successful with their devices because users do not have
> > to care at all about IP-Numbers or editing /etc/resolv.conf. Neither do
> > today's
>
> And they "fail" because you usually can't do anything out of the
> ordinary. Connect just one phone to the PC at a time, please. Connect
> two phones to each other with a usb cable? Why would anyone want that?
> A networked phone game that doesn't need to call into one of our servers
> - where is the money in that . . .
>
> > Linux-Users as the vast majority is using DHCP on their
> > DSL-(WiFi)-Routers They plug it in or move into a certain location and
> > things just happen as expected.
> >
> > Believe me I don't like the side effects that come with all this
> > automatisms, which is why I bought the freerunner so I have the freedom
> > to change it. However as I sit in front of my desktop day by day already
> > strangling with a more or less constant level of "configuration problems"
> > (network gone, faulty acpi, xorg update broke screen resolution, etc.). I
> > would really love to have my phone "just work" sometime in the relatively
> > near future.
>
> I agree that it should "just work" as far as possible. And the expert
> user can always make changes precisely because this is linux.
>
> Still, the way to "just works" is to use existing standards as
> much as possible. A fixed IP address is a last resort. Use that only if
> we have to. If this phone (or the next one) makes it to mass markets,
> then there will be families with several phones. It may be convenient
> to charge & update them at the same time from the same PC. Your friend
> with the same phone might visit. You may want to surf the net at the
> same time. It'd be nice if all this "just works" too,
> and it won't when all phones share a fixed address.
>
> Running DHCP on the PC's usb interface is one way to make this case
> "just work". Combining link-local addresses with NAT is perhaps another
> way. A fixed address won't do the trick.
>
> Either way, some software has to be set up on the PC. But that is OK,
> even windows people are used to installing a "driver CD" in order
> to connect their new phone to the computer. If this software then
> allows plugging in all your phones at the same time, so much the better!
>
> > For example a user friendly but still linux-like phone could ask me:
> > "Hey, while you already have decided to go on the internet (via usb or
> > wifi or gprs, it's my decision and not limited by design flaws) shouldn't
> > I download the latest updates in the background?"
> > or
> > "Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly
> > sync your appointments and contacts with your favourite OpenSync-enabled
> > PIM-Suite (or even with nasty Outlook)?"
>
> Do this or don't do this. Make it a setup option.
> But please - don't pop up questions! Questions
> that pop up while I use the phone gets in my way - yuk. Questions
> that pop up while the phone is in my pocket just wastes CPU effort
> and drains the battery. And it is particularly nasty if I pull the
> phone out of my pocket to make a call, and have to wade through
> 2-3 items that popped up since the last use - items that may even be
> irrelevant now that I have moved around.
>
> With SHR I already get one such popup - the one that suggests charging
> the nearly empty battery. The warn

Re: Openmoko keyboard mockup

[leona...@lilik.it]

Hi Raster,
thanks for the explanation.

> anyway. i hope this helps people understand how it works. someone can throw
> this onto the wiki if they like. this is the code i wrote for the illume kbd

I've summarized this in a page:

http://wiki.openmoko.org/wiki/Illume_keyboard

it's cool, you should really patent it!
:-)))

ciao,
leonardo.

-- 
http://leonardo.lilik.it
Key fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMooCow 0.3

[Helge Hafting]

Thomas White wrote:
> Helge Hafting  wrote:
> 
>> My SHR is "unable to open audio". But the older moocow worked with
>> the same setup.  I can stop speech-dispatcher, but it doesn't help.
>> There is no snd-pcm-oss module to load, bt the previous moocow didn't
>> need that.
> 
> Previous meaning version 0.2?  All the previous versions are available
> from my site:
> http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/
> - would you be able to check version 0.2 again to be sure?  This is
> particularly puzzling because the audio parts of the program haven't
> been touched between 0.2 and 0.3...

Strange. I must have done something wrong, this time both
version 0.2-r2 and version 0.3 moos, as soon as I stop
speech-dispatcher.

The accelerometers don't work though. hexdump /dev/input/event2
gets me changing output as I turn the phone around. event3 is
dead, perhaps that is the problem?

I have a 2.6.24 kernel, as SHR doen't work well with 2.6.28 yet.

Helge Hafting

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:53:37 +0100 Mathieu Rochette  babbled:

> Shashank Bharadwaj wrote:
> > On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler
> > mailto:ras...@rasterman.com>> wrote:
> >
> > On Tue, 06 Jan 2009 02:46:15 + Jan Henkins  > > babbled:
> >
> >  > Hello there,
> >  >
> >  > Pascal d'Hermilly wrote:
> >  > > With 2008.12 release, a well working finger-friendly keyboard
> > is the
> >  > > most critical missing feature for me.
> >  > > I've made a mockup of a keyboard that I think would make things
> > a lot
> >  > > easier to type.
> >  > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
> >
> >
> > I think, the current Raster's Keyboard great for potrait mode. For
> > landscape mode(i.e holding neo sideways) however, the keyboard does not
> > utilize the extra space. What we need is, imho, a keyboard that would
> > increase in size to take up the extra space in this landscape mode. That
> > way we'll be able to type even faster. If we could add that fuctionality
> > to raster's keyboard, then it'd be just great.
> >
> if you start the keyboard in landscape mode, it does utilize all 
> available place and it's great :)
> (in keyboard settings, just select non and then default while in 
> landscape mode)
> 
> Another thing, I can't test it from office, but, is it possible to have 
> multiple at the same position, if so one could make a t9 "like" layout
> just put, abc on the same position, def, on another, etc.
> would that be possible?

no it's not possible as they'd overlap and you'd not see the ones underneath -
BUT you could do just as well with:

[...@][!][?][.] [ a][ b][ c] [ d][ e][ f]

[ g][ h][ i] [ j][ k][ l] [ m][ n][ o]

[p][q][r][s] [ t][ u][ v] [w][x][y][z]

[ *  ][] [ +  ][ .  ] [ #  ][ &  ] 

(make it a bit taller). :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 23:55:13 +1300 "Robin Paulson" 
babbled:

> 2009/1/6 The Rasterman Carsten Haitzler :
> > you do - Terminal.kbd layout - it ships with illume. i designed the kbd
> > engine in illume to allow for straight-through pushing of key presses
> > without a dict int he way. the Terminal.kbd bypasses dict lookup by just
> > emitting keysyms as
> 
> following on from this, would a hybrid of the two (the terminal kb no
> guesses, and the dictionary lookup kb) be possible? it can be very
> frustrating to think a long word will be in the dictionary, type it,
> find it's not in the dictionary, and have to delete it, switch to the
> terminal kb and type it again.
> 
> when the list of possible words comes up, it would be very useful to
> have the kb give the exact sequence of letters, as typed, as one
> option, alongside the dictionary guesses

hold and press -to zoom and select keys. once in the dict - its in. and yes its
possible to make a version of the basic (Default) qwerty that doesnt use the
dict - just do a .kbd file- look at the terminal and default kbd files and work
it out - its easy to figure that one out :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Default IP Address on All Distributions

[Helge Hafting]

Thomas Otterbein wrote:

> Now when it comes to "real users" I believe the discussion about the best 
> fixed 
> IP-Number or a pool of dynamic numbers is far too short-sighted. As a true 
> linux user by hard for many year now I have no problem in running a couple of 
> commands to connect my Freerunner to my machine and configure it's internet 
> connection to get some updates. However on the long run, if I will have to 
> continue doing it like that I consider it a confession of failure.
> 
Sure. The default should "just work". And there should be 
configurability for those with different needs. Such as updating 30 
company phones all connected to the same usb hub...

> M$ and Apple are successful with their devices because users do not have to 
> care at all about IP-Numbers or editing /etc/resolv.conf. Neither do today's 

And they "fail" because you usually can't do anything out of the 
ordinary. Connect just one phone to the PC at a time, please. Connect
two phones to each other with a usb cable? Why would anyone want that?
A networked phone game that doesn't need to call into one of our servers 
- where is the money in that . . .

> Linux-Users as the vast majority is using DHCP on their DSL-(WiFi)-Routers 
> They plug it in or move into a certain location and things just happen as 
> expected.
> 
> Believe me I don't like the side effects that come with all this automatisms, 
> which is why I bought the freerunner so I have the freedom to change it. 
> However as I sit in front of my desktop day by day already strangling with a 
> more or less constant level of "configuration problems" (network gone, faulty 
> acpi, xorg update broke screen resolution, etc.). I would really love to have 
> my phone "just work" sometime in the relatively near future.
> 
I agree that it should "just work" as far as possible. And the expert 
user can always make changes precisely because this is linux.

Still, the way to "just works" is to use existing standards as
much as possible. A fixed IP address is a last resort. Use that only if
we have to. If this phone (or the next one) makes it to mass markets,
then there will be families with several phones. It may be convenient
to charge & update them at the same time from the same PC. Your friend 
with the same phone might visit. You may want to surf the net at the 
same time. It'd be nice if all this "just works" too,
and it won't when all phones share a fixed address.

Running DHCP on the PC's usb interface is one way to make this case 
"just work". Combining link-local addresses with NAT is perhaps another 
way. A fixed address won't do the trick.

Either way, some software has to be set up on the PC. But that is OK,
even windows people are used to installing a "driver CD" in order
to connect their new phone to the computer. If this software then
allows plugging in all your phones at the same time, so much the better!

> For example a user friendly but still linux-like phone could ask me: 
> "Hey, while you already have decided to go on the internet (via usb or wifi 
> or 
> gprs, it's my decision and not limited by design flaws) shouldn't I download 
> the latest updates in the background?"
> or
> "Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly sync 
> your appointments and contacts with your favourite OpenSync-enabled PIM-Suite 
> (or even with nasty Outlook)?" 
> 
Do this or don't do this. Make it a setup option.
But please - don't pop up questions! Questions
that pop up while I use the phone gets in my way - yuk. Questions
that pop up while the phone is in my pocket just wastes CPU effort
and drains the battery. And it is particularly nasty if I pull the
phone out of my pocket to make a call, and have to wade through
2-3 items that popped up since the last use - items that may even be
irrelevant now that I have moved around.

With SHR I already get one such popup - the one that suggests charging
the nearly empty battery. The warning makes sense, but I usually
put the phone on charging without looking at the screen, and the
popup hang around forever until I need to use the thing. So often 
enough, I see this power complaint combined with a full battery.
Of course this case can be fixed - the phone notices that
power gets plugged in, and could remove the warning.


Helge Hafting



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Illume keyboard dictionary sorting and normalization

[The Rasterman]

On Tue, 6 Jan 2009 11:49:55 +0100 "Olof Sjobergh"  babbled:

> Hi,
> 
> I'm working on a Swedish dictionary and keyboard for Illume, but I'm
> having some trouble with sorting of utf8 chars in the dictionary. I
> can't seem to get the sorting right. Looking at the code, Illume sorts
> the dictionary after first normalizing the strings according to the
> internal normalization table. Is there any way to reproduce this
> sorting with the sort command? I've tried with a few different locales
> (C, en_US.utf8) which all make the unix sort command work differently.
> But no matter what I try words don't show up correctly.

sort -f i think does it... i think...

> Another issue I found is that the built in normalization table is not
> very good for typing Swedish text. On a standard Swedish qwerty
> layout, we have three additional letters (å, ä and ö). These are used
> very frequently in Swedish and there are many common words that have
> different meanings if spellt with a, å or ä (for example har, här and
> hår are all very common words). But in Illume these are all normalized
> to a. Writing Swedish with a US qwerty layout and then having to
> select aåä manually after the dictionary lookup is a pain, since many
> common words will have to be selected from the lookup list each time.
> 
> Instead, what you want is a Swedish qwerty layout (which is very
> simple to implement as a .kbd file), and not normalize åäö for the
> Swedish dictionary lookup. So the normalization table would really
> need to be configurable, either as a part of the dictionary or the
> .kbd file. I suppose this problem exists for other languages as well.
> If I were to work on such a change, what would be the best approach?

hmm interesting i was just going of german/french and portuguese on this where
i thought i could get away with simple normalisation and a basic qwerty layout
- with selecting the matches (Vogel/Vögel for example). making the table part
of the dictionary does make a lot of sense of course. the dict format does need
to change to make it a lot faster and intl-char friendly. i avoided this at the
time as i'd need to efficiently encode a b-tree in the file and be able to mmap
() it efficiently and use it.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Robin Paulson]

2009/1/6 The Rasterman Carsten Haitzler :
> you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
> in illume to allow for straight-through pushing of key presses without a dict
> int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as

following on from this, would a hybrid of the two (the terminal kb no
guesses, and the dictionary lookup kb) be possible? it can be very
frustrating to think a long word will be in the dictionary, type it,
find it's not in the dictionary, and have to delete it, switch to the
terminal kb and type it again.

when the list of possible words comes up, it would be very useful to
have the kb give the exact sequence of letters, as typed, as one
option, alongside the dictionary guesses

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Mathieu Rochette]

Shashank Bharadwaj wrote:
> On Tue, Jan 6, 2009 at 10:47 AM, The Rasterman Carsten Haitzler
> mailto:ras...@rasterman.com>> wrote:
>
> On Tue, 06 Jan 2009 02:46:15 + Jan Henkins  > babbled:
>
>  > Hello there,
>  >
>  > Pascal d'Hermilly wrote:
>  > > With 2008.12 release, a well working finger-friendly keyboard
> is the
>  > > most critical missing feature for me.
>  > > I've made a mockup of a keyboard that I think would make things
> a lot
>  > > easier to type.
>  > > http://dhermilly.dk/pascal/openmoko/keyboard%20mockup.png
>
>
> I think, the current Raster's Keyboard great for potrait mode. For
> landscape mode(i.e holding neo sideways) however, the keyboard does not
> utilize the extra space. What we need is, imho, a keyboard that would
> increase in size to take up the extra space in this landscape mode. That
> way we'll be able to type even faster. If we could add that fuctionality
> to raster's keyboard, then it'd be just great.
>
if you start the keyboard in landscape mode, it does utilize all 
available place and it's great :)
(in keyboard settings, just select non and then default while in 
landscape mode)

Another thing, I can't test it from office, but, is it possible to have 
multiple at the same position, if so one could make a t9 "like" layout
just put, abc on the same position, def, on another, etc.
would that be possible?

Mathieu.
> Just my INR 0.02.
>
> --
> Regards
> Shashank
> As our circle of knowledge expands, so does the circumference of
> darkness surrounding it - Albert Einstein
>
>
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Leonti Bielski]

I like the illume keyboard! I like it a lot.
Word matching is working for me very well even for thumb. I get exact
words with my finger in a majority of cases.

Dictionaries. It seems like a lot of people blame Raster's keyboard
for not getting word matches because of the lack of dictionary. Do you
really expect Rasterman to make dictionaries for every language?
Dictionary format is very simple.

In conclusion - for our screen, from all possible qwerty keyboards -
Raster's is the best one. Maybe some other inpout method would be
good, but as for keyboard it's actually very very impressive.

Leonti

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Illume keyboard dictionary sorting and normalization

[Olof Sjobergh]

Hi,

I'm working on a Swedish dictionary and keyboard for Illume, but I'm
having some trouble with sorting of utf8 chars in the dictionary. I
can't seem to get the sorting right. Looking at the code, Illume sorts
the dictionary after first normalizing the strings according to the
internal normalization table. Is there any way to reproduce this
sorting with the sort command? I've tried with a few different locales
(C, en_US.utf8) which all make the unix sort command work differently.
But no matter what I try words don't show up correctly.

Another issue I found is that the built in normalization table is not
very good for typing Swedish text. On a standard Swedish qwerty
layout, we have three additional letters (å, ä and ö). These are used
very frequently in Swedish and there are many common words that have
different meanings if spellt with a, å or ä (for example har, här and
hår are all very common words). But in Illume these are all normalized
to a. Writing Swedish with a US qwerty layout and then having to
select aåä manually after the dictionary lookup is a pain, since many
common words will have to be selected from the lookup list each time.

Instead, what you want is a Swedish qwerty layout (which is very
simple to implement as a .kbd file), and not normalize åäö for the
Swedish dictionary lookup. So the normalization table would really
need to be configurable, either as a part of the dictionary or the
.kbd file. I suppose this problem exists for other languages as well.
If I were to work on such a change, what would be the best approach?

Best regards,

Olof Sjobergh

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:39:02 +0100 "arne anka"  babbled:

> >> > no, t9 is patented in it's entirety.
> >>
> >> what exactly is patented that could not be reimplemented?
> >>
> >> - the system of numbers and characters per key is afaik a well known
> >> standard (and dating from long before the mobile era)
> >> - hitting the key several times to select a specific symbol was done  
> >> long
> >> before t9 came up
> >> - completing a word from a dictionary based on the already available
> >> string is done by several keyboard apps (even xvkbd afaik) w/o violating
> >> any patents
> >
> > the last bit is patented. matching it to a dictionary (when combined  
> > with the
> > first 2). this is the patent. when combined with a numberpad and key
> > combinations per number - to use a dictionary to auto-guess the key you  
> > wanted
> > without having to cycle through all keys with multiple presses on a key.
> 
> sounds to my like a combination of prior art and triviality -- but  
> probably no one has time or money to dispute it ...

they do. they have. and they have lost. patent has withstood the court system.
and that cost them dearly. google it. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 13:37:41 +0300 Paul Fertser  babbled:

> Hi,
> 
> Carsten Haitzler (The Rasterman)  writes:
> >> what exactly is patented that could not be reimplemented?
> ...
> >> - completing a word from a dictionary based on the already available  
> >> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
> >> any patents
> >
> > the last bit is patented. matching it to a dictionary (when combined with
> > the first 2). this is the patent. when combined with a numberpad and key
> > combinations per number - to use a dictionary to auto-guess the key you
> > wanted without having to cycle through all keys with multiple presses on a
> > key.
> 
> But isn't it a "software patent" and therefore unenforceable in any
> sane jurisdiction?
> 
> It seems many people just can't believe how bad "software patents" are
> if they can be enforced. So bad it's hard to imagine.

you might be surprised how many jurisdictions its enforceable in. several
companies have been taken to court and lost over this patent - having to pay
up. and they had to pay up big-time. millions of $. now you can do your own
software for your own "software patents can go suck a duck" world - but the
moment that software goes to major markets in the world and is distributed
and/or used - people are in danger of litigation over a successfully defended
patent. and even worse - they are up for extra damages as you now KNOW about
the patent - if you don't know you get off lighter. the moment it can be shown
you knew and violated it anyway... you are in deep trouble.

yes - software patents suck - but they are a reality of life unfortunately. i
wish they didn't exist. even places where software patents don't apply - they
are normally enforceable when COMBINED with hardware. so that means OM can't
ever ship a product with such an input system so it's useless to om as its
combined with hardware - even if it's an extra download later - OM is directly
involved in development of the software and hosting repositories of software to
download etc. etc. so they are playing with fire even having anything to do
with such an input method.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[arne anka]

>> > no, t9 is patented in it's entirety.
>>
>> what exactly is patented that could not be reimplemented?
>>
>> - the system of numbers and characters per key is afaik a well known
>> standard (and dating from long before the mobile era)
>> - hitting the key several times to select a specific symbol was done  
>> long
>> before t9 came up
>> - completing a word from a dictionary based on the already available
>> string is done by several keyboard apps (even xvkbd afaik) w/o violating
>> any patents
>
> the last bit is patented. matching it to a dictionary (when combined  
> with the
> first 2). this is the patent. when combined with a numberpad and key
> combinations per number - to use a dictionary to auto-guess the key you  
> wanted
> without having to cycle through all keys with multiple presses on a key.


sounds to my like a combination of prior art and triviality -- but  
probably no one has time or money to dispute it ...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Paul Fertser]

Hi,

Carsten Haitzler (The Rasterman)  writes:
>> what exactly is patented that could not be reimplemented?
...
>> - completing a word from a dictionary based on the already available  
>> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
>> any patents
>
> the last bit is patented. matching it to a dictionary (when combined with the
> first 2). this is the patent. when combined with a numberpad and key
> combinations per number - to use a dictionary to auto-guess the key you wanted
> without having to cycle through all keys with multiple presses on a
> key.

But isn't it a "software patent" and therefore unenforceable in any
sane jurisdiction?

It seems many people just can't believe how bad "software patents" are
if they can be enforced. So bad it's hard to imagine.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Jan Henkins]

Hello Xavier,

On Tue, January 6, 2009 09:07, Xavier Cremaschi wrote:
>> I don't get how the dictionnary (illume and qtopia) actually helps to
>> write some word.
>
> To write "forest" with illume keyboard you just have to type :
> - near the f key
> - near the o key
> - near the r key
> - near the e key
> - near the s key
> - near the t key
> For each key you type, the illume keyboard makes the hypothesis that you
>   probably type near the right key but not exactly on the right key, so
> with these 6 different positions (for "forest") it searches in its
> dictionary all the possible words.
>
> That's why "for" and "die" come together.

In practice this did not work for me. Reasons for this is partly my lack
of proficiency with the likes of the qtopia k/b, and partly because I type
in multiple languages (one being Afrikaans, which does not have a
dictionary yet, something I would like to do a bit of work on myself a bit
later). A stock finger-friendly qwerty layout without dictionary support
works better in a situation like this.

-- 
Regards,
Jan Henkins


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 11:20:12 +0100 "arne anka"  babbled:

> > no, t9 is patented in it's entirety.
> 
> what exactly is patented that could not be reimplemented?
> 
> - the system of numbers and characters per key is afaik a well known  
> standard (and dating from long before the mobile era)
> - hitting the key several times to select a specific symbol was done long  
> before t9 came up
> - completing a word from a dictionary based on the already available  
> string is done by several keyboard apps (even xvkbd afaik) w/o violating  
> any patents

the last bit is patented. matching it to a dictionary (when combined with the
first 2). this is the patent. when combined with a numberpad and key
combinations per number - to use a dictionary to auto-guess the key you wanted
without having to cycle through all keys with multiple presses on a key.

> so, what does t9 do that's not available already?
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 06 Jan 2009 12:02:40 +0100 Esben Stien  babbled:

> Pascal d'Hermilly  writes:
> 
> > a well working finger-friendly keyboard is the most critical missing
> > feature for me.
> 
> Yes, I find this issue very strange. First and foremost, it is us
> hackers that use this device for now and are supposed to make apps for
> freerunner and all, and we don't have a damn keyboard;). All this
> fancy pancy dictionary based guessing is maybe good for normal people
> writing crappy SMS messages, but not for the current user base, in my
> opinion.

you do - Terminal.kbd layout - it ships with illume. i designed the kbd engine
in illume to allow for straight-through pushing of key presses without a dict
int he way. the Terminal.kbd bypasses dict lookup by just emitting keysyms as
opposed to strings. don't like the keys on that .kbd? edit the .kbd file.
change it yourself! its just text! i tackled both sides of the problem in 1 bit
of code. if you want you can install and use the matchbox keyboard or the
matchbox numberpad keyboard too- they both work. they need a little extra
packaging with a .desktop file - but they are selectable. i tried to cover
pretty much everything anyone could want - an internal built-in kbd capable of
both dictionary fixup entry and simple straight-through terminal keyboard, able
to have that just disabled in favor of an external keyboard window provided by
any process, as well as protocols that are robust for hinting if you want
keyboard entry or not and what kind of entry (numeric, password, terminal) etc.
i've laid a lot of the groundwork and filled in a lot of the boxes too - can't
expect me to do EVERYTHING for EVERYONE... but i tried to cover a good
smattering.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[arne anka]

> no, t9 is patented in it's entirety.

what exactly is patented that could not be reimplemented?

- the system of numbers and characters per key is afaik a well known  
standard (and dating from long before the mobile era)
- hitting the key several times to select a specific symbol was done long  
before t9 came up
- completing a word from a dictionary based on the already available  
string is done by several keyboard apps (even xvkbd afaik) w/o violating  
any patents

so, what does t9 do that's not available already?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 10:14:19 +0100 kimaidou  babbled:

> Ok. Thanks both for your usefull answers.
> @Vasily : T9 is patented, but we can reproduce the same functionnality, as
> OpenOffice did with Microsoft Office, or am I missing something ?

no you can't a patent coverts any form of reproduction of the idea. its not
copyright. the way the illume kbd works as best i know bypasses apples patent
on the iphone kbd (which enlarges hit areas for keys based on the most likely
key you want next also based on dictionary lookup) as it works differently (not
playing with hit areas at all but using distances to keys). it doesnt do
anything like t9 that could be violating the patent - so as such unless you come
up with a better way to enter stuff that isnt patented... good luck! my take on
the Fr touchscreen:

1. avoid drags - you have to press hard with a finger to retain enough
pressure to keep a press down. it's a resistive screen meant for a stylus - a
sharp point. a finger is not a small sharp point thus more pressure is needed
to keep things down soa press is registered and stays registered.
2. stick to taps - it's easy to tap a finger down with a bit of speed to thus
get enough momentum and press the screen to get a tap - but maintaining as
above is much harder and should be avoided. so input methods that need a press
+drag (a lot) are going to be painful with fingers - avoid them like the
plague. they are nice theories - and work with styluses. good luck doing it
with a finger.

so.. now you want an input method that uses taps. you want something that is
familiar/easily learnable by people. you can do dasher. you can do all sorts of
out-there input methods people dream up. humans are creatures of habit. we like
the familiar. so... you could go the "qwerty - familiar if you ever used a
computer or typewriter" or "abc def ghi ..." arrangement (in fact the illume
kbd can do this just fine - go make a .kbd file with keys laid out like they
are on a numberpad! it will work - just fine! thats the idea of .kbd layout
files - it puts the power in the hands of (advanced) users without having to
code to be able to do new keyboard layouts). the core dictionary and fuzzy
matching code is the same and applies to both. some people will find the qwerty
layout more familiar - some the abc def ghi etc. numberpad layout better... all
the mechanisms, file formats and power is there - just waiting to be
harnessed. :) (i love writing stuff to be generic to tackle a problem in a
broad way to solve lots of problems in one foul swoop - it is a painful entry
barrier to get it done to begin with, but once done and tuned - is nice how its
so flexible with just some config swizzling - it solves a problem a whole new
way etc.) :)

> @Xavier : Ah ah, I completely lost this one ! I wil try it now
> 
> @ both and others : what about transparency ?

see my long long long email about the kbd. :)

> 2009/1/6 Xavier Cremaschi 
> 
> > > I don't get how the dictionnary (illume and qtopia) actually helps to
> > > write some word.
> >
> > To write "forest" with illume keyboard you just have to type :
> > - near the f key
> > - near the o key
> > - near the r key
> > - near the e key
> > - near the s key
> > - near the t key
> > For each key you type, the illume keyboard makes the hypothesis that you
> >  probably type near the right key but not exactly on the right key, so
> > with these 6 different positions (for "forest") it searches in its
> > dictionary all the possible words.
> >
> > That's why "for" and "die" come together.
> >
> >
> > Xavier.
> >
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [2008.12] Mediaplayer

[Giovanni]

Dear Timo,

can you share your python app for switching the profiles?



On Tue, Jan 6, 2009 at 10:07 AM, Timo Jyrinki wrote:

> 2009/1/6 Dylan Reilly :
> > To tell you the truth, I am not sure. I have always been running the
> > testing distribution, but 2008.12 *should* be more or less the same as
> > testing.
>
> No. There were two types of testing image, one using the 2008.12-like
> qtopia stuff and one using freesmartphone.org. 2008.12 is not using
> frameworkd, but the qtopia daemons like qpe and qtopia-x11
> messaging/dialing/etc. software.
>
> 2008.12 does not include the profile switching feature, but like said
> there are scripts for it. I simply have a python app with a few
> buttons I can use to switch between profiles for music playback
> (phone, loudspeakers, headphones).
>
> -Timo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Developers guide for dummies - Eclipse

[Robin Häggqvist]

Hello
I might start with that I don't have much developer experience(some
java/Pascal class in school a few years ago) and im trying to setup eclipse
on my ubuntu8.10 machine. I think I have installed it in 3 diffrent
places(first 3.2 version second 3.4.4 version and one 3.4.1 with C/C++
platform). Maybe not too good but there it is.

Im having problem setting it up. Im told to do:
http://wiki.openmoko.org/wiki/Development_with_Eclipse
create the managed C project and add `pkg-config --cflags --libs gtk+-2.0`
both to the compiler options and to linker flags.

and follow the 8 steps on the same page.

I have no ide what the compiler options are or what linker flags are.  My
window looks like this.(
http://picasaweb.google.se/lh/photo/Hqo8bETo7P2a9NvcoJ0fbQ?feat=directlink )
( http://img377.imageshack.us/my.php?image=propertiesforfirstjt3.png )
Did I start on the wrong end here?
Did I skip anything important since im a dummie and are starting from 0 as a
developer. should I start somewhere else?


-- 
/Robin Häggqvist

Robin recommends:
http://openoffice.org * http://gimp.org * http://avast.com *
http://gmail.com * http://cdburnerxp.se * http://7-zip.org *
http://realvnc.com/ or http://www.ubuntu-se.org/
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When will kernel 2.6.24 be replaced by andy 2.6.28 kernel for better suspend/resume?

[Sander van Grieken]

> Hi,
>
> Fox Mulder  writes:
>> Paul Fertser wrote:
>>> Sander van Grieken  writes:
> So the question is, when will the default kernel be replaced by the new
> 2.6.28 andy kernel so that userspace tools could be adapted to it?
 That would be my question as well.

 I only care for userspace to be adapted to test the suspend/resume
 functionality (on FSO, only frameworkd?).
>>>
>>> frameworkd newer than 31 Dec should properly support both kernels. I'm
>>> afraid it's not included in any images yet (please correct me if i am 
>>> wrong).
>>
>> Latest fso-frameworkd in debian is 0.8.4.3-20081215-1 which is older
>> than 31 dec i would guess.
>> I hope a new version comes very soon so i can try to change from 2.6.24
>> to the new 2.6.28 kernel. :)
>
> Actually, you can try to change from 2.6.24 after applying an ad-hoc
> patch from http://trac.freesmartphone.org/ticket/293 even on old
> version that's provided by Debian (that's exactly what i did a month ago).

Aah exactly what I was looking for, thanks Paul.

grtz,
Sander



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[kimaidou]

Woua ! THAT is a complete explanation ! It shows well the complexity and
power of the illume keyboard method. I apologize for not having well
understand this before.
I will now definitely use the keyboard, and improve my dictionnary as I
type.
Thanks a lot for the complete explanation



2009/1/6 The Rasterman Carsten Haitzler 

> On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou  babbled:
>
> > Hi all,
> >
> > I am glad people (re-)start to talk about keyboards.
> >
> > 2 points:
> >
> > * Another great improvement compared to the iphone, illume, etc. ones,
> would
> > be to have a transparent keyboard, using the whole screen, but allowing
> to
> > see through it. Of course we need the transparency % to be changed by the
> > user. What about the technical feasibility of that ? Would it be possible
> ?
> > I thing for example about the Qwo keyboard (
> > http://www.opkg.org/package_84.html ) which would be very finger
> friendly in
> > full screen (like the other one)
>
> not possible without compositing. not to mention the absolute HORROR of now
> having to mix keyboard input with controlling the apps under it - which is
> it u
> do? press the key or the "ok" button thats visible thru the key?
> compositing is
> not a viable thing on the freerunner - u'll need a much lower res to make
> it
> sane and even then it'll be really pushing it at qvga on the 2442.
>
> > * I don't get how the dictionnary (illume and qtopia) actually helps to
> > write some word. In mobile phones, on which you have only 9 numbers to
> type,
> > so 3 letters by number, the "T9" dictionnary was really helpfull, because
> it
> > showed a list of words possible with the combination of the letters
> entered.
> > I could actually write sms faster with only 9 keys than now with a
> complete
> > qwerty keyboard because the buttons were much bigger and I had only 9
> button
> > to search among. Here with the FR, the "eyes and brain" must locate the
> > desired letter among much more and much smaller keys. And furthermore, I
> > don't see the point with the dictionnary. The dictionnary only shows
> words
> > with the same number of letters as the ones entered. So it does not
> provide
> > a way to easily choose a word (for example, when I type "for" it must
> show
> > "for", "forest", force", etc., but  with the illume keyboard it only
> shows
> > "for" and other useless words like :"big", "fit", die", but", etc.--> not
> > very related to "for" ) People using OpenOffice Writer with the
> > autocompletion activated will understand what I am trying to explain with
> my
> > limited english skills..
>
> ok. let me draw u a keyboard (or part of it):
>
>  q w e r t y u i o p
>   a s d f g h j k l
>z x c v b n m
>
> i want to type "dog". for this example i will only use english as the
> example -
> but it applies to all languages actually. now lets say i press "d" (i want
> to
> type "dog"), then "o" then "g". but look at the keyboard - i may not
> EXACTLY
> hit d, o and g. i probably hit them or something near them, so ad i try and
> hit
> d i may hit e, and i may hit k and not o, and h instead of g, so i actually
> hit:
> "ekh"
>
> that's not "dog"! of course not. but it also is not any word in english (in
> the
> dictionary) so obviously.. it must be wrong. i meant something else. now
> lets
> stand back.
>
> first key i press "e" is near d. it's also near r, s, w, and f. let's write
> the
> "possible" keys i may have intended as a list per keystroke:
> e, d, r, s, w, f
> now for "k" (when i meant "o"):
> k, i, u, j, m, l, o
> and for "h" (when i meant "g"):
> h, y, u, j, n, b, g
>
> ok so now for every keystroke i have a list of possible keys near where i
> pressed that i may have meant (again i have simplified this - in reality
> the
> list of keys per press is more like 10-15 possible keys as it has a large
> search area - this is the fuzz value in the .kbd file - it determines how
> far
> the fuzzy matching should search in virtual keyboard units).
>
> now what we do is start checking all combinations of all the letters per
> key
> stroke, so we first try:
>
> ekh -> wrong
> eih -> wrong
> euh -> wrong
> ejh -> wrong
> emh -> wrong
> elh -> wrong
> eoh -> wrong
> eky -> wrong
> eiy -> wrong
> euy -> wrong
> ejy -> wrong
> emy -> wrong
> ely -> wrong
> eoy -> wrong
> ekh -> wrong
> eiu -> wrong
> euu -> wrong
> eju -> wrong
> emu -> BINGO! a real word!
> elu -> wrong
> eou -> wrong
> ekj -> wrong
> eij -> wrong
> etc.
>
> in the end if you search permutations you'd get a list of words that
> "match"
>
> emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on.
>
> now we have a list of words i possibly wanted that match. (its very much
> like
> the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on
> mapping
> 26 letters to just 8 numbers on a numberpad - because you have no actual
> numberpad - its just a surface you tap on and you have a co-ordinate where
> you
> press. so you dont NEED to map it that way - you can just pre

Re: Default IP Address on All Distributions

[Thomas Otterbein]

> wrote:
> > fla...@correo.ugr.es wrote:
> >>> Sure. And if we go that way, why not use the proper way of setting a
> >>> link-local address?
> >>> * Pick a random address
> >>> * check that it is free (arp, ping,...)
> >>> * take it.
> >>>
> >>> That has a good chance of working, even for those who
> >>> routinely connect two phones to the same pc at the same time.
> >>>
> >>> Helge Hafting
> >>
> >> I'm not sure to have fully understood you, but I like having the phone
> >> always on the same address.
> >
> > There was a suggestion of using link-local addresses.
> > If we do that, then we had better do it properly, because you
> > aren't supposed to grab the same link-local address every time. If that
> > is a problem, the solution is to not use link-local addresses.
> >
> > As long as you have one phone, a fixed IP address works well. If you
> > have two or more, it is better if they are different or resolves the
> > colission automatically. And then we might as well use existing
> > standards. But perhaps there aren't that many people
> > managing several phones from one pc.
> >
> > Helge Hafting
>
> Certainly there will be far less, proportionally, with Openmoko success.
> If Openmoko succeeds - which I presume we all want - then we, the linux
> hackers, will be the minority of users.  The community as it exists right
> now cannot be considered the long-term target userbase.  The more things
> deviate from 'just works' the more Joe Smartphone-user will consider broken
> when he can't figure it out.  I'm not saying "dumb it down", just
> reiterating my mantra of "simple working defaults".
>
> I think we need to set a default IP pair in a /30 subnet or at least
> designate a subnet NOT commonly used, and UI network controls can allow to
> alter them at need.  (or for those who perversely eschew UIs on a
> touchscreen phone, you can edit the config :)  For 'backward-compatibility'
> (read: our convenience ;) I suggest 192.168.0.202/30 on the FR, .201 on
> host - machines with .200 can still communicate on this subnet.  But my gut
> tells me we need a clean break and a clean subnet, like 10.19.73.0/24 or
> 10.79.77.0/24... ;)
>
> Something that works for a linux hacker works for us, something that works
> for the average smartphone user works for Openmoko.  But by virtue of who
> and where we are, we can influence this and hopefully end up with something
> that just works.
>
> j


Now when it comes to "real users" I believe the discussion about the best fixed 
IP-Number or a pool of dynamic numbers is far too short-sighted. As a true 
linux user by hard for many year now I have no problem in running a couple of 
commands to connect my Freerunner to my machine and configure it's internet 
connection to get some updates. However on the long run, if I will have to 
continue doing it like that I consider it a confession of failure.

M$ and Apple are successful with their devices because users do not have to 
care at all about IP-Numbers or editing /etc/resolv.conf. Neither do today's 
Linux-Users as the vast majority is using DHCP on their DSL-(WiFi)-Routers 
They plug it in or move into a certain location and things just happen as 
expected.

Believe me I don't like the side effects that come with all this automatisms, 
which is why I bought the freerunner so I have the freedom to change it. 
However as I sit in front of my desktop day by day already strangling with a 
more or less constant level of "configuration problems" (network gone, faulty 
acpi, xorg update broke screen resolution, etc.). I would really love to have 
my phone "just work" sometime in the relatively near future.

For example a user friendly but still linux-like phone could ask me: 
"Hey, while you already have decided to go on the internet (via usb or wifi or 
gprs, it's my decision and not limited by design flaws) shouldn't I download 
the latest updates in the background?"
or
"Um, I sense your bluetooth-enabled desktop is nearby. Shall I quickly sync 
your appointments and contacts with your favourite OpenSync-enabled PIM-Suite 
(or even with nasty Outlook)?" 

Sorry for pouring out all that stuff here but I felt the urgent need to try to 
refocus on the efforts. I know it's a lot of work to which I haven't 
contributed much (yet), but if the Freerunner is supposed do revolutionize the 
mobile world it needs to do things better or smarter or at leased as good but 
with more freedom than it's competitors (Windows Mobile, IPhone, Blackberry 
from my point of view).

Regards
  thomas


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Esben Stien]

Pascal d'Hermilly  writes:

> a well working finger-friendly keyboard is the most critical missing
> feature for me.

Yes, I find this issue very strange. First and foremost, it is us
hackers that use this device for now and are supposed to make apps for
freerunner and all, and we don't have a damn keyboard;). All this
fancy pancy dictionary based guessing is maybe good for normal people
writing crappy SMS messages, but not for the current user base, in my
opinion.

-- 
Esben Stien is b...@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FSO/SHR/Debian] Update to BtGPS.py

[Minh Ha Duong]

Le mardi 06 janvier 2009, kimaidou a écrit :
> Hi Angus
> What about putting this app on the opkg.org website, so people would easily
> find it ?
> Thanks anyway for sharing your work

  I would like to kindly share my recent experience with opkg.org. Entering or 
updating an application page is really simple. Just fill a form with half a 
dozen fields. Anybody can do it, it does not need to be done by the author. I 
recon it is not as simple as writing an email to ask someone else to do it, 
but almost ;) ...

Yours,
Minh

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Robin Paulson]

2009/1/6 kimaidou :
> Ok. Thanks both for your usefull answers.
> @Vasily : T9 is patented, but we can reproduce the same functionnality, as
> OpenOffice did with Microsoft Office, or am I missing something ?

no, t9 is patented in it's entirety. ms office is not patented as a
whole, although some parts might be - ms do not own the concepts of a
word processor/spreadsheet/presentation editor

as raster and om have shown, there are other great methods to input
text; i'm sure someone can design more decent methods, without ripping

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[The Rasterman]

On Tue, 6 Jan 2009 09:50:38 +0100 kimaidou  babbled:

> Hi all,
> 
> I am glad people (re-)start to talk about keyboards.
> 
> 2 points:
> 
> * Another great improvement compared to the iphone, illume, etc. ones, would
> be to have a transparent keyboard, using the whole screen, but allowing to
> see through it. Of course we need the transparency % to be changed by the
> user. What about the technical feasibility of that ? Would it be possible ?
> I thing for example about the Qwo keyboard (
> http://www.opkg.org/package_84.html ) which would be very finger friendly in
> full screen (like the other one)

not possible without compositing. not to mention the absolute HORROR of now
having to mix keyboard input with controlling the apps under it - which is it u
do? press the key or the "ok" button thats visible thru the key? compositing is
not a viable thing on the freerunner - u'll need a much lower res to make it
sane and even then it'll be really pushing it at qvga on the 2442.

> * I don't get how the dictionnary (illume and qtopia) actually helps to
> write some word. In mobile phones, on which you have only 9 numbers to type,
> so 3 letters by number, the "T9" dictionnary was really helpfull, because it
> showed a list of words possible with the combination of the letters entered.
> I could actually write sms faster with only 9 keys than now with a complete
> qwerty keyboard because the buttons were much bigger and I had only 9 button
> to search among. Here with the FR, the "eyes and brain" must locate the
> desired letter among much more and much smaller keys. And furthermore, I
> don't see the point with the dictionnary. The dictionnary only shows words
> with the same number of letters as the ones entered. So it does not provide
> a way to easily choose a word (for example, when I type "for" it must show
> "for", "forest", force", etc., but  with the illume keyboard it only shows
> "for" and other useless words like :"big", "fit", die", but", etc.--> not
> very related to "for" ) People using OpenOffice Writer with the
> autocompletion activated will understand what I am trying to explain with my
> limited english skills..

ok. let me draw u a keyboard (or part of it):

  q w e r t y u i o p
   a s d f g h j k l
z x c v b n m

i want to type "dog". for this example i will only use english as the example -
but it applies to all languages actually. now lets say i press "d" (i want to
type "dog"), then "o" then "g". but look at the keyboard - i may not EXACTLY
hit d, o and g. i probably hit them or something near them, so ad i try and hit
d i may hit e, and i may hit k and not o, and h instead of g, so i actually hit:
"ekh"

that's not "dog"! of course not. but it also is not any word in english (in the
dictionary) so obviously.. it must be wrong. i meant something else. now lets
stand back.

first key i press "e" is near d. it's also near r, s, w, and f. let's write the
"possible" keys i may have intended as a list per keystroke:
e, d, r, s, w, f
now for "k" (when i meant "o"):
k, i, u, j, m, l, o
and for "h" (when i meant "g"):
h, y, u, j, n, b, g

ok so now for every keystroke i have a list of possible keys near where i
pressed that i may have meant (again i have simplified this - in reality the
list of keys per press is more like 10-15 possible keys as it has a large
search area - this is the fuzz value in the .kbd file - it determines how far
the fuzzy matching should search in virtual keyboard units).

now what we do is start checking all combinations of all the letters per key
stroke, so we first try:

ekh -> wrong
eih -> wrong
euh -> wrong
ejh -> wrong
emh -> wrong
elh -> wrong
eoh -> wrong
eky -> wrong
eiy -> wrong
euy -> wrong
ejy -> wrong
emy -> wrong
ely -> wrong
eoy -> wrong
ekh -> wrong
eiu -> wrong
euu -> wrong
eju -> wrong
emu -> BINGO! a real word!
elu -> wrong
eou -> wrong
ekj -> wrong
eij -> wrong
etc.

in the end if you search permutations you'd get a list of words that "match"

emu, fig, dig, fly, sky, fog, rig, sob, dog, ... and so on.

now we have a list of words i possibly wanted that match. (its very much like
the 2 == avc, 3 == def, 4 == ghi, 5 == jkl etc. - but its not based on mapping
26 letters to just 8 numbers on a numberpad - because you have no actual
numberpad - its just a surface you tap on and you have a co-ordinate where you
press. so you dont NEED to map it that way - you can just present a qwerty
layout and just search for nearby keys u may have wanted to hit.

anyway - this is the simple version. now.. things get more complex. lets go
over the keys i possible wanted to hit again:

e, d, r, s, w, f
k, i, u, j, m, l, o
h, y, u, j, n, b, g

unlike the numberpas - the set of keys per press is entirely variable based on
what keys are near "within" the fuzz search radius. also unlike a keypad each
key will have a DISTANCE from the point i pressed so i know how far away it is
from the press point - thus the further away - the more unlikely it is i wanted
it. the clos

Re: Openmoko keyboard mockup

[kimaidou]

Ok. Thanks both for your usefull answers.
@Vasily : T9 is patented, but we can reproduce the same functionnality, as
OpenOffice did with Microsoft Office, or am I missing something ?

@Xavier : Ah ah, I completely lost this one ! I wil try it now

@ both and others : what about transparency ?

2009/1/6 Xavier Cremaschi 

> > I don't get how the dictionnary (illume and qtopia) actually helps to
> > write some word.
>
> To write "forest" with illume keyboard you just have to type :
> - near the f key
> - near the o key
> - near the r key
> - near the e key
> - near the s key
> - near the t key
> For each key you type, the illume keyboard makes the hypothesis that you
>  probably type near the right key but not exactly on the right key, so
> with these 6 different positions (for "forest") it searches in its
> dictionary all the possible words.
>
> That's why "for" and "die" come together.
>
>
> Xavier.
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko keyboard mockup

[Xavier Cremaschi]

> I don't get how the dictionnary (illume and qtopia) actually helps to 
> write some word.

To write "forest" with illume keyboard you just have to type :
- near the f key
- near the o key
- near the r key
- near the e key
- near the s key
- near the t key
For each key you type, the illume keyboard makes the hypothesis that you 
  probably type near the right key but not exactly on the right key, so 
with these 6 different positions (for "forest") it searches in its 
dictionary all the possible words.

That's why "for" and "die" come together.


Xavier.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community