Re: Replace battery in suspend

2009-05-09 Thread Hendrik Siedelmann

2009/5/9, Christian Rüb

 is it possible to do the following:
  * power off GSM
  * suspend
  * plug external USB power supply (can do 100,500 and 1000mA)
  * open device and exchange battery
  * resume again
  * power on GSM
  * (optional) unplug USB power supply

Just exchange the battery when on usb power (500mA is enough). No need
to suspend or even disable gsm/gps/screen ...


Openmoko community mailing list

Re: SHR first impression : it's slow ?

2009-02-27 Thread Hendrik Siedelmann
2009/2/27, Johny Tenfinger
 On Fri, Feb 27, 2009 at 21:26, Marco Trevisan (Treviño) wrote:

 No - it should be:

x11-16, x16, software-16-x11, software_16_x11
will all work ...


Openmoko community mailing list

Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)

2009-02-26 Thread Hendrik Siedelmann
2009/2/26 Helge Hafting
 Joel Newkirk wrote:
 On Wed, 25 Feb 2009 12:43:59 +0100
 Helge Hafting wrote:

 Joel Newkirk wrote:

 As I said, I'm guessing, but when I removed the extra PNG images and
 leav just one, enlightenment average CPU drops and the display is more
 responsive. The glass button effect /is/ applied to every icon,
 it's just that the parts ('parts' in edc syntax) relevant to the effect
 are flagged as non-visible by default.  I'm assuming that even when a

 Urrgh - such inefficient coding. Making a 'movie' per icon - every time
 - and just not showing it for most of them. :-( The sane way is to only
 do the _needed_ calculations. Either animate a single icon when the
 effect is actually used, or generate all the frames once and just store
 them till needed. I wonder how they come up with such stuff. This is not
 only a problem on weak processors - it wastes energy on the good ones as
 well. :-(

Perhaps you should have alook at the efl before stating such things.
I also don't have much insight, but thats what I think I understood:
The non-visible parts shouldn't need any but size caclculations, the layering
and stuff is also reasonably fast, at least much faster than what the FR can
transfer to the screen anyway. I think the main proplem is the scaling, smooth
scaling is pretty slow, there is a scale cache planned, but not actually
finished, when it comes things will get much faster.
The efl are way faster than any other toolkit I know of, especially if you trim
down theming.

 Maybe we ought to use a modified duke nukem as an app launcher interface
 instead of enlightenment. Duke has a _better_ framerate for scrolling
 and zooming - in 3D!

Well does it do alpha? And is it using the screen in 480x640 or only a quarter
the screen size?

 Shoot at icons to start apps. Fire at the process list to kill. kill -9
 using a bigger gun.  ;-)

   Wonderful feature
 to have, but I suspect that the calculations involved in this scaling
 and other nice effects E offers are at least a slight detriment to the
 (integer) FR user experience...

 I wish people though more about efficiency. One can have all sorts of
 wonderful effects by precomouting some stuff _once_, and then use plain
 bit block transfers. 1990 game machines was weaker than the FR, but that
 did not seem to be a problem then.
Really have a look at the EFL, very efficient.
Problem is, the Theme just needs to be optimized. And using the
16-bit engine also gives a huge speedup.
 If you watch an icon closely when you press your stylus against it, you
 can usually perceive the fade-in taking place, particularly if your FR
 is straining, in which case you can sometimes see a few distinct delayed
 steps.  The linear transition is set to occur in 0.2 seconds fading in,
 and 0.1 seconds fading out - so it is quite brief.  I believe it
 abides by the Framerate setting in Illume config (the spanner), such
 that a 30fps setting and a 0.2 second fade equal a 6-frame animation.

 I have now set the framerate to its minimum of 5, and turned off
 animations where I could. At least the keyboard appears more quickly now.
If it can't cope with the high framerate it will of course simply drop frames.
And for parts it will easily hit 30 fps, that's why I leave it on default
(but disable some animations).

 Icon animation and only two icons - selected and

 Thanks for the encouragement. :)  It's already improved my user
 experience, but in my poking about I've broken things as well, which is
 why I'm not offering the .edj to anyone yet.  I plan to start from a
 clean extraction from illume.edj and default.edj once more, applying
 only the changes confirmed to be beneficial and not cause E to segfault.

 I hope this will go into the distributions, at least as a selectable
 alternative. Eye candy is nice - but only as long as it doesn't create
 performance problems.

 Scrolling is slow enough even if I grab the iconless corner - so that no
 icon actually change state. (None was selected, none became selected)
 But of course it is still slow if all those icons have to be scaled 9
 times or so before drawing the screen.

 But at the pace I'm going that'll be a couple weeks still.  Hopefully
 at that point I'll be able to offer tarball and ipk versions of the
 theme for both enlightenment in general and for elementary (shr-dialer
 and kin, paroli, Raster's alarm, shr-config, etc all use elementary) as

 Take your time. Ideally, a beta release whenever one more performance
 killer is chopped off. If it isn't too much extra work.
 below are lines 14053 through 14438 of 'default.edc', inside
 'default.edj', this copy extracted from FSO M5 IIRC but I believe the
 same utilized in SHR. At the top it specifies what images are required
 for this 'group', which defines a single icon on the desktop. (Illume in
 our case) It also uses 'pager_base2.png' which is defined in a 

Re: Questions about the usability of GTA02

2009-01-31 Thread Hendrik Siedelmann
2009/1/31 arne anka
 1st) Battery Power
 So, since i'm not able to plug the phone to a power source at university,
 would i be able to run it the whole day, without getting out of battery
 power after 10 hours?

 not with the scenario you describe -- but otoh: which phone does? your
 power consumption seems pretty impressive to me and with a phone more
 suited to doing that stuff (that said, i don't know what phone you are
 currently using, but assume something more traditional).

