Re: Tangogps google maps

[Michele Brocco]

the latest i had was:
http://mt1.google.com/vt/lyr...@110&hl=en&x=%d&y=%d&z=%d%s=Galile

and set xyz instead of zxy

On Fri, Oct 30, 2009 at 10:18 PM, Aditya Gandhi  wrote:
> whats the latest config to get google maps working on tangogps I need help
> with it too

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

bluetooth a2dp connection problem

[Mario Huelsegge]

hallo,

i have a problem with my b-speech calypso bluetooth headset and a2dp. i
configured my shr-u (bluez4) as described on
http://wiki.openmoko.org/wiki/A2DP . after starting mplayer to listen to
some music over bluetooth, mplayer stops and bluetoothd gives these errors:

bluetoothd[2938]: Found AV Remote
bluetoothd[2938]: Adapter /org/bluez/2938/hci0 has been enabled
bluetoothd[2938]: Computer is classified as laptop
bluetoothd[2938]: Current device class is 0x4a010c
bluetoothd[2938]: Setting 0x00010c for major/minor device class
bluetoothd[2938]: Changing major/minor class to 0x4a010c
bluetoothd[2938]: Accepted new client connection on unix socket (fd=16)
bluetoothd[2938]: Audio API: BT_REQUEST <- BT_GET_CAPABILITIES
bluetoothd[2938]: avdtp_ref(0x2a041730): ref=2
bluetoothd[2938]: adapter_get_device(00:2B:7D:02:AE:B4)
bluetoothd[2938]: link_key_request (sba=00:06:2B:17:96:C3,
dba=00:2B:7D:02:AE:B4)
bluetoothd[2938]: kernel auth requirements = 0x04
bluetoothd[2938]: stored link key type = 0x00
bluetoothd[2938]: Connection refused (111)
bluetoothd[2938]: Disconnected from 00:2B:7D:02:AE:B4
bluetoothd[2938]: discovery failed
bluetoothd[2938]: Audio API: BT_ERROR -> BT_GET_CAPABILITIES
bluetoothd[2938]: avdtp_unref(0x2a041730): ref=1
bluetoothd[2938]: avdtp_unref(0x2a041730): ref=0
bluetoothd[2938]: avdtp_unref(0x2a041730): freeing session and removing from
list
bluetoothd[2938]: Unix client disconnected (fd=16)
bluetoothd[2938]: client_free(0x2a03cf98)
bluetoothd[2938]: link_key_request (sba=00:06:2B:17:96:C3,
dba=00:2B:7D:02:AE:B4)
bluetoothd[2938]: kernel auth requirements = 0x00
bluetoothd[2938]: stored link key type = 0x00
bluetoothd[2938]: adapter_get_device(00:2B:7D:02:AE:B4)
bluetoothd[2938]: AVDTP: incoming connect from 00:2B:7D:02:AE:B4
bluetoothd[2938]: avdtp_unref(0x2a041730): ref=0
bluetoothd[2938]: avdtp_unref(0x2a041730): freeing session and removing from
list
bluetoothd[2938]: session_cb

the interesting thing is that after trying to start mplayer several times,
it works!
any ideas why this is happening? it is quite uncomfortable to start mplayer
again and again to finally listen to music over bluetooth.

this is the output of bluetoothd after a successful connection:

