Re: Replace battery in suspend
hi 2009/5/9, Christian Rüb : > Hi, > > 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 ... hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR first impression : it's slow ?
2009/2/27, Johny Tenfinger : > On Fri, Feb 27, 2009 at 21:26, "Marco Trevisan (Treviño)" > wrote: >> ELM_ENGINE=x16 > > No - it should be: > ELM_ENGINE=x11-16 x11-16, x16, software-16-x11, software_16_x11 will all work ... hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI responsiveness (was Re: SHR first impression : it's slow ?)
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
> unselected.
>
>> 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.
>
> Great!
> 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.
Re: Questions about the usability of GTA02
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. hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
2009/1/27, Helge Hafting : > Gunnar Aastrand Grimnes wrote: >> This page does: http://wiki.openmoko.org/wiki/Accelerometer_Fundamentals >> >> 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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Conflict when several apps use the accelerometers?
2009/1/14 Olivier Migeot :
> On Wed, Jan 14, 2009 at 3:40 PM, VirtuAlex wrote:
>
>> Fully exclusive access is not a solution. It just defeats the purpose of
>> multitasking. Actually I think the window manager should dispatch
>> accelerator events, like it dispatches the mouse events. Only focused
>> application should receive them
>
> Well, unless we decide of a new kind of focus ("accel-focus" or
> something), this should be more flexible. For example, some background
> apps might want to get accel' data : auto-rotation tools (yeah I know,
> the whole point of managing accelerometers through the WM would be to
> bury this practice), HDD-parkers (yeah I know, there's not HDD in
> Neo's), ... Seriously, I can't get anything serious as an example, but
> I think you got my point.
Get higher gps accuracy using accelerometer data (or use it when driving
through a tunnel) would be a nice example.
> This apart, I'm all for the WM-based path. This should be a
> freedesktop standard or something, actually. Or has it more to do with
> Linux' input layer? Or Xorg's? I don't know...
I also don't know which is the best way to get the data to the apps, but we
shouldn't forget that different apps will need the data in different ways:
- as gestures (like keyboard events), this could also be events like
orientation changes
- raw data as often as possible or averaged over small time intervalls
(games, ...)
- preprocessed to give only orientation, or accelleration ...
A point agains the WM way would be that the data should be available over
network, so the FR could be used for example as a joystick. Also there might
be programs that want to use the data without being dependent of an WM-stack.
So perhaps a daemon wich communicates over dbus?
I'm actually thinking of writing one, I want to use accellerometers in omview
and I want to do it the right way.
Needs to be fast though.
hendrik
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [omview] images not diplayed
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 it. 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 projects.openmoko.org/community 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 ... hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: rcp works, konqueror+fish not
2008/10/23 Hendrik Siedelmann <[EMAIL PROTECTED]>: > 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 > fish. > > hendrik > I remember something like this, like if you have no password set sftp will accept any password but not empty, and if you have a password set it will simply work as expected. hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: rcp works, konqueror+fish not
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 fish. hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: omview is cool!
2008/10/9 Marcel <[EMAIL PROTECTED]>: > Am Thursday 09 October 2008 21:20:42 schrieb Clemens Kirchgatterer: >> [EMAIL PROTECTED] wrote: >> > 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 ... hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: omview is cool!
2008/10/8 Marcel <[EMAIL PROTECTED]>: > Hey! > > 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 appreciated. 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). hendrik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume Theme and E native gold theme
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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