I'm pretty sure it will. If I do zero calls and messages, but often look at the
clock the FR will last 3 workdays (being empty at the third evening).
With I use it for some hours a day (wlanm gps, ...) it gets half empty
in one day.
I think the highest power consumption comes from the screen.
APM says it will last 5h with screen at full brightness, and around 12 h
with screen disabled. Don't forget that's both without suspending!
With wlan enabled this will be somewhat shorter, but it shouldn't be a problem
to get more than 2h browsing and 2h music out of it.


Openmoko community mailing list

Re: Conflict when several apps use the accelerometers?

2009-01-27 Thread Hendrik Siedelmann
2009/1/27, Helge Hafting
 Gunnar Aastrand Grimnes wrote:
 This page does:

 Noise is around 3cm/s^2, i.e:

 It can fill in _short_ - 3-5s gaps in GPS coverage, if the orientation
 of the phone is known.

 Not enough for a 4km tunnel then, which is 3 min when going 80km/h.
 5s is enough for a 111m tunnel, but 5s signal loss is usually not a
 problem anyway.

 Of course, the car speedometer readout can take care of speed and
 braking/acceleration, the accelerometer would only be needed to notice
 turning. Could be interesting to see where it thinks I am after 3 min,
 if 5s is all I can expect. I guess those 3-5s is the interval where
 precision matces the gps. But it will be useful for longer than that, as
 long as estimate is more accurate than stopped at the tunnel entrance.

 The error increase with time, but so do the real distance from the entrance.

 Helge Hafting

Yes, I too think it would be useful for a longer period. In a time of
3-5 seconds one could propably get away with simply projecting the
route at signal loss with constant speed. And I think navit snaps to
streets anyway, so it wouldn't matter if its off by a bit.

Openmoko community mailing list

Re: [omview] images not diplayed

2009-01-09 Thread Hendrik Siedelmann
2008/12/24 Marc Bantle
 Hi all,

 I'm running omview r32 on om-testing and
 trying to display some JPG pictures taken with
 a canon digicam in 2592x1944 resolution.

 The images are not displayed, only their names.

 Thumbnails  are produced on startup as png-files.

 Here's the console output:
 r...@om-gta02:~# omview --ewl-evas-xrender-x11 --ewl-theme ewl_om
 connect(): No such file or directory
 connect(): No such file or directory
 connect(): No such file or directory
 connect(): No such file or directory
 connect(): No such file or directory
 Failed to connect to server
 mouse down 253x187
 mouse down 130x331
 exec 0 action
 mouse down 267x253
 mouse down 247x514
 mouse down 244x167
 mouse down 273x68
 mouse down 154x243

 What's that server, the connection to which fails?