bluetoothd[2938]: link_key_request (sba=00:06:2B:17:96:C3,
dba=00:2B:7D:02:AE:B4)
bluetoothd[2938]: kernel auth requirements = 0x00
bluetoothd[2938]: stored link key type = 0x00
bluetoothd[2938]: adapter_get_device(00:2B:7D:02:AE:B4)
bluetoothd[2938]: AVDTP: incoming connect from 00:2B:7D:02:AE:B4
bluetoothd[2938]: avdtp_unref(0x2a041730): ref=0
bluetoothd[2938]: avdtp_unref(0x2a041730): freeing session and removing from
list
bluetoothd[2938]: session_cb
bluetoothd[2938]: Accepted new client connection on unix socket (fd=16)
bluetoothd[2938]: Audio API: BT_REQUEST <- BT_GET_CAPABILITIES
bluetoothd[2938]: avdtp_ref(0x2a041730): ref=2
bluetoothd[2938]: state change attempted from connecting to connecting
bluetoothd[2938]: AVDTP: connected signaling channel to 00:2B:7D:02:AE:B4
bluetoothd[2938]: AVDTP imtu=672, omtu=895
bluetoothd[2938]: session_cb
bluetoothd[2938]: DISCOVER request succeeded
bluetoothd[2938]: seid 1 type 1 media 0 in use 0
bluetoothd[2938]: session_cb
bluetoothd[2938]: GET_CAPABILITIES request succeeded
bluetoothd[2938]: seid 1 type 1 media 0

-- 
View this message in context: 
http://n2.nabble.com/bluetooth-a2dp-connection-problem-tp3925316p3925316.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: Navit - german localization causes rounding of GPS-position

[David Garabana Barro]

O Sábado, 31 de Outubro de 2009, Christian Rüb escribiu:
> Hi,
> 
> I had the same problem. Also bookmarks will be saved using comma instead of
>  dot a separator (locale settings). As a workaround I unset LC_ALL before
>  starting navit (i.e. "Exec=unset LC_ALL; navit" in
>  /usr/share/applications/navit.desktop). That way your LANG variable keeps
>  set to de_DE.UTF-8, but locale settings are not in German...
> 
> I posted this in navit ML back in July - but no response if this is
>  intended or a bug :(

At least is't sure it's a known bug/feature:

http://wiki.navit-
project.org/index.php/FAQ#My_position_is_reported_incorrectly

-- 
David Garabana Barro
jabber & google talk ID:da...@garabana.com
Clave pública PGP/GPG:  http://davide.garabana.com/pgp.html


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: QtMoko - FBreader?

[Torfinn Ingolfsen]

On Sat, Oct 31, 2009 at 12:17 PM, foringer  wrote:

> You can run FBreader from QX menu. Open QX, in the left down corner tap
> the screen, select Favorites and check E-book reader.
>

Aha, there it is! I wasn't aware that I needed QX for it. Thanks!


> Tips: you can add QX menu to the Favorites, to quickly access its
> applications.
>

I already have QX in Favorites, if that is what you mean.
There is no way to add a "shortcut" somewhere that would automatically
launch  QX and a selected application in one step?

Sorry for ugly english, I'm not a native speaker
>

Your english is perfectly understandable to me (I am also not a native
english speaker), so don't worry about it. :-)
Have a nice day!

-- 
Regards,
Torfinn Ingolfsen
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: kbosd, or fatfingereverything

[A.A.]

Good job,

but the package libh1settings0 is missing in debian repository. How can I
solve?

2009/10/31 Michal Brzozowski 

> 2009/10/31 
>
>> So the OSD keyboard inspired by fatfingershell is now quite
>> nice and useable, especially since the addition of user feedback
>> using vibrator (due to Radics Áron). Also, you can now configure
>> the keyboard layout to your will using a simple configuration
>> file.
>>
>
> I'm curious and would like to try it out. Could you make an ipk for SHR
> too?
>
> Michal
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>


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

Re: [WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)

[EdorFaus]

On Saturday 31 October 2009 02:35:42 Sean Moss-Pultz wrote:
> On Sat, Oct 31, 2009 at 3:46 AM, Doug Jones  wrote:
> > (1) Has OpenMoko made the policy decision that filenames will be limited
> > to 8.3?
>
> We're using FAT.

I have a usable grasp of how FAT works, so I figured this would be the answer 
while reading this thread, and thought I'd reply with an explanation even 
before I saw your reply. It's not just policy, there are technical reasons.

While I suppose it's really enough to accept that this is how it is, I guess 
people with less of a grasp on how FAT works might need an explanation to 
really understand why this is the only sensible choice, so here goes:

The FAT filesystem inherently supports up to 8.3 filenames, and nothing more. 
This is a limitation of the on-disk format used for directories (including the 
root directory).

Long file name (LFN) support has been implemented on top of this (aka VFAT) in 
some systems, but it is really a hack: it adds extra directory entries that 
are (iirc) marked as being deleted files, and then uses the rest of the data 
(both filename and other fields, like size) for those entries to contain 
characters representing the long filename for the following directory entry 
(the real file). Thus, implementing this is a bit complex and hacky.

This is why DOS (and the DOS mode of W9x) doesn't see the long file names (just 
foobar~1.ext), and might destroy the LFN if you do certain things with the 
files (such as moving to another dir) - they were made before LFNs existed.

