Re: fatfingershell V0.2
c_c wrote: Marco Trevisan (Treviño) wrote: Would be possible keeping the same system but allowing an usage in 480x640 mode? OT - but - what hardware are you talking about? ;-) Sorry I used a wrong term... With system I didn't meant another hardware, just the same software used in a different way, but always in the FR, of course :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
-[ Tue, Oct 27, 2009 at 04:42:21PM +1100, Carsten Haitzler ] but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. It might be dead, but as there is no other free phone I have no choice but to use this one. I can live without fancy graphics anyway (although I can remember a time when I was coding 3d eye candy on much less powerfull hardware, but that's another story). it has no evolution path. You seam to consider gta03 community project as unable to produce anything ? I don't think so. you don't build your world around your first bit of hardware. (...) most games i know of are written to work on the highest end graphics cards at the time. why? by the time the game is out and is selling - everyone has finally upgraded to those cards. We are dealing with 2 different ideas here I believe : what hardware you target when you plan the feature of a future product, and what hardware is required to run a given set of features. You designed E to give good results on bigger hardware (due to the ambitious theme engine if I understood correctly) ; and I believe you that it's probably honestly optimised. You targeted more capable hardware when designing E and I believe it was probably the good choice ! For instance, if I were designing a rendering toolkit now I would certainly not consider anything but OpenGl capable hardware :) I've seen E at work on bigger hardware too, and it seamed allright. The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. Kindly, ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
Carsten Haitzler (The Rasterman) wrote: with linux i'm not lumping in uclinux, elks, etc. as they do come under different names :) notice.. i included desktop... and at least i'd hope to imply that would be the desktop he speaks of... ie how great compiz is and so much better than e17. :) (just using context). Please don't lock on my comparing E vs. Compiz, it was just an example to show how things could be done in different manner, the same as you don't consider uclinux as linux... I didn't say Compiz is better than E per se, I just said on *my* desktop systems E never run as smooth as you claim (and show on your videos) BUT Compiz do. Given that I don't use compiz because simply I don't need fancy windows to browse the web, developing apps and see movies ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. my 2 cents: we can have lighter themes in E (as for example gry is, thanks the author for that!), but then need to have the X11-16 working - at this point, it has been recommended by Raster not to use it and even the new SHR phoneui apps cannot work with X11-16. So we are going back to the even slower engine. Could this be looked at and revised? We need X11-16 for the Freerunner, the 32bit rendering is way too slow on Freerunner. Illume is absolutely unmaintained - as Raster pointed, it hasn't been actively touched for a long time. Please see list of Illume immediate issues [1]. Raster, are you using Illume yourself somewhere? Could Illume get some attention? Otherwise it's going to die with the Freerunner users getting another phones (Pré etc). As i see it, if the above will not happen, users will slowly drift away to solution perhaps not so optimized but feeling lighter and maintained. So the wish for E being THE toolkit for mobile devices will disappear. And we can see this already. SHR has been asked several times for more options in window managers. And as SHR has no manpower to provide this, Debian might start gaining attention, proper deb packaging of FSO will help this a lot. Petr [1] http://wiki.openmoko.org/wiki/Illume#Issues ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: well.. you're telling the one that wrote the graphics code, that has read the glamo hw docs, has worked on it long before freerunner was on sale, who has written graphics code for many platforms, manye cpus of many varying levesl of speed (from 7mhz 68k up), many gpu's from old console hardware to 3d gl... that he's talking bullshit (and being very rude about it, providing no evidence, numbers or anything else to back anything you say up) about exactly the things he's deeply involved in. thus.. you must be an expert beyond my experience and abilites. No and...NO I said I read too much bull**it regarding the approach used when users complains about graphic speed. I didn't say you are a liar or incompetent just your system is not the one, there are many different choices so if another system is faster than yours MAYBE there should be a reason and obviously it's not only Glamo issue. You said E does many more calculations than Qt not me so I simply pointed this doesn't mean me (as a user) MUST accept perfect-fancy-heavy background calculations at the cost of speed and responsiveness. And for this I pointed (yes I was rude but 2 years of the same shut-up you bought a looser device so don't complain messages altered my patience ;) ) that your approach of porting a desktop system to an embedded one it's not as easy as ./configure make make install cross compiling.and for this I talked as a bit competent in embedded devices (not on graphics) development. As a GUI designer and technician you should very well know users perceive responsiveness and usability not background calculation so *seeing from the end user point of view* I can tell Qt is way far faster than E (even if it does less things...) if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... i have been factual, realistic and constructive. i have stated that freerunner is a limited platform. it's one of the slowest (if running at its native resolution i have ever worked on, and i've worked on a fair few. Several months ago I saw a rootfs image you provided as a proof-of-concept of you new gadgets (clock, buttons) and keyboard (IIRC) why simply you didn't ever provide a rootfs with a 240x320 configured screen to show the 4x speed enhancement? I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) ... the users and developers that insist on vga, that they are paying a high price for their insistence. the hardware simply wasnt designed to be optimal on vga. trust me. i've read the glamo docs. vga is the top LIMIT of its capabilities. it's being stretched. these developers ALSO decide the themes they use as part of building SHR for example. the default is a generic default - it's not tuned for really slow systems. Why don't you? You are the only one (and I sincerely believe this) who can know how to optimize things, why don't you show users what they can do instead of telling it's limited, stop? as for e17 not runing on any desktop acceptably. i really have to laugh at that, as i have had it run acceptably on an hp mini-note 2133. 1 ghz via c3. really slow. e is just fine on it. just compile and run. compiz doesn't even start on it. so don't get me started in how wrong you are there. e runs on beagleboards (omap3 - 600mhz) just fine. this is roughly an equivalent machine to the netbook (give or take). I'll send you my desktop PC :P it is all factual and based on imperative results and engineering work. not being an it manager and being rude. you have implicitly called me a liar and have also implicitly claimed i know not of what i speak. No, please read my previous posts, I claimed your approach to end users complaints is of closure. Sorry if you interpreted this as a personal offense. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Xavier :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
-[ Tue, Oct 27, 2009 at 04:37:15PM -0300, Rafael Ignacio Zurita ] there is a new version of fatfingershell (0.2). Trying it on Hackable1, I got : No se pudo iniciar el modo grafico No video mode large enough for 640x480 Apparently it rely on SDL being able to open a 640x480 fullscreen window. Can't it work in portrait mode ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 10:09:36 +0100 Petr Vanek van...@penguin.cz said: As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. my 2 cents: we can have lighter themes in E (as for example gry is, thanks the author for that!), but then need to have the X11-16 working - at this point, it has been recommended by Raster not to use it and even the new SHR phoneui apps cannot work with X11-16. So we are going back to the even slower engine. you dont need it for lighter themes to work. it wont have as good an effect though. but see below. Could this be looked at and revised? We need X11-16 for the Freerunner, the 32bit rendering is way too slow on Freerunner. i'm not going to do anything to the 16bit engine. why? it's 100% parallel code to the 32bit. and it's more work to do it as the format is more complex. every operation is in 16bit or 16bit + alpha plane mask. it doubles maintenance work. i have enough work just making 1 engine fast and maintaining accelerated engines (xrender, gl, ...). :( 32bit engine is much mroe stable and more capable. it is slower. but unless someone steps up to the plate and does the work, it's not going to get done. 16bit engine was never complete from the start, as it was written to make 1 specific app fast, and only what it used was implemented. Illume is absolutely unmaintained - as Raster pointed, it hasn't been actively touched for a long time. Please see list of Illume immediate issues [1]. correct. as it simply hasnt been on a list of priorites in the last year. it's far backburner stuff :) Raster, are you using Illume yourself somewhere? Could Illume get some attention? Otherwise it's going to die with the Freerunner users getting another phones (Pré etc). no it isn't :) trust me on that one. :) nothing to do with freerunner. as for illume - i am not using it. there is an illume2 module in svn that is a skeleton rewrite that just does window arrangement in a very primitive way right now. i don't have time to work on it right now either. As i see it, if the above will not happen, users will slowly drift away to solution perhaps not so optimized but feeling lighter and maintained. So the wish for E being THE toolkit for mobile devices will disappear. And we can see this already. SHR has been asked several times for more options in window managers. And as SHR has no manpower to provide this, Debian might start gaining attention, proper deb packaging of FSO will help this a lot. from that point of view... i'll disagree. you'll know why at some point. :) it'd love to chat about it... but i can't. :( Petr [1] http://wiki.openmoko.org/wiki/Illume#Issues ___ 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: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). -- - 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)
On Wed, Oct 28, 2009 at 10:27 AM, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? Or discrete scrolling. (ie. only scroll by lets say 48px height). Also text only scrolling would be useful to speed up. (most of our scrolling happens on the text). Or dont load the whole text only the first 20 lines of it, and when you hit at the bottom, load the rest of the text. (Im implementing this approach, and I expect better speed of this *workaround* then what elementary provides by default) I do believe that scrolling can be speedup. Especially for texts. I also think that a zoom in/zoom out interface can be also speedier than what the current scrolling is. Ie.you zoom out the texts, and zoom in the other part of it... What I think our hardware shows really its limitation is the animations. But I dont think scrolling falls in that category. Best regards, Laszlo ___ 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)
-[ Wed, Oct 28, 2009 at 11:27:03AM +0200, Michael 'Mickey' Lauer ] [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? Reading an ebook or looking a webpage or a map is better with scrolling I guess. Apart from that, you are right that paging is easier than scrolling for the hardware and for the user as well (scrolling with a finger is fun but not very precise nor fast - I remember having difficulties with H1 scrolling application list, looking for tangogps ; it requires too much attention, especially while driving :)...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Xavier :) Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS a écrit : Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Bye. No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? That as Raster correctly said, default is something that should do everything as-best-as-possible, and default in all E distros is a pain-in-the-a** This is a distro maintainer issue ok but remember I'm talking from the user's point of view and from this point of view it's a matter of E not distro maintainer configuration (given both distros suffer the same problem). And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
This discussion is _very very_ interesting! And for sure we'll have progress... quote: if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... OK, we -as freerunner users- have a lot of patience, we'll see (we need manpower (community power)! wtf!). d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 11:15:46 +0100 Davide Scaini dsca...@gmail.com said: This discussion is _very very_ interesting! And for sure we'll have progress... quote: if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... hehehe :) OK, we -as freerunner users- have a lot of patience, we'll see (we need manpower (community power)! wtf!). d indeed. indeed. :) -- - 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: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 11:00 AM, DJDAS dj...@djdas.net wrote: Xavier Cremaschi wrote: DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. -- Cedric BAIL ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Cedric BAIL wrote: Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). I don't have time too!!! I don't want to write a theme that REMOVES ALL THE FUNCY STUFF! I'd like (did I ever say that?) AS AN END USER to have something by default that demonstrates its capabilities. And at the moment it simply doesn't! As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience. If you are happy to be fooled after believing in this fantastic project, spending money, spending a lot of time you are welcome, I don't and I'll look for everything doable to make this device (and if ever will be another one in the future) better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
-[ Wed, Oct 28, 2009 at 11:38:22AM +0100, DJDAS ] Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience (...) and I'll look for everything doable to make this device (and if ever will be another one in the future) better. Yet somehow tuning illume theme seams too much ? :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 11:38 AM, DJDAS dj...@djdas.net wrote: Cedric BAIL wrote: Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). I don't have time too!!! I don't want to write a theme that REMOVES ALL THE FUNCY STUFF! I'd like (did I ever say that?) AS AN END USER to have something by default that demonstrates its capabilities. And at the moment it simply doesn't! So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. Choice has been make that people prefer fancy stuff over speed, and you are one of them apparently, so the compromise make sense. If you want better perf, switch to another theme and E will feel faster. As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience. If you are happy to be fooled after believing in this fantastic project, spending money, spending a lot of time you are welcome, I don't and I'll look for everything doable to make this device (and if ever will be another one in the future) better. You don't want to solve the problem. You want the world to be like you dream it. But this hardware has limitation that you should take into account, if you don't, you will wast your energy and the energy of others for nothing. And yes, it costs to accept that the hardware we have is not as powerfull as we would like it to be. And yes, it costs to accept compromise. Welcome to the real world. So now, I ask you, what do you propose ? At least raster give you a few possibility. -- Cedric BAIL ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] [Debian] Which MicroSDHC card should I buy to install Debian onto?
I have tried two cards on FR: Kingston C4 8 GB Kingston SDC4/8GB 07 I don't recommend this one. hadn't much kuck with kingston either. i use an 8g sandisk, listed in the wiki. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] building packages
Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) thanks d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Release of xminimokostatus (Part of Minimoko)
matzehuber wrote: i leaved just a new version of xminimokostatus. Improvements: now fully using dbus: - it doen't need external programs for getting status. - signal strenth and provider is now read from dbus-signals, no active poll == http://wiki.openmoko.org/wiki/Minimoko Nice work, I`ve been trying to get openbox to boot on the freerunner (shr-u). How does your Xsession look like? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/New-Release-of-xminimokostatus-Part-of-Minimoko-tp3900428p3904791.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: Centralization of graphical awesomeness
Cedric BAIL wrote: So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. That's exactly what I said in my previous post it's not me that is saying E is the best piece of software, all the others are sh*t and I'm not crying, I worked to optimize my personal distribution based on an old FDOM and it's quite responsive and daily since september 2008, I try always to optimize things and some time share my knowledge with other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Did you see any other posts from me crying my FR is slow and unstable and unresponsive and shi**y and so on? No! I simply wrote yesterday because I saw since last year only messages like you have a bad hardware so what you want? and I don't think it's a good promotion to achieve new customers or developers to the community...so if you tell me that this is the approach I take it on account and will do my work for myself not trying to share my knowledge with a community which rounds only around Raster and SHR like Gods I want to be proactive not simple yell, but I see only people who say Raster is right not trying to study or thinking in a different way... Can you point me at someone who is different from this approach? Choice has been make that people prefer fancy stuff over speed, and you are one of them apparently, Maybe you missed my previous posts, I said exactly the opposite: I don't NEED nor want fancy stuff at the price of speed this is why I don't consider E *FOR ME* a good piece of softwarebecause I prefer to have something responsive and written to be to, especially if its aimed at an embedded device with low capabilities (in general but especially the FR). You don't want to solve the problem. You want the world to be like you dream it. I want a world in which a community shares its thoughts and discovers, not a community which depends on 3-4 people who say I'm right you're wrong, stop! and think them as God in EarthPassiveness is bad, EVER! But this hardware has limitation that you should take into account, if you don't, you will wast your energy and the energy of others for nothing. And yes, it costs to accept that the hardware we have is not as powerfull as we would like it to be. And yes, it costs to accept compromise. Welcome to the real world. I perfectly know this and if you read carefully my previous posts you see exactly what you're writing So now, I ask you, what do you propose ? At least raster give you a few possibility. I'm not a graphic expert, I'm trying to test some stuffs and looking for alternatives, when I'll reach a milestone if you'll be interested I'll share my thoughts... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Release of xminimokostatus (Part of Minimoko)
ajvogel schrieb: matzehuber wrote: Nice work, thank you. I`ve been trying to get openbox to boot on the freerunner (shr-u). How does your Xsession look like? My .Xsession is: exec /usr/bin/openbox-session but the Xsession in /etc/X11 is the standard from shr, wich tests .Xsession as replacement file for any windowmanager (ie illume) the rest is done in /etc/xdg/openbox/autostart.sh (modified for not using this autstart-prog in /usr/lib ) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) So why don't we talk about future? What are we going to do with our brick? d ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] building packages
On Wednesday 28 October 2009, Davide Scaini wrote: Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) SHR is based at shr-project.org, and the link you want is: http://shr-project.org/trac/wiki/Building%20SHR Note that it may not build cleanly at the moment as the devs are concentrating on some major changes in another branch, and the build procedure will change when they pull this branch into unstable soon. SHR uses OpenEmbedded (OE) so development howtos for OE and bitbake will apply to SHR as well. The initial build will take a long time and a lot of disk space. Once that is done, building extra packages that already have bitbake recipes is usually easy: cd /wherever/you/installed/it/shr-unstable . setup-env bitbake packagename If you are using your own repository, update the repository index with: bitbake package-index ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] building packages
Am Mittwoch 28 Oktober 2009 12:10:39 schrieb Davide Scaini: Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) thanks d You can look at this: http://trac.shr- project.org/trac/wiki/Howto%20get%20my%20application%20in%20the%20SHR%20feed Or to build gnuplut, just do: wget http://build.shr-project.org/Makefile make setup cd shr-unstable . ./setup-env bitbake gnuplot Greets Thomas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Davide Scaini wrote: DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Simply because ATM our work (it's not ONLY mine but we are a team of about 10 people) it's not more than a simple prototype, we are hardly working but obviously in our spare time so we prefer to achieve almost an alpha stage before sharing our ideas ;) they're too much a WIP... Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) I'm too interested in what works but more in what we can do to let it work better, it's not a competition, it's a matter of research, sharing ideas and propose, not stopping at what we have here, whining and nothing more (otherwise I would by an HTC with Android if I only wanted a Linux-phone) So why don't we talk about future? What are we going to do with our brick? I think we could do very beautiful things, we need only a couple of months, as I said previously, and then we could speak about how push forward our work :) ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. Personally I don't, but world is beautiful because it's various :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[hard] Need advices
Hi everyone, I just tried to #1024fix buzzfix an A6. When testing, the mic seemed to be cut, so I removed the cap, but the mic still won't work (I can't hear anything on the other phone). Does anybody have already seen something like that ? What Could be wrong ? Do you think removing #1024fix should change something ? Thanks to every answer. AstHrO ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Finally came round to want to try this... :) Am Dienstag, den 27.10.2009, 02:21 +0300 schrieb Paul Fertser: Marcel tan...@googlemail.com writes: I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Manually altering state is needed because you're using deprecated Xglamo. True - I don't want to reflash, so I'm waiting for SHR merging the new stuff into the unstable feed. (Hope opkg doesn't mess up my system during the upgrade then...) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Release of xminimokostatus (Part of Minimoko)
matzehuber wrote: My .Xsession is: exec /usr/bin/openbox-session but the Xsession in /etc/X11 is the standard from shr, wich tests .Xsession as replacement file for any windowmanager (ie illume) the rest is done in /etc/xdg/openbox/autostart.sh (modified for not using this autstart-prog in /usr/lib ) I also tried the ~/.Xsession. However I tried starting the other applications in there as well, similar to what I found on google: /usr/bin/literki /usr/bin/vala-terminal exec /usr/bin/openbox-session Maybe thats whats wrong. Ill try starting things in autostart.sh -- View this message in context: http://n2.nabble.com/New-Release-of-xminimokostatus-Part-of-Minimoko-tp3900428p3904992.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: [SHR] building packages
Wow... it SEEMS simple ;-) thanks. but, as you said, the build procedure will change... so it's better to wait... how can i get informed *when* this will happen? d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Hey there, On Mon, Oct 26, 2009 at 10:50 PM, Pieter Colpaert freep...@gmail.com wrote: Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Bearstech (through me and others) would like to be there to talk about hackable:1 and our forthcoming initiative about open hardware. Plus, I'd also like to be there to talk a bit about SHR/FSO, as well as drink some beers (Mickey, you owe me one!) :-) -- Julien Cassignol http://www.ainulindale.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
ha ha ok, i'll wait. But please, share ;-) ciao d On Wed, Oct 28, 2009 at 12:51 PM, DJDAS dj...@djdas.net wrote: Davide Scaini wrote: DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Simply because ATM our work (it's not ONLY mine but we are a team of about 10 people) it's not more than a simple prototype, we are hardly working but obviously in our spare time so we prefer to achieve almost an alpha stage before sharing our ideas ;) they're too much a WIP... Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) I'm too interested in what works but more in what we can do to let it work better, it's not a competition, it's a matter of research, sharing ideas and propose, not stopping at what we have here, whining and nothing more (otherwise I would by an HTC with Android if I only wanted a Linux-phone) So why don't we talk about future? What are we going to do with our brick? I think we could do very beautiful things, we need only a couple of months, as I said previously, and then we could speak about how push forward our work :) ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. Personally I don't, but world is beautiful because it's various :P ___ 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: FOSDEM2010
Ok mail to fosdem written and our names added to wiki, I would like to have there a OM-showroom brain storming and a presentation/workshop on how to connect FR to other ultra portable devices what to do once conected :) 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!!! 2009/10/27 PieterC freep...@gmail.com: great :) feel free to contact me at any time Pieter On Tue, 2009-10-27 at 11:02 -0700, David Samblas Martinez [via Openmoko Public Mailinglists] wrote: :) :) seems there are at least three request for a Openmoko devroom!! :) Nikolaus do you agree to unify our efforts in one?, I propose use the PieterC request. mine at least I will send a a mail organizers retire mine and agregate to PieterC one. 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!!! 2009/10/27 PieterC [hidden email]: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3900343.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list [hidden email] http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list [hidden email] http://lists.openmoko.org/mailman/listinfo/community __ View message @ http://n2.nabble.com/FOSDEM2010-tp3895254p3900678.html To unsubscribe from Re: FOSDEM2010, click here. -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3902082.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: [SHR] building packages
Al Johnson schrieb: On Wednesday 28 October 2009, Davide Scaini wrote: Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) SHR is based at shr-project.org, and the link you want is: http://shr-project.org/trac/wiki/Building%20SHR Note that it may not build cleanly at the moment as the devs are concentrating on some major changes in another branch, and the build procedure will change when they pull this branch into unstable soon. SHR uses OpenEmbedded (OE) so development howtos for OE and bitbake will apply to SHR as well. The initial build will take a long time and a lot of disk space. Once that is done, building extra packages that already have bitbake recipes is usually easy: cd /wherever/you/installed/it/shr-unstable . setup-env bitbake packagename If you are using your own repository, update the repository index with: bitbake package-index ... and if do don't get this to run like me, you can try (like i sucsessfully did): download: http://downloads.openmoko.org/developer/toolchains/ documentation: http://wiki.openmoko.org/wiki/Toolchain happy compiling ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Hi Michael, i'm also interested in doing teh rework on my own, but on this page http://wiki.openmoko.org/wiki/1024 and related links there are only few images... so can you please post yours when your work is done? thanks d (if you want/can you can contact me directly) On Fri, Oct 23, 2009 at 11:29 AM, Michael Smith michael.sm...@netapps.com.au wrote: On Fri, 23 Oct 2009 21:05:50 +1100 Chris Samuel ch...@csamuel.org wrote: Or Australia ? Hi. I'm in Melbourne too. Needing to buzz fix an A6 I asked a few electronics engineers. I was looking for somebody who would do delicate soldering work for an hourly rate. The consensus from people I spoke to was that while there are a few small businesses who do electronic work, few would be interested in small jobs. A co-worker of mine offered to do the buzz fix for me. This person tends to over rate his ability. I should have remembered this when I agreed for him to do the work. I plan to tool up and redo the soldering on that phone in the next couple of weeks. The problem with little jobs like this is liability. If he stuffs up, who takes responsibility? On small jobs it is impossible to get insurance. So I am going to do a buzz fix soon. The #1024 fix seems more complicated because you have to disassemble parts of the phone which may be hard to put back together. I might try this procedure on the phone which I am going to do the buzz fix on. I can more afford to stuff that one up. I will post the results here: http://glitch.tl/working_with_shr.html Regards, -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services ___ 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: [SHR] building packages
great! d (i'm not trying this now, for sure next week, i'm moving. I'm definitely interested in build some packages for shr and give a hand... and maybe learn some stuff about etk for simple apps) On Wed, Oct 28, 2009 at 1:03 PM, Matthias Huber matthias.hu...@wollishausen.de wrote: Al Johnson schrieb: On Wednesday 28 October 2009, Davide Scaini wrote: Hi guys, i would like to build some packages for shr that i feel i miss (like gnuplot or so... and maybe do some stupid interface, but not in the immediate future). Where do i start? I tried to find a source on the openmoko wiki, but with no sure answers... I'm sure you can give me a simple reference to start ;-) SHR is based at shr-project.org, and the link you want is: http://shr-project.org/trac/wiki/Building%20SHR Note that it may not build cleanly at the moment as the devs are concentrating on some major changes in another branch, and the build procedure will change when they pull this branch into unstable soon. SHR uses OpenEmbedded (OE) so development howtos for OE and bitbake will apply to SHR as well. The initial build will take a long time and a lot of disk space. Once that is done, building extra packages that already have bitbake recipes is usually easy: cd /wherever/you/installed/it/shr-unstable . setup-env bitbake packagename If you are using your own repository, update the repository index with: bitbake package-index ... and if do don't get this to run like me, you can try (like i sucsessfully did): download: http://downloads.openmoko.org/developer/toolchains/ documentation: http://wiki.openmoko.org/wiki/Toolchain happy compiling ! ___ 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: FOSDEM2010
Am Mittwoch, den 28.10.2009, 12:58 +0100 schrieb Julien Cassignol: Hey there, Bearstech (through me and others) would like to be there to talk about hackable:1 and our forthcoming initiative about open hardware. Excellent. Plus, I'd also like to be there to talk a bit about SHR/FSO, as well as drink some beers (Mickey, you owe me one!) :-) For sure! :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Release of xminimokostatus (Part of Minimoko)
ajvogel schrieb: matzehuber wrote: My .Xsession is: exec /usr/bin/openbox-session but the Xsession in /etc/X11 is the standard from shr, wich tests .Xsession as replacement file for any windowmanager (ie illume) the rest is done in /etc/xdg/openbox/autostart.sh (modified for not using this autstart-prog in /usr/lib ) I also tried the ~/.Xsession. However I tried starting the other applications in there as well, similar to what I found on google: /usr/bin/literki /usr/bin/vala-terminal exec /usr/bin/openbox-session Maybe thats whats wrong. Ill try starting things in autostart.sh No, that's totally correct. try the following: /etc/init.d/xserver-nodm stop Xglamo :0 -br -pn -dpi 285 -screen 480x640x16 -mouse tslib vt1 export DISPLAY=:0 openbox # no , look, if you get any error. after that, replace openbox with openbox-session (is a script, in wich you can look) if that runs, all is good, but maybe not your /etc/xdg/openbox/rc.xml have also a look at my files /etc/xdg/openbox/* in: http://openmoko.huber-computer.de/minimoko-diff.tbz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Please Julien add you and you and others to the wiki page :) Nikolaus, Ghislain you too :) Let me make an special recount , Nickolaus(Golden Delicious Computers, Germany), Julien(Bearstech, France) Wim, (kd85,Belgium) I suppose he wants to come is his own country :P Ghislain(openmobile, Netherlands) David(Tuxbrain, Spain) Do you thing we can do some distributors meeting there to talk about comercial stuff??? 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!!! 2009/10/28 Julien Cassignol ainulind...@gmail.com: Hey there, On Mon, Oct 26, 2009 at 10:50 PM, Pieter Colpaert freep...@gmail.com wrote: Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Bearstech (through me and others) would like to be there to talk about hackable:1 and our forthcoming initiative about open hardware. Plus, I'd also like to be there to talk a bit about SHR/FSO, as well as drink some beers (Mickey, you owe me one!) :-) -- Julien Cassignol http://www.ainulindale.net ___ 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: FOSDEM2010
our forthcoming initiative about open hardware. Come one, share with us. We promise to keep it secret. :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Am 28.10.2009 um 13:22 schrieb David Reyes Samblas Martinez: Please Julien add you and you and others to the wiki page :) Nikolaus, Ghislain you too :) Done just before I received your mail. Let me make an special recount , Nickolaus(Golden Delicious Computers, Germany), Julien(Bearstech, France) Wim, (kd85,Belgium) I suppose he wants to come is his own country :P Ghislain(openmobile, Netherlands) David(Tuxbrain, Spain) Do you thing we can do some distributors meeting there to talk about comercial stuff??? Yes, sure - if there are any news from producers to talk about... 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!!! 2009/10/28 Julien Cassignol ainulind...@gmail.com: Hey there, On Mon, Oct 26, 2009 at 10:50 PM, Pieter Colpaert freep...@gmail.com wrote: Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Bearstech (through me and others) would like to be there to talk about hackable:1 and our forthcoming initiative about open hardware. Plus, I'd also like to be there to talk a bit about SHR/FSO, as well as drink some beers (Mickey, you owe me one!) :-) -- Julien Cassignol http://www.ainulindale.net ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
hey On Wed, Oct 28, 2009 at 01:22:10PM +0100, David Reyes Samblas Martinez wrote: Let me make an special recount , Nickolaus(Golden Delicious Computers, Germany), Julien(Bearstech, France) Wim, (kd85,Belgium) I suppose he wants to come is his own country :P Ghislain(openmobile, Netherlands) David(Tuxbrain, Spain) I'll be there, surely, I've been running the Openmoko booth in the past. Last year, the booth was very busy and we should ask for more space, way too many people were hanging out and blocking the hall access. This year, I'll be focussing more on running the Reprap/Makerbot booth, but if you need help to get an Openmoko booth, talk to me (I'm not reading this mailinglist fulltime anymore due to a peak in work and personal things) Do you thing we can do some distributors meeting there to talk about comercial stuff??? Usually on Saturday evening, we go out in group and eat at a restaurant, that makes a great place to talk about all sorts of things. I think in 2009, we had over 50 people at one big table ;-) Wim. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [hard] Need advices
On Wed, Oct 28, 2009 at 11:25 AM, Thomas HOCEDEZ thomas.hoce...@free.fr wrote: Hi everyone, I just tried to #1024fix buzzfix an A6. When testing, the mic seemed to be cut, so I removed the cap, but the mic still won't work (I can't hear anything on the other phone). Does anybody have already seen something like that ? What Could be wrong ? Do you think removing #1024fix should change something ? I've heard of shorts due to the soldering job (it is a pretty small region) causing problems liek that. I've never experienced it, but there was a post on the list a while back about it. I don't believe #1024 could cause the mic issue, as it is in the modem power supply circuit (As I understand it) Best of luck, and double check your buzzfix for shorts. Toaster ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [hard] Need advices
Am 28.10.2009 um 12:25 schrieb Thomas HOCEDEZ: Hi everyone, I just tried to #1024fix buzzfix an A6. When testing, the mic seemed to be cut, so I removed the cap, but the mic still won't work (I can't hear anything on the other phone). Does anybody have already seen something like that ? What Could be wrong ? Do you think removing #1024fix should change something ? During our professional buzz-rework initiative we had approx. 3 devices where the mic was dead after rework. Just removing all components and resoldering (new) ones did help in all cases. So I don't know exactly what the reason was (maybe no contact of a solder point or a short circuit across the capacitor), but it was possible to fix. Propability that it has something to do with the #1024 is very very low (in that case you should not even be able to use the GSM modem). Nikolaus Thanks to every answer. AstHrO ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ 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)
Hi [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? +1 for paging. mind you, I dont need a button for paging, a gesture could do it. which makes it feel very much like scrolling again, but then more solid. $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Hello Marco, --- On Tue, 10/27/09, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Il giorno mar, 27/10/2009 alle 16.37 -0300, Rafael Ignacio Zurita ha scritto: Hello people, there is a new version of fatfingershell (0.2). It is a virtual terminal for Openmoko mobile phones, with a fullscreen keyboard, and sound/screen/vibrator feedback. Nice work! Thanks!, Suggestions and feedback are always welcome. Would be possible keeping the same system but allowing an usage in 480x640 mode? You mean a smaller keyboard? (width 480?), and the same for the terminal?. I am not sure if I can (using the same font) to put 80x24 (columnsxlines), which is the original idea for the shell. Let me know if I am understanding well your idea :) Rafa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS dj...@djdas.net wrote: [...] I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) OK, I was going to try to control myself, but I just can't. I'm one of the people who always pops out of the woodwork to scream when someone suggests that switching to QVGA is a good idea. 1) The iPhone is not QVGA. It's HVGA. Try running a web browser on an iPhone with the bottom half of the display covered with black tape. 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. You are suggesting that feature should be downgraded so that it is effectively worse than what is found virtually every smart phone being currently manufactured. Every other feature of our phones is either no better than average (the GPS, the accelerometers), worse than average (USB 1.1, GPRS), or fucked up by firmware problems (WiFi). Yes, let's make sure the display is substandard too! Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. They did not have access to the hardware components. They did not have a legion of engineers to work on it.There is even less chance that gta02-core or gta03 will have state-of-the-art graphics capabilities. It will be nothing short of a miracle if a community hardware effort ever produces a usable phone, available to the full OM community, at all. IMO the OM software should try to differentiate our device from other smart phones, not produce a half-assed iPhone clone. Forget smooth graphics. Forget kinetic scrolling. Forget transparency. Show a simple, clean array of icons representing the applications which can be launched. Allow the user to set the brightness, screen blank time and suspend time. Stop there. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [hard] Need advices
Dr. H. Nikolaus Schaller a écrit : During our professional buzz-rework initiative we had approx. 3 devices where the mic was dead after rework. Just removing all components and resoldering (new) ones did help in all cases. So I don't know exactly what the reason was (maybe no contact of a solder point or a short circuit across the capacitor), but it was possible to fix. I answer myself : this midday I was worrying about this semi-bricked FR, so I came back to home to do some extra checks. I put my efforts on the small resistor that has to be changed (the vertical one on the bottom left): - I Tried to measure it directly onboard : 0 ohm - seems to be dead. - I shorten it, then tested with a recorder app. I could hear my voice ! So It can be a way to check this one. The shorten resistor cause the recorded sound to be really loud, so I'll put a small resistor (2k) inplace. Hope this can help other people : some other cases have been reported by Bearstech (France). Thank you all for your quicks answers ! My friend will get back its FR fully fixed! P.S. : I didn't remove the 1024Fix while performing those actions. AstHrO ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Hello, --- On Tue, 10/27/09, Łukasz Pankowski lukp...@o2.pl wrote: Rafael Ignacio Zurita rizur...@yahoo.com writes: Hello people, there is a new version of fatfingershell (0.2). (snip) Moreover it is comfortable for fat fingers. Thanks for that, really usable shell. The keyboard lacks only small feature, I tried to run $ mdbus -s org.freesmartphone.otimed and made a typo, and I see right and left cursors (preferable on keys in FN mode) are a must. I can do well with C-p and C-n to browse shell history (as you hit them once or twice), but multiple C-b or C-f to move inside the line to edit it is a pain and unusable. Well, I use bash, and set -o vi, so I can use ESC, and then h j k l for left, down, up, right ;-) But, yes, arrows keys are in my TODO list. Thanks for the feedback. Rafa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Hello, --- On Wed, 10/28/09, ri...@happyleptic.org ri...@happyleptic.org wrote: -[ Tue, Oct 27, 2009 at 04:37:15PM -0300, Rafael Ignacio Zurita ] there is a new version of fatfingershell (0.2). Trying it on Hackable1, I got : No se pudo iniciar el modo grafico No video mode large enough for 640x480 Apparently it rely on SDL being able to open a 640x480 fullscreen window. Can't it work in portrait mode ? Question: the problem looks like you don't have xrandr in Hackable1 right?. If you have, can you rotate the display to landscape? The fatfingershell.sh tries to rotate the display with xrandr first, then runs the ffs binary. Portrait: no yet, and I am not sure if I want a portrait mode. I want a 80x24 shell, and comfortable keyboard. I don't know how to do that in portrait mode yet. Regards, Rafa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Ken Young wrote: DJDAS dj...@djdas.net wrote: [...] I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) OK, I was going to try to control myself, but I just can't. I'm one of the people who always pops out of the woodwork to scream when someone suggests that switching to QVGA is a good idea. 1) The iPhone is not QVGA. It's HVGA. Try running a web browser on an iPhone with the bottom half of the display covered with black tape. 2) The Freerunner has one, and ONLY ONE, feature which is somewhat better than what is found on a typical smart phone. The VGA display. You are suggesting that feature should be downgraded so that it is effectively worse than what is found virtually every smart phone being currently manufactured. Every other feature of our phones is either no better than average (the GPS, the accelerometers), worse than average (USB 1.1, GPRS), or fucked up by firmware problems (WiFi). Yes, let's make sure the display is substandard too! Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. They did not have access to the hardware components. They did not have a legion of engineers to work on it.There is even less chance that gta02-core or gta03 will have state-of-the-art graphics capabilities. It will be nothing short of a miracle if a community hardware effort ever produces a usable phone, available to the full OM community, at all. IMO the OM software should try to differentiate our device from other smart phones, not produce a half-assed iPhone clone. Forget smooth graphics. Forget kinetic scrolling. Forget transparency. Show a simple, clean array of icons representing the applications which can be launched. Allow the user to set the brightness, screen blank time and suspend time. Stop there. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Neo graphics is certainly not as wonderful as you can get with iPhone like devices, but it is certainly far from a disaster. Only real problem I have found is the rate at which images can be displayed, which appears to be related more to SD card and memory access speed than anything else. Still, its usable for looping through pictures. The VGA resolution makes the device as far as I am concerned. Lots of space for a nice application UI, good scrolling, scalable fonts, nice color handling. I do think, however, that its never going to be more than an interesting toy and test platform for ideas for mobile applications. To me, the most interesting feature is it can be used as a portable office, as it can hold quite a bit of data, connects to anything, and when forwarded to a display with modern graphics capabilities, is quite fast and smooth on many applications. Instead of hauling about a portable, you can pop the Neo in your pocket, and not worry about it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] glamo mplayer
On Wednesday 28 of October 2009 03:16:47 Denis Johnson wrote: I want to use my FR to watch a stream from my MythTV recordings using http stream (I think it is mpeg 2) using my wireless. Is the glamo enhanced mplayer available in QtMoko/Denian ? Yes, the binary that QMplayer downloads from internet is using glamo acceleration. Btw QMplayer has also PC version [1]. On your PC you can scan for media and start http server which will offer videos encoded for Freerunner for streaming or downloading. QMplayer in QtMoko can talk with the PC version from it's GUI. [1] http://activationrecord.net/radekp/qmplayer/ Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] mediaplayer issue
On Wednesday 28 of October 2009 03:37:34 Denis Johnson wrote: How does one play a mpeg stream uing a link from qmplayer such as http://192.168.0.105//mythweb/pl/stream/1003/1256644800 You can try the sharing option. But the http parser in QMplayer is very simple - so it will most probably wont work, but the source code is out there and everyone can improve it ;) Another option is starting mplayer from command line or download the file via web browser or wget and play it locally. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS wrote: Xavier Cremaschi wrote: No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? That as Raster correctly said, default is something that should do everything as-best-as-possible, and default in all E distros is a pain-in-the-a** This is a distro maintainer issue ok but remember I'm talking from the user's point of view and from this point of view it's a matter of E not distro maintainer configuration (given both distros suffer the same problem). And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) i'll tell you something about e themes: so you have teh possibility to make everything constist of what you want ant look like you want it. if i have the time i will make you an e theme that uses hardly äny images and as little layers as possible it will be very fast in comparison. best example for single layer atm should be the toolbars in elm and illume using gry* theme, which can be made even faster if you use some tricks (yes i have something specific in mind but i dunno if i'll actually impelent it (no the user wont SEE any desing difference, but the code-wise design would get ugly and i dont think i want that). if you want to theme e you will probably need more time to get into it, but a soon as you are in it you can radiacally change the way it behaves and the way it looks. you have much more possibilites which means moch more potential for optimization the gtk will ever give you, because the desing of gtk limits you VERY MUCH, edje doesn't. i've wrote 3 themes until now (of which 2 have been released third one was playground for exploiting how far one can go using edje, when you see it you'll shit bricks!). i can make gry* even faster, but the them is still in development and there still soem decisions to make before i can start to kick out even the last bit of unneeded stuff (also it gets a little tricky if you try not to use any images and still want to make it look good also testing is required to find out what gives you ultimate speed with nice looks...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Hi Portrait: no yet, and I am not sure if I want a portrait mode. I want a 80x24 shell, and comfortable keyboard. I don't know how to do that in portrait mode yet. http://wiki.openmoko.org/wiki/User:Pike/FFShell that may be radical, but I'm not sure if I find a qwerty layout to be the most comfi too. in the default keyboard in fatfingershell the keys are high rather than wide. I estimate my fingertips are about 160 wide (and 80 high). I found I could use ffshell flawlessly when holding it vertical :-) $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Can't it work in portrait mode ? Question: the problem looks like you don't have xrandr in Hackable1 right?. If you have, can you rotate the display to landscape? Well, we had it for sure, but in the daily build I'm using right now it kills X :) Portrait: no yet, and I am not sure if I want a portrait mode. I want a 80x24 shell, and comfortable keyboard. I don't know how to do that in portrait mode yet. Yeah. The problem is : I would like my keyboard in landscape mode like a real keyboard but I like my terminal in portrait mode like a real sheet of paper. Is it possible ?? :-) Also, I'm a little contraried by the memory footprint of the program, and by the fact that I would like this keyboard for other apps... Anybody already tried to build a OSD keyboard with lib-aosd or lib-xosd ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On 10/28/09, DJDAS dj...@djdas.net wrote: And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Also light themes which already exist - niebiee, nEo and gry* - are available in repositories) Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
how to port a scheme interpreter to om?
hi guys, does anybody has try to port the scheme interpreter(guile,etc) to openMOKO? -- GNU powered it... GPL protect it... God blessing it... regards HFG--Shawn the R0ck ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
one more question about nand
because i hadn't nderstood it in deep: when i would for example do an nand_erase on mtd6 and would make for example an ext3 of it, would this work or is the jffs necessary for writing into nand (mtd6) ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: one more question about nand
because i hadn't nderstood it in deep: when i would for example do an nand_erase on mtd6 and would make for example an ext3 of it, would this work or is the jffs necessary for writing into nand (mtd6) ? You may create ext3 on top of mtdblock6, however this will be slower than ext3, and cause fast nand chip wearing. So better not to do it unless you are know what you are doing. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
On Wed, 2009-10-28 at 23:57 +0800, Shawn wrote: hi guys, does anybody has try to port the scheme interpreter(guile,etc) to openMOKO? for what distribution? If it's for SHR try openembedded...there is a guile recipe,but verify that it's the same version than the one in org.openembedded.dev else it will fail with a libtool problem because it would require an old libtool. Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[all] window manager options
hello list. after asking about the enlightenment keyboard crash issue someone mentioned switching the x window manager. my question is who has done this with there freerunner? how has it worked out for you? which wm did you chose? do all of them work for the freerunner? do you have any screenshots of how it looks on the moko screen? thanks for anyone who can add something here. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: one more question about nand
because i hadn't nderstood it in deep: when i would for example do an nand_erase on mtd6 and would make for example an ext3 of it, would this work or is the jffs necessary for writing into nand (mtd6) ? You may create ext3 on top of mtdblock6, however this will be slower than ext3, and cause fast nand chip wearing. slower than jffs2 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
-[ Wed, Oct 28, 2009 at 11:57:13PM +0800, Shawn ] hi guys, does anybody has try to port the scheme interpreter(guile,etc) to openMOKO? Let's try : ri...@hackable1:~/leech$ sudo aptitude install guile-1.8 guile guile (version) 1.8.5 What distribution do you use, that comes without a prepackaged scheme ? :-p ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
for what distribution? I got om for a few days.Im downloading the openWRT distro right now. If it's for SHR try openembedded...there is a guile recipe,but verify that it's the same version than the one in org.openembedded.dev else it will fail with a libtool problem because it would require an old libtool. I have used the cross compiler arm-linux-gcc to compile guile but failed in libtool problem. I tried compile 2 versions of guile(1.4 and 1.8.7) but got same error about libtool.It's any way to take it out? Denis. thanks for your answer,Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- GNU powered it... GPL protect it... God blessing it... regards HFG--Shawn the R0ck ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
Let's try : ri...@hackable1:~/leech$ sudo aptitude install guile-1.8 guile guile (version) 1.8.5 What distribution do you use, that comes without a prepackaged scheme ? my laptop distro is Fedora 9.om,i will try to put a openWRT into it. :-p ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- GNU powered it... GPL protect it... God blessing it... regards HFG--Shawn the R0ck ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: one more question about nand
Nikita V. Youshchenko schrieb: because i hadn't nderstood it in deep: when i would for example do an nand_erase on mtd6 and would make for example an ext3 of it, would this work or is the jffs necessary for writing into nand (mtd6) ? You may create ext3 on top of mtdblock6, however this will be slower than ext3, and cause fast nand chip wearing. slower than jffs2 yes, was clear. thank you. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] window manager options
jeremy jozwik schrieb: hello list. after asking about the enlightenment keyboard crash issue someone mentioned switching the x window manager. my question is who has done this with there freerunner? how has it worked out for you? which wm did you chose? do all of them work for the freerunner? do you have any screenshots of how it looks on the moko screen? thanks for anyone who can add something here. i did it with openbox - http://wiki.openmoko.org/wiki/Minimoko for me, it's great (see the thread about grafical ...). i tried to make some things faster in getting back to the roots and in minimalism. for me, it is more usable, because you can see outdoor's , and it is reacting fast. you are invited to try it. another guy in italy does the same on debian: http://www.sneaked.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
2009/10/28 Shawn cit...@gmail.com: I have used the cross compiler arm-linux-gcc to compile guile but failed in Ah, the happy conjunction of my main free software interests... (I'm one of Guile's maintainers.) libtool problem. I tried compile 2 versions of guile(1.4 and 1.8.7) but got same error about libtool.It's any way to take it out? If you want to send me details, I'm happy to try to help. But cross-compiling environments are tricky so it could take a few iterations. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to port a scheme interpreter to om?
Ah, the happy conjunction of my main free software interests... (I'm one of Guile's maintainers.) wowo~it's pleasure to meet you here dude~ If you want to send me details, I'm happy to try to help. But cross-compiling environments are tricky so it could take a few iterations. the 1.4 version of guile has been succeed compile.but got this below on board: [...@friendlyarm /shawn]# guile /bin/guile: /bin/guile: 1: Syntax error: ( unexpected and 1.8.7 failed(it's a little bit long) to compile: [st...@localhost guile-1.8.7]$ ./configure --prefix=/citypw/shawn-dev/port-guile-to-arm/guile-build --target=arm-linux-gcc --host=arm-linux configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-linux-strip... arm-linux-strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... arm-unknown-linux-gnu configure: autobuild project... guile configure: autobuild revision... 1.8.7 configure: autobuild hostname... localhost.localdomain configure: autobuild timestamp... 20091028T163227Z checking for a BSD-compatible install... /usr/bin/install -c checking for arm-linux-gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-linux-gcc accepts -g... yes checking for arm-linux-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of arm-linux-gcc... gcc3 checking how to run the C preprocessor... arm-linux-gcc -E checking for gawk... (cached) gawk checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for arm-linux-gcc option to accept ISO C89... (cached) none needed checking whether arm-linux-gcc and cc understand -c and -o together... yes checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by arm-linux-gcc... /usr/local/arm/3.4.1/arm-linux/bin/ld checking if the linker (/usr/local/arm/3.4.1/arm-linux/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/local/arm/3.4.1/bin/arm-linux-nm -B checking the name lister (/usr/local/arm/3.4.1/bin/arm-linux-nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1966080 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/local/arm/3.4.1/arm-linux/bin/ld option to reload object files... -r checking for arm-linux-objdump... objdump checking how to recognize dependent libraries... pass_all checking for arm-linux-ar... arm-linux-ar checking for arm-linux-strip... (cached) arm-linux-strip checking for arm-linux-ranlib... arm-linux-ranlib checking command to parse /usr/local/arm/3.4.1/bin/arm-linux-nm -B output from arm-linux-gcc object... ok checking for dlfcn.h... yes checking for objdir... .libs checking if arm-linux-gcc supports -fno-rtti -fno-exceptions... no checking for arm-linux-gcc option to produce PIC... -fPIC -DPIC checking if arm-linux-gcc PIC flag -fPIC -DPIC works... yes checking if arm-linux-gcc static flag -static works... yes checking if arm-linux-gcc supports -c -o file.o... yes checking if arm-linux-gcc supports -c -o file.o... (cached) yes checking whether the arm-linux-gcc linker (/usr/local/arm/3.4.1/arm-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries...
Re: [QtMoko] glamo mplayer
I was thinking about this the other day. There are arm4 ports of myth-frontendso I wonder how well the frontend would run on the freerunner. It is designed to look good on low res screens I may try installing the front-end after I get my new myth system migrated. Has anyone else tried this? I'm bet you could run mythtranscode to change the video streams to something reasonable for the freerunner Also, if nothing else, I bet it could play music from your mythbackend pretty well... -Dan Staley On Wed, Oct 28, 2009 at 11:02 AM, Radek Polak pson...@seznam.cz wrote: On Wednesday 28 of October 2009 03:16:47 Denis Johnson wrote: I want to use my FR to watch a stream from my MythTV recordings using http stream (I think it is mpeg 2) using my wireless. Is the glamo enhanced mplayer available in QtMoko/Denian ? Yes, the binary that QMplayer downloads from internet is using glamo acceleration. Btw QMplayer has also PC version [1]. On your PC you can scan for media and start http server which will offer videos encoded for Freerunner for streaming or downloading. QMplayer in QtMoko can talk with the PC version from it's GUI. [1] http://activationrecord.net/radekp/qmplayer/ Regards Radek ___ 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: [QtMoko] glamo mplayer
Dan Staley a écrit : I was thinking about this the other day. There are arm4 ports of myth-frontendso I wonder how well the frontend would run on the freerunner. It is designed to look good on low res screens I may try installing the front-end after I get my new myth system migrated. Has anyone else tried this? I'm bet you could run mythtranscode to change the video streams to something reasonable for the freerunner Also, if nothing else, I bet it could play music from your mythbackend pretty well... -Dan Staley I tried to watch TV from freerunner+deb...@microsd+mythtv-frontend Nothing else but a black screen :D Btw I confirm that mythtv recordings are MPEG2 TS (transport stream) Xavier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: one more question about nand
On Wednesday 28 October 2009, Matthias Huber wrote: Nikita V. Youshchenko schrieb: because i hadn't nderstood it in deep: when i would for example do an nand_erase on mtd6 and would make for example an ext3 of it, would this work or is the jffs necessary for writing into nand (mtd6) ? You may create ext3 on top of mtdblock6, however this will be slower than ext3, and cause fast nand chip wearing. slower than jffs2 yes, was clear. thank you. Just for extra clarification, mtdblock devices are raw flash without wear levelling, so we want to use a filesystem like jffs2 that's designed with this in mind. uSD cards, CF, USB and SATA flash devices have wear levelling built into the controller hardware, so we can use any old filesystem. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. -- 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: Centralization of graphical awesomeness
Wow, I'm surprised nobody in this thread has been throwing Hitler insults around yet [1]. Changing the default resolution on the FR to QVGA is a good idea if it means a more responsive UI. Assuming that bpp and fps parameters stay the same, that would mean 1/4 of the current glamo-bus traffic. Personally, I'm more interested in running Android on my FR, so even changing the framebuffer resolution statically in the kernel source would be fine by me. C [1] http://en.wikipedia.org/wiki/Godwin's_law ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] glamo mplayer
Xavier Cremaschi schrieb: Dan Staley a écrit : I was thinking about this the other day. There are arm4 ports of myth-frontendso I wonder how well the frontend would run on the freerunner. It is designed to look good on low res screens I may try installing the front-end after I get my new myth system migrated. Has anyone else tried this? I'm bet you could run mythtranscode to change the video streams to something reasonable for the freerunner Also, if nothing else, I bet it could play music from your mythbackend pretty well... -Dan Staley I tried to watch TV from freerunner+deb...@microsd+mythtv-frontend Nothing else but a black screen :D Btw I confirm that mythtv recordings are MPEG2 TS (transport stream) Xavier. did someone already try to port vlc media player ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Strange behaviour of elementary entry and illume keyboard. Did anybody noticed it?
Hi! Have anybody noticed, when you type some text in a elementary entry, then you click on any other element (a button for example) and you click again on the entry. Now the cursor is still at the end of the text. But when you send some chars using illume keyword it inserts the chars *before the last char*. And what is really strange: The backspace button (or swiping left on the keyboard) does erase the LAST char. Even after you inserted some chars already before the last char. The backspace still erase the last char. Once you erased one char from the end (using backspace), you are back to the normal behaviour. The cursor is at the end, when you type chars, it inserted at the end, and the backspace deletes the last char too. Any possible explanation? Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Strange behaviour of elementary entry and illume keyboard. Did anybody noticed it?
Oh yes, I got VERY annoyed from that f*cking inconsistent backspace behaviour! Sorry, this had to be written. Its so annoying when editing text after having typed a few sentences, although I couldn't make out any rule behind that. Am Mittwoch, den 28.10.2009, 19:15 +0100 schrieb Laszlo KREKACS: Hi! Have anybody noticed, when you type some text in a elementary entry, then you click on any other element (a button for example) and you click again on the entry. Now the cursor is still at the end of the text. But when you send some chars using illume keyword it inserts the chars *before the last char*. And what is really strange: The backspace button (or swiping left on the keyboard) does erase the LAST char. Even after you inserted some chars already before the last char. The backspace still erase the last char. Once you erased one char from the end (using backspace), you are back to the normal behaviour. The cursor is at the end, when you type chars, it inserted at the end, and the backspace deletes the last char too. Any possible explanation? Best regards, 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
Re: Strange behaviour of elementary entry and illume keyboard. Did anybody noticed it?
Oh yes, I got VERY annoyed from that f*cking inconsistent backspace behaviour! Sorry, this had to be written. Its so annoying when editing text after having typed a few sentences, although I couldn't make out any rule behind that. Am Mittwoch, den 28.10.2009, 19:15 +0100 schrieb Laszlo KREKACS: Hi! Have anybody noticed, when you type some text in a elementary entry, then you click on any other element (a button for example) and you click again on the entry. Now the cursor is still at the end of the text. But when you send some chars using illume keyword it inserts the chars *before the last char*. has this been reported in E track? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Sebastian Krzyszkowiak wrote: But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. Sorry other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. Sorry How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Maybe a contest asking if users wanted to launch opkg upgrade without messing their system at random one day yes and the following no? Maybe asking if the unstable or stable o testing branches could be useful for ALL instead of deciding to break things without any advice? I think community driven means we want to decide one thing do you agree with us or suggest something better? not we decide to do something and you are only passive testers simply because even the Freerunner is a high end user device, not every high end user is a Linux system expert or able to fix something...But maybe I'm wrong so sorry again... Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). It's not trolling, I never trolled or wanted to, but asked questions and told my opinion (I was rude in my first post but I explained why), if this is not acceptable only because I don't fully agree with Raster or SHR devs it's not my problem and I'll continue to work by myself and (if possible) share my results with anyone interested in, otherwise it's really not a problem and my life will go on as ever :) my way of thinking the Freerunner is written in the little green card I found in its box... So sorry again and good bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
DJDAS wrote: Cedric BAIL wrote: So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. That's exactly what I said in my previous post it's not me that is saying E is the best piece of software, all the others are sh*t and I'm not crying, I worked to optimize my personal distribution based on an old FDOM and it's quite responsive and daily since september 2008, FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
jeremy jozwik jerjoz.for...@gmail.com writes: 2009/10/25 Łukasz Pankowski lukp...@o2.pl: Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. ive just thought of something. instead of using the enlighten fullscreen mode. which kills the UI if the keyboard is set to none. is there any way you could borrow the render-above-all bit of code from literki? if you run literki you can position the keyboard above the menu bar, thus emulating the fullscreen mode. would make for a much more stable package while we wait for a working enlightenment. Hi, I will try to look into this issue looking at literki, if it will be easy to workaround I will add it as an option in config file (hope to look at before the next release). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On 10/28/09, DJDAS dj...@djdas.net wrote: Sebastian Krzyszkowiak wrote: But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. Sorry other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. Sorry How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Maybe a contest asking if users wanted to launch opkg upgrade without messing their system at random one day yes and the following no? Maybe asking if the unstable or stable o testing branches could be useful for ALL instead of deciding to break things without any advice? I think community driven means we want to decide one thing do you agree with us or suggest something better? not we decide to do something and you are only passive testers simply because even the Freerunner is a high end user device, not every high end user is a Linux system expert or able to fix something...But maybe I'm wrong so sorry again... Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). It's not trolling, I never trolled or wanted to, but asked questions and told my opinion (I was rude in my first post but I explained why), if this is not acceptable only because I don't fully agree with Raster or SHR devs it's not my problem and I'll continue to work by myself and (if possible) share my results with anyone interested in, otherwise it's really not a problem and my life will go on as ever :) my way of thinking the Freerunner is written in the little green card I found in its box... So sorry again and good bye. Well, don't be sorry. Just please, be little more friendly when expressing your opinions, as discussing when being close to insults isn't nice ;) That's all. Personally I think you're wrong, but I'm not God, not even Flying Spaghetti Monster, so we both can be wrong ;) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-u] Wifi, Keyboard and scripting
Hi all, I have got a couple of questions regarding the latest SHR-u. Is is possible to have it _not_ suspend as default when on battery? How do I turn on the wifi radio from the command line (instead of going through the settings)? How do I run a script automatically at the end of the start up process? When I start the terminal, the keyboard is the predictive one. How do I change it to the 'terminal' keyboard as default? In appreciation of your time -Johan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
don't forget to fit in the Snooze slider too, please :) It shouldn't need a separate slider. If you turn off but don't ACK it should be equivalent to a snooze. tried that this morning and no snooze, i mean i could snooze but the phone went to sleep :) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
can anyone tell their experiences about mer
hi there just curios about mer can anyone tell their experiences about mer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-u] Wifi, Keyboard and scripting
On Wednesday 28 October 2009, Johan Kraft wrote: Hi all, I have got a couple of questions regarding the latest SHR-u. Is is possible to have it _not_ suspend as default when on battery? Settings - Power in the 'Power Settings' section How do I turn on the wifi radio from the command line (instead of going through the settings)? mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy WiFi enabled Change 'enabled' to 'auto' to let apps request it, or 'disabled' to force it off. How do I run a script automatically at the end of the start up process? Never looked into that one. When I start the terminal, the keyboard is the predictive one. How do I change it to the 'terminal' keyboard as default? Keyboard definitions live in /usr/lib/enlightenment/modules/illume/keyboard/*.kbd The default definition is whichever is named Default.kbd, so if you rename the files you can change which is used by default. In appreciation of your time -Johan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-u] Wifi, Keyboard and scripting
Is is possible to have it _not_ suspend as default when on battery? Settings-Power-Auto-suspend: Off How do I turn on the wifi radio from the command line (instead of going through the settings)? opkg install fsoraw fsoraw --help How do I run a script automatically at the end of the start up process? start up of the system or start up of X? either place your script into /etc/rc5.d or /etc/X11/Xsession.d , look into how scripts are named - numbered. use the highest number +1 of existing scripts or 99 to be the last to start. When I start the terminal, the keyboard is the predictive one. How do I change it to the 'terminal' keyboard as default? http://wiki.openmoko.org/wiki/Illume_keyboard Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wednesday 28 October 2009, Petr Vanek wrote: don't forget to fit in the Snooze slider too, please :) It shouldn't need a separate slider. If you turn off but don't ACK it should be equivalent to a snooze. tried that this morning and no snooze, i mean i could snooze but the phone went to sleep :) I meant that it ought to behave that way in future, not that it would in the current version. I don't care if the phone goes to sleep during the snooze interval so long as the alarm goes off again five minutes later! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
I meant that it ought to behave that way in future, not that it would in the current version. I don't care if the phone goes to sleep during the snooze interval so long as the alarm goes off again five minutes later! :) sure, now it didn't wake up itself and me neither :)) what if the unlocking 1-2-3-4 pattern is configurable, how would snooze get in then? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: can anyone tell their experiences about mer
On Thu, Oct 29, 2009 at 01:29:23AM +0530, Aditya Gandhi wrote: hi there just curios about mer can anyone tell their experiences about mer As my Smart q/ arrives, I may have something to say about it :) But I don't expect it before sometime in the next 7 to 17 days :( Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
On Wed, 28 Oct 2009 13:04:54 +0100 Davide Scaini dsca...@gmail.com wrote: Hi Michael, i'm also interested in doing teh rework on my own, but on this page http://wiki.openmoko.org/wiki/1024 and related links there are only few images... so can you please post yours when your work is done? Okay I will do that. -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Keyboard above xterm, first try
Also, I'm a little contraried by the memory footprint of the program, and by the fact that I would like this keyboard for other apps... Anybody already tried to build a OSD keyboard with lib-aosd or lib-xosd ? Ok, as a proof of concept I just did a virtual keyboard using the XShape extension, so you can have it over xterm (or anything else that does not need the mouse) : http://gitorious.org/kbosd Runs fine under hackable:1 rev5, may require some tweaking on other distros (like selecting another font). Happy Hacking in portrait mode ! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wednesday 28 October 2009, DJDAS wrote: Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... FDOM display is faster mainly because it uses a relatively simple theme. Bernd's lightweight themes should give a similar speedup. Another factor is that some iterations of the fso daemons have been occasional resource hogs, causing display slowdowns whichever toolkit you use. This has been addressed partly by bugfixes in the python implementations, and for the future by the ongoing move to vala implementations of the daemons, starting with the most resource-hungry. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