the Failed to connect to server message means omview can't connect
to epsilon_thumbd which it tries to start but is seems it doesn't find
Can you start the epsilon_thumbd program by hand and launch omview afterwards?
It should be in the libepsilon_tests package (it's a dependency of the
ipk from repository).
And from where is the package of omview you use?
It's a bit late, I hope omview wasn't broken the whole time with the
om-image ...


Openmoko community mailing list

Re: rcp works, konqueror+fish not

2008-10-22 Thread Hendrik Siedelmann
2008/10/22 Aapo Rantalainen [EMAIL PROTECTED]:
 I can rcp files from computer to my freerunner, but with konqueror and
 fish:// I can only download not upload. Moko just disconnects when I
 start uploading. Freerunner is running fdom and my computer is running
 Ubuntu: 8.04, Qt: 3.3.8b, KDE:3.5.9, Konqueror: 3.5.9.

 I just installed Debian on Freerunner and now konqueror+fish works, so
 I think it is about dropbear, not konqueror.
 (Debian has Dropbear sshd v0.51and  fdom 0.49, maybe this is the point)

 -Aapo Rantalainen

I don't really know whats the difference, but konqueror+sftp:// works
out of the box on every image I used, so I think the problem is indeed


Openmoko community mailing list

Re: omview is cool!

2008-10-09 Thread Hendrik Siedelmann
2008/10/8 Marcel [EMAIL PROTECTED]:

 I didn't fiddle with my neo for a few weeks now and flashed 2008.8_20080903
 today (which suspends/resumes fine for me, hooray, but settings doesn't
 start yet...) and installed omview because I had heard of it here. I just
 need to say: to whoever made omview, this thing is really cool! Controlling
 it through gestures works fine and it simply does what it's intended to do (I
 think so, from what I know it does).

 Keep that up!

Thanks a lot, nice to hear that. I really took care to make the
program simply work without fiddling, and it's good to hear this is
And yes it does not much, show images. 1:1 zoom on click. That's all.
No hidden features (Ok aside from raw file support - I'm propably the
only one using that).


Openmoko community mailing list

Re: omview is cool!

2008-10-09 Thread Hendrik Siedelmann
2008/10/9 Marcel [EMAIL PROTECTED]:
 Am Thursday 09 October 2008 21:20:42 schrieb Clemens Kirchgatterer:
  May I suggest to let the .dirs to be hidden somehow? If you have a
  lot of applications and you want to navigate through your home it can
  take a lot of time.

 yes, i want sugest this also. and while we are at it. i would prefere
 to let it start in $HOME and/or remember the last directory it was in.

 Yep, that would be useful. :)

Ok hide hidden files is in svn. To remeber the last used directory or
to have a home directory I need to add configuration files. I'll do
this and also add configuration of everything else, but this will take
some time I don't have :(. But don't worry it will come.
For now you can instead add your start directory to the desktop file.

Like this:
In file /usr/share/applications/omview.desktop
Exec=omview --ewl-evas-xrender-x11 --ewl-theme ewl_om /home/user/Documents


Openmoko community mailing list

Re: Illume Theme and E native gold theme

2008-09-13 Thread Hendrik Siedelmann
Neil Caldwell wrote:
as far as i know (new to e17) every program can have its own .edj
(theme) file and OMView is one that does.

It's correct every application can have its own theme, but omview does
(or did) not. It would use the default ewl theme in
/usr/share/ewl/themes/e17.edj (ewl and etk are both toolkits using
the efl). As that was the native gold theme it would look bad. So I
created a simple incomplete theme to mimic illume, which was to be
placed instead of the default theme.

But looking at the downloads most people missed the theme. So in new
releases (r27) I included a stripped down ewl theme file which is
installed in /usr/share/ewl/themes/ewl_om.edj.
When the program gets started with --ewl-theme ewl_om like in the
desktop file it will use that theme.

So for omview simply download the newest version (see wiki). For other
applications check where they get their themes from (search for *.edj)
and then edit those themes, upload them to the wiki or get them
included in the default packages.

Openmoko community mailing list