Besides, even with just 8.3, that's 11 bytes that can be chosen pretty much 
arbitrarily (only a few values you can't use); for most purposes you don't 
need even that, and can put conventions into place (such as using a specific 
.ext for specific file types).

Personally, I see no reason why the wikireader should need more than 8.3 
filenames, at least for the kernel to know what app to start, or the reader app 
to find its data files.


> > (2) How complicated will it be to implement subdirectory support?
>
> Not a problem. We're going to do something like this when we support
> more languages.

That certainly seems like both the easiest and most sensible approach.


> > Note that only one subdirectory level is really needed to implement what
> > has already been suggested.

This is kind of interesting in a way. The first DOS versions (that supported 
directories at all) only supported one level. :)


> > We could adopt a brain-swap approach:  After bootup, the user selects
> > one wiki and then the app switches to the selected subdirectory and
> > considers that to be the root until the next cold boot.  All 81 files

> > kernel.elf.  Only the initial wiki selection app (we would have to write
> > one) would have to understand subdirectories, and only to one level deep.
>
> Yeah that should work.

I thought of the same, and afaik there's just one small gotcha (not really a 
problem though): subdirectories are not quite the same on-disk as the root 
directory.

The format of the data in the directories is the same, sure. But 
subdirectories are stored the same way files are - in a chain of clusters - 
while the root directory is a specific area on the disk, determined at FS 
creation time. This is why the root directory has a limited number of files it 
can hold, while subdirectories don't.

So, the code reading the directory entries from the disk still has to know if 
it's reading the root dir or a subdirectory, to know where on the disk to load 
the entries from. The code parsing those entries can be the same though.

One way to simplify this could be to *always* keep apps such as the wikireader 
in a subdirectory, never in the root directory, as then only the app selector 
needs to know how to read the root dir.

Of course, if the filesystem reading/parsing code is provided by the kernel, as 
a service to the programs, it could take care of this (rather small) difference 
under the hood, without each app having to deal with it on its own - that 
seems much more sensible to me, since it needs to know how to read FAT anyway.


That could also open up another intriguing possibility... Copying the app 
selector into a subdir that has subdirs of its own. From the POV of any app 
that doesn't understand directories, it doesn't really matter how deep it is, 
and even if it does understand them, it still doesn't matter as long as the 
current directory is considered the root and the .. directory is ignored.

Then, if the selector was implemented so that it could switch root to the .. 
directory and (re)start that app, you could even move up again in the tree...

Well, this all assumes the "root" subdir selection is done by keeping the 
cluster number or some such (as opposed to keeping the path by name).


--
Frode Austvik

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

Re: [All] Black Screen of Death - Won't resume from standby

[Steven **]

I don't have omnewrotate nor do I ever use GPS.  So, I don't think
those are the cause.

Now, I'm sure my phone switches towers occasionally.  And I have an
extreme case of the recamping issue.  I maybe see it more often with
Android-on-Freerunner now that they're doing an adaptive deep-sleep
(which I had disabled on SHR-Unstable).  Or that could just be bad
luck...

-Steven

On Sat, Oct 31, 2009 at 1:04 PM, Matthias Huber
 wrote:
>  31.10.2009 18:03,   Warren Baird :
>
> I just started noticing this on an shr-u build updated in early sept.   The
> only thing I've changed lately is installing omnewrotate.   I also noticed
> it on an install of the shr-testing candidate, that also had omnewrotate
> installed.
> I'm going to keep omnewrotate installed for a while and see how often I get
> the BSOD. Then I'll uninstall or disable omnewrotate and see what happens.
>
> i have actually no omnewrotate installed, but i had some time ago.
>
> On Sat, Oct 31, 2009 at 4:27 AM, Matthias Huber
>  wrote:
>>
>> Steven ** schrieb:
>> > I've seen this several times with SHR-Unstable and now with Android.
>> > So, I'd say it's something that is common among these distro's.  Is it
>> > seen on all distros?  Is it the kernel?  Hardware bug?  Bootloader
>> > issue?
>> > Any clues how to debug this or what might cause it?
>> >
>> > I know I'm not the only one that sees it.  How are others dealing with
>> > these random lock-ups?
>> >
>> >
>> i have this too with my system gta02v6 latest shr-u.
>> sometimes i thought, it has to do with gps, but i am not sure about.
>> sometimes i think, problem it is changing cell while sleeping.
>
>
> ___
> 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: [All] Black Screen of Death - Won't resume from standby

[Matthias Huber]

31.10.2009 18:03,   Warren Baird :
I just started noticing this on an shr-u build updated in early 
sept.   The only thing I've changed lately is installing 
omnewrotate.   I also noticed it on an install of the shr-testing 
candidate, that also had omnewrotate installed.
I'm going to keep omnewrotate installed for a while and see how often 
I get the BSOD. Then I'll uninstall or disable omnewrotate and see 
what happens.

i have actually no omnewrotate installed, but i had some time ago.
On Sat, Oct 31, 2009 at 4:27 AM, Matthias Huber 
> wrote:


Steven ** schrieb:
> I've seen this several times with SHR-Unstable and now with Android.
> So, I'd say it's something that is common among these distro's.
 Is it
> seen on all distros?  Is it the kernel?  Hardware bug?  Bootloader
> issue?
> Any clues how to debug this or what might cause it?
>
> I know I'm not the only one that sees it.  How are others
dealing with
> these random lock-ups?
>
>
i have this too with my system gta02v6 latest shr-u.
sometimes i thought, it has to do with gps, but i am not sure about.
sometimes i think, problem it is changing cell while sleeping.



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

Re: SHR-U wifi problem!!

[Aditya Gandhi]

 Thanks I do use wep

On Sat, Oct 31, 2009 at 9:16 PM, Mario Huelsegge  wrote:

>
>
> Aditya Gandhi wrote:
> >
> >
> >> I dont know about encryption problems
> >> And its recursive even after reboot
> >> The aux buttin red led starts blinking after about 5-10 secs
> >>
> >
>
> I got the same problem with mokonnect using wep encryption (blinking aux
> light). After switching to wpa2 mokonnect worked without problems. so it
> seems to be a problem with encryption.
> --
> View this message in context:
> http://n2.nabble.com/SHR-U-wifi-problem-tp3920986p3924188.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
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [All] Black Screen of Death - Won't resume from standby

[Warren Baird]

I just started noticing this on an shr-u build updated in early sept.   The
only thing I've changed lately is installing omnewrotate.   I also noticed
it on an install of the shr-testing candidate, that also had omnewrotate
installed.

I'm going to keep omnewrotate installed for a while and see how often I get
the BSOD. Then I'll uninstall or disable omnewrotate and see what happens.

Warren


On Sat, Oct 31, 2009 at 4:27 AM, Matthias Huber <
matthias.hu...@wollishausen.de> wrote:

> Steven ** schrieb:
> > I've seen this several times with SHR-Unstable and now with Android.
> > So, I'd say it's something that is common among these distro's.  Is it
> > seen on all distros?  Is it the kernel?  Hardware bug?  Bootloader
> > issue?
> > Any clues how to debug this or what might cause it?
> >
> > I know I'm not the only one that sees it.  How are others dealing with
> > these random lock-ups?
> >
> >
> i have this too with my system gta02v6 latest shr-u.
> sometimes i thought, it has to do with gps, but i am not sure about.
> sometimes i think, problem it is changing cell while sleeping.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
Warren Baird - Photographer and Digital Artist
http://www.synergisticimages.ca
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Navit - german localization causes rounding of GPS-position

[Christian Rüb]

Hi,

I had the same problem. Also bookmarks will be saved using comma instead of dot 
a separator (locale settings).
As a workaround I unset LC_ALL before starting navit (i.e. "Exec=unset LC_ALL; 
navit" in /usr/share/applications/navit.desktop).
That way your LANG variable keeps set to de_DE.UTF-8, but locale settings are 
not in German...

I posted this in navit ML back in July - but no response if this is intended or 
a bug :(

Cheers,
 Christian

Am Samstag, 31. Oktober 2009 schrieb Mirothanus:
> 
> Hi everybody,
> 
> I have successfully localized my Navit to speak German I thought.
> 
> Using SHR on my FR, I have installed every necessary localization packages
> (i.e. navit-locale-de and locale-base-de-de) and all speed-dispatcher
> packages. To start Navit I use the navit.sh - script from the wiki.
> 
> If I use Navit in English (i.e. the main language of SHR is set to EN) or
> don't use the script, everything works smoothly, the GUI is in English, my
> GPS-position is found and the speech-dispatcher leads me in English to my
> destination.
> 
> But if I set the SHR-Language to DE-de and use the script to start the
> localized Navit, something goes terribly wrong. The GUI is in German,
> alright. Spd-say seems to speak German, alright. But one thing is wrong: my
> GPS-Position!
> 
> At the moment I'm at 50°59"24 N 09°01"04 E. But Navit thinks I am at
> 50°59"59 N 8°59"59 E. That's far-off my position! TangoGPS and other
> GPS-apps report my correct position. If I change the street, for example,
> nothing changes in Navit.
> 
> I guess that in the course of localization, the floating-point-number of my
> position is mangled and thus reported incorrectly to Navit.
> 
> How can I solve this problem?
> 
> Yours sincerely,
> Christoph
> 


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

Re: ffalarms 0.3.1 -- bug fix and editing of non recurring alarms

[Bernd Prünster]

jeremy jozwik wrote:
> 2009/10/31 Łukasz Pankowski :
>   
>> - make puzzle digits twice bigger for without glasses readability
>> 
>
> i like this one, works well.
>   
isn't the point of the puzzle that you cannot read it unless you are 
fully awake?

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

Re: SHR-U wifi problem!!

[Mario Huelsegge]

Aditya Gandhi wrote:
> 
> 
>> I dont know about encryption problems
>> And its recursive even after reboot
>> The aux buttin red led starts blinking after about 5-10 secs
>>
> 

I got the same problem with mokonnect using wep encryption (blinking aux
light). After switching to wpa2 mokonnect worked without problems. so it
seems to be a problem with encryption.
-- 
View this message in context: 
http://n2.nabble.com/SHR-U-wifi-problem-tp3920986p3924188.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

Navit - german localization causes rounding of GPS-position

[Mirothanus]

Hi everybody,

I have successfully localized my Navit to speak German I thought.

Using SHR on my FR, I have installed every necessary localization packages
(i.e. navit-locale-de and locale-base-de-de) and all speed-dispatcher
packages. To start Navit I use the navit.sh - script from the wiki.

If I use Navit in English (i.e. the main language of SHR is set to EN) or
don't use the script, everything works smoothly, the GUI is in English, my
GPS-position is found and the speech-dispatcher leads me in English to my
destination.

But if I set the SHR-Language to DE-de and use the script to start the
localized Navit, something goes terribly wrong. The GUI is in German,
alright. Spd-say seems to speak German, alright. But one thing is wrong: my
GPS-Position!

At the moment I'm at 50°59"24 N 09°01"04 E. But Navit thinks I am at
50°59"59 N 8°59"59 E. That's far-off my position! TangoGPS and other
GPS-apps report my correct position. If I change the street, for example,
nothing changes in Navit.

I guess that in the course of localization, the floating-point-number of my
position is mangled and thus reported incorrectly to Navit.

How can I solve this problem?

Yours sincerely,
Christoph
-- 
View this message in context: 
http://n2.nabble.com/Navit-german-localization-causes-rounding-of-GPS-position-tp3924154p3924154.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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[The Rasterman]

On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber
 said:

> Carsten Haitzler (The Rasterman) schrieb:
> > On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber
> >  said:
> >
> >   
> >> Laszlo KREKACS schrieb:
> >> 
>  To not confuse with window changing, I would suggest the following
>  scenario:
>  1. double click for launching an app
> 
> 
>  why double click ? for me, i am using double click for a menu and a
>  single click for starting the app.
>  
>  
> >>> Because when sliding, you can have accidental clicks. I know it from
> >>> the hard way.
> >>> (I came up a nice usability workaround in paroli exactly for this
> >>> issue. It works good.)
> >>>   
> >>>   
> >> yes i know this also from paroli. but it is solvable i think.
> >>
> >> openbox has a tunable parameter for distinguish between slide and click.
> >> in my oppinion, this is highly usable.
> >>
> >> i personally find a single click more elegant and usable than double click.
> >> 
> >
> > the problem is not differentiating between slide and click - e and
> > elementary have this too. it's that if you drag horizontally for example,
> > your actual events often look something like:
> >
> > ++ +--+ +--+   +-+ ++-++ +--+ + +   +   +---+
> >   
> that's exact what i told you, what openbox has: they say: if movement < 
> number_pixels then its click,
> if movement >= pixels, its slide.

and that's what i told you e and elementary have too. the problem is your
finger moves the entire length of that line. the actual input events you see
are the discontinuous stutters as above. see the "+" by itself? that's a press
+release on the same spot.

> in your case, one could hava a hysteresis over the time: if a single 
> click comes shortly after a slide,
> it is part of slide.

that's what i said... and it should be done in tslib/x - every toolkit and app
should not have to go implement this again and again. the lower layers should
sanitise input by the time it gets to x clients.

> if you measure now the time of the tap, you have all you need for 
> differentiating between all this three events.
> 
> generally i think, its better to get the btn-release instead of 
> btn-down. (from the view of windowmanager)
> 
> and you are right: it should be done in tslib or window manager.

well not wm. wm's dont intercept or modify events in any way. each x app (the
wm, or the app listening to the events on the window where the events are
going) gets them. so the choice is. 1. every toolkit+app does it (every game
using sdl, every "GL" app (tho this is hypotherical - this is just the general
case, not gta02), elementary, e, gtk, qt - they all need to repeat the same
logic to filter these.

elementary and e have logic to know the difference between a tap and a drag.
the values are configurable and tunable. the problem is all the "dirty input".

-- 
- 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[The Rasterman]

On Sat, 31 Oct 2009 11:38:59 +0100 Michal Brzozowski  said:

> 2009/10/31 Carsten Haitzler 
> 
> > you pressed just once - or you think you did. but you actually had a press,
> > a
> > release, and a press , release etc. again because your pressure went above,
> > below and above the "pressure level" needed to register a click.
> >
> 
> What's the "pressure level"? Is it in the the hardware? Is it possible to
> adjust it?

nothing in software i have seen. if it was possible it would have been adjusted
long ago... the driver already has code to de-jitter the input (smooth it out)
it may as well de-jitter the temporal information too.

-- 
- 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[The Rasterman]

On Sat, 31 Oct 2009 09:34:17 +0100 Laszlo KREKACS
 said:

> On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber
>  wrote:
> > that's exact what i told you, what openbox has: they say: if movement <
> > number_pixels then its click,
> > if movement >= pixels, its slide.
> >
> > in your case, one could hava a hysteresis over the time: if a single click
> > comes shortly after a slide,
> > it is part of slide.
> >
> > if you measure now the time of the tap, you have all you need for
> > differentiating between all this three events.
> >
> > generally i think, its better to get the btn-release instead of btn-down.
> > (from the view of windowmanager)
> >
> > and you are right: it should be done in tslib or window manager.
> 
> In that case you just killed any application which are drawing oriented.
> So no Xournal, Sketchbook or any such application.

no you didnt. your stroke would go from the dotty broken one to a continuous
one - like your finger actually traced on the screen. the sensors just didnt
pick it up.

-- 
- 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: ffalarms 0.3.1 -- bug fix and editing of non recurring alarms

[jeremy jozwik]

2009/10/31 Łukasz Pankowski :
> - make puzzle digits twice bigger for without glasses readability

i like this one, works well.

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

Re: kbosd, or fatfingereverything

[Michal Brzozowski]

2009/10/31 

> So the OSD keyboard inspired by fatfingershell is now quite
> nice and useable, especially since the addition of user feedback
> using vibrator (due to Radics Áron). Also, you can now configure
> the keyboard layout to your will using a simple configuration
> file.
>

I'm curious and would like to try it out. Could you make an ipk for SHR too?

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

ffalarms 0.3.1 -- bug fix and editing of non recurring alarms

[Łukasz Pankowski]

Vikas Saurabh  writes:

>> r...@om-gta02 ~ $ ffalarms
>> icalerror.c:99: BADARG: Bad argument to function
>> ffalarms: icalerror.c:100: icalerror_set_errno: Assertion `0' failed.
>> Aborted
>> r...@om-gta02 ~ $
>>
>> any ideas?
> It happened to me as well...and its probably you have got an empty
> .ffalarms/alarms file in your home directory. Just delete the file and
> the app would come up again.
>
> I was about to report it...I guess empty file should be handled gracefully

Thanks for discussing the problem, fixed in 0.3.1
(download: http://projects.openmoko.org/frs/?group_id=260&release_id=581)

Notes:
- bug fix: handle empty ~/.ffalarms/alarms file
  (thanks to jeremy jozwik and Vikas Saurabh for discussing the issue
   on the community mailing list)

- add editing of non recurring alarms

- make puzzle digits twice bigger for without glasses readability

>
> --Vikas

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

kbosd, or fatfingereverything

[rixed]

So the OSD keyboard inspired by fatfingershell is now quite
nice and useable, especially since the addition of user feedback
using vibrator (due to Radics Áron). Also, you can now configure
the keyboard layout to your will using a simple configuration
file.

You have a debian package (that's specially tailored for H:1) here :

http://happyleptic.org/~rixed/kbosd_20091031_armel.deb

And the source code and everything else there :

http://gitorious.org/kbosd/

Don't forget to 'man kbosd' if you want to change anything to
the default parameters.

This is no more a proff of concept but also my default everyday
keyboard. Enjoy!



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

Re: QtMoko - FBreader?

[foringer]

You can run FBreader from QX menu. Open QX, in the left down corner tap
the screen, select Favorites and check E-book reader.

Tips: you can add QX menu to the Favorites, to quickly access its
applications.

Sorry for ugly english, I'm not a native speaker


В Птн, 30/10/2009 в 19:32 +0100, Torfinn Ingolfsen пишет:
> Ok, I have installed FBreader (with apt--get).
> Now, How do I get an icon / menu entry to start it from on my QtMoko
> v14 dektop?
> -- 
> Regards,
> Torfinn Ingolfsen
> ___
> 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[Michal Brzozowski]

2009/10/31 Carsten Haitzler 

> you pressed just once - or you think you did. but you actually had a press,
> a
> release, and a press , release etc. again because your pressure went above,
> below and above the "pressure level" needed to register a click.
>

What's the "pressure level"? Is it in the the hardware? Is it possible to
adjust it?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Paroli : migrating SIM contacts

[Xavier Cremaschi]

Hi folks,
reverse problem now : I want to migrate contacts from paroli to VCF.

What would be the best solution for me ?

Thanks,
Xavier.


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

Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[Matthias Huber]

Laszlo KREKACS schrieb:

On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber
 wrote:
  

that's exact what i told you, what openbox has: they say: if movement <
number_pixels then its click,
if movement >= pixels, its slide.

in your case, one could hava a hysteresis over the time: if a single click
comes shortly after a slide,
it is part of slide.

if you measure now the time of the tap, you have all you need for
differentiating between all this three events.

generally i think, its better to get the btn-release instead of btn-down.
(from the view of windowmanager)

and you are right: it should be done in tslib or window manager.



In that case you just killed any application which are drawing oriented.
So no Xournal, Sketchbook or any such application.


  


why do you think so ?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[Laszlo KREKACS]

On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber
 wrote:
> that's exact what i told you, what openbox has: they say: if movement <
> number_pixels then its click,
> if movement >= pixels, its slide.
>
> in your case, one could hava a hysteresis over the time: if a single click
> comes shortly after a slide,
> it is part of slide.
>
> if you measure now the time of the tap, you have all you need for
> differentiating between all this three events.
>
> generally i think, its better to get the btn-release instead of btn-down.
> (from the view of windowmanager)
>
> and you are right: it should be done in tslib or window manager.

In that case you just killed any application which are drawing oriented.
So no Xournal, Sketchbook or any such application.


Laszlo

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

Re: [All] Black Screen of Death - Won't resume from standby

[Matthias Huber]

Steven ** schrieb:
> I've seen this several times with SHR-Unstable and now with Android.
> So, I'd say it's something that is common among these distro's.  Is it
> seen on all distros?  Is it the kernel?  Hardware bug?  Bootloader
> issue?
> Any clues how to debug this or what might cause it?
>
> I know I'm not the only one that sees it.  How are others dealing with
> these random lock-ups?
>
>   
i have this too with my system gta02v6 latest shr-u.
sometimes i thought, it has to do with gps, but i am not sure about.
sometimes i think, problem it is changing cell while sleeping.

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

Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[Matthias Huber]

Carsten Haitzler (The Rasterman) schrieb:

On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber
 said:

  

Laszlo KREKACS schrieb:


To not confuse with window changing, I would suggest the following
scenario:
1. double click for launching an app


why double click ? for me, i am using double click for a menu and a single
click for starting the app.



Because when sliding, you can have accidental clicks. I know it from
the hard way.
(I came up a nice usability workaround in paroli exactly for this
issue. It works good.)
  
  

yes i know this also from paroli. but it is solvable i think.

openbox has a tunable parameter for distinguish between slide and click.
in my oppinion, this is highly usable.

i personally find a single click more elegant and usable than double click.



the problem is not differentiating between slide and click - e and elementary
have this too. it's that if you drag horizontally for example, your actual
events often look something like:

++ +--+ +--+   +-+ ++-++ +--+ + +   +   +---+
  
that's exact what i told you, what openbox has: they say: if movement < 
number_pixels then its click,

if movement >= pixels, its slide.

in your case, one could hava a hysteresis over the time: if a single 
click comes shortly after a slide,

it is part of slide.

if you measure now the time of the tap, you have all you need for 
differentiating between all this three events.


generally i think, its better to get the btn-release instead of 
btn-down. (from the view of windowmanager)


and you are right: it should be done in tslib or window manager.

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

Re: [wikireader]Error on ArticleParsing.py

[David Reyes Samblas Martinez]

2009/10/31 Sean Moss-Pultz :
> On Sat, Oct 31, 2009 at 4:00 AM, David Reyes Samblas Martinez
>  wrote:
>> Man, you forget a "," in line 49 on 
>> host-tools/offline-renderer/ArticleParser.py
>>
>> (re.compile(r'&([a-zA-Z]{2,8});', re.IGNORECASE), r'&\1;'),<---Here!
>>
>>    # change % so php: wr_parser does not convert them
>>    (re.compile(r'%', re.IGNORECASE), r'%25')
>
> Stange. We must not have pushed the right changes. Sorry about that!
>
>  -Sean
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
Yes I can confirm it still failing to parse the spanish wikipedia ,
please notify when the correct changes has been summited :)

David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable & embedded solutions
Openmoko, Openpandora,  Arduino
Hey, watch out!!! There's a linux in your pocket!!!

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