Enlightenment Returns To Bring Ubuntu To ARM
Available on /. today: http://enlightenment.org/p.php?p=news/showl=ennews_id=20 -- Microsoft gives you windows, Linux gives you the whole house. _ Lentekriebels? Speel samen met je vrienden de spelletjes die Windows Live je aanbiedt! http://www.messengerbillboard.be/nl/play ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
On Tuesday 11 August 2009, Michal Brzozowski wrote: 2009/8/11 Al Johnson openm...@mazikeen.demon.co.uk On Tuesday 11 August 2009, Michal Brzozowski wrote: Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Do you have a link to the bug report? No, it's been discussed a few times on this list. Then please file a bug report. The devs can't keep track of everything mentioned on the list, but can easily get a list of outstanding bugs on the tracker. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
2009/8/12 Al Johnson openm...@mazikeen.demon.co.uk Then please file a bug report. The devs can't keep track of everything mentioned on the list, but can easily get a list of outstanding bugs on the tracker. http://trac.enlightenment.org/e/ticket/398 Sorry for being lazy and not filing the ticket earlier :-) Michal ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
enlightenment still crashing
Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Michal ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
On Tuesday 11 August 2009, Michal Brzozowski wrote: Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Do you have a link to the bug report? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
2009/8/11 Al Johnson openm...@mazikeen.demon.co.uk On Tuesday 11 August 2009, Michal Brzozowski wrote: Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Do you have a link to the bug report? No, it's been discussed a few times on this list. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enlightenment and .desktop file (with autostarting)
Thanks for you reply! On Thu, May 7, 2009 at 12:12 AM, Carsten Haitzler ras...@rasterman.com wrote: the only cache is a runtime cache in ram - none on disk. and restart of e (including its own restart) will completely rebuild it from disk. it does monitor files and on changes, reads them. there could be a race condition with a partially written file by the time e reads it. so chances are... your command is just wrong. if it can change the name - its loading all the fields, and then running them. e may have a different $PATH in its environment than your shell remember, so use full paths to be explicit. I specified the full path. I will post the .desktop file later today. If I quit from paroli (using the illume bar), I cant relaunch it anymore. Just if I kill -HUP enlightenment. After that will start paroli. (I get a loading screen). So I need to kill enlightenment each time I quit paroli. Rather strange. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enlightenment and .desktop file (with autostarting)
On Thu, 7 May 2009 08:01:10 +0200 Laszlo KREKACS laszlo.krekacs.l...@gmail.com said: Thanks for you reply! On Thu, May 7, 2009 at 12:12 AM, Carsten Haitzler ras...@rasterman.com wrote: the only cache is a runtime cache in ram - none on disk. and restart of e (including its own restart) will completely rebuild it from disk. it does monitor files and on changes, reads them. there could be a race condition with a partially written file by the time e reads it. so chances are... your command is just wrong. if it can change the name - its loading all the fields, and then running them. e may have a different $PATH in its environment than your shell remember, so use full paths to be explicit. I specified the full path. I will post the .desktop file later today. If I quit from paroli (using the illume bar), I cant relaunch it anymore. Just if I kill -HUP enlightenment. After that will start paroli. (I get a loading screen). So I need to kill enlightenment each time I quit paroli. Rather strange. actually - did you make sure paroli ACTUALLY quit? that it didnt stay running and just iconify its window? -- - 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: Enlightenment and .desktop file (with autostarting)
On Thu, 2009-05-07 at 23:39 +1000, Carsten Haitzler wrote: So I need to kill enlightenment each time I quit paroli. Rather strange. actually - did you make sure paroli ACTUALLY quit? that it didnt stay running and just iconify its window? Currently paroli won't quit. It backgrounds itself so it can catch calls and bring up the answer window ( this will configurable in the future ) Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enlightenment and .desktop file (with autostarting)
On Thu, 07 May 2009 07:56:23 -0600 Angus Ainslie nyt...@openmoko.org said: On Thu, 2009-05-07 at 23:39 +1000, Carsten Haitzler wrote: So I need to kill enlightenment each time I quit paroli. Rather strange. actually - did you make sure paroli ACTUALLY quit? that it didnt stay running and just iconify its window? Currently paroli won't quit. It backgrounds itself so it can catch calls and bring up the answer window ( this will configurable in the future ) and thats probably why it comes back up again. one of 2 things. 1. if iconified - e will match the command line to the .desktop file - or simply know that that .desktop file launched that app and thus running it again if the window for that app is still there should simply bring that window up again... or 2. paroli has its own session finding/handling so it finds the existing instance of itself and ipc's asking it to show its window again - much like firefox does or a whole bunch of apps these days can do. -- - 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
Enlightenment and .desktop file (with autostarting)
Hi! I hope my questions are mainly rtfm ones, so someone can provide me the right links;) Short story: I installed om2009, and after I installed paroli from git. I could launch the new paroli (latest git) from command line. So I thought a little modification in /usr/share/paroli.desktop would be enough. I changed in the desktop file the Exec and TryExec line, but when I clicked on the Desktop button, nothing happened (didnt launch paroli). I even restarted the phone hoping it will magically load. But it loaded instead the old paroli application! even when no .desktop file existed for it. So I suspect there are definietly some caching mechanism inside E, and this is the reason why paroli failed to launch. Because when I changed every name in the .desktop file: Name, GenericName, Comment The icon magically begun to work. But when I start the phone the *old* paroli gets loaded. (I need to close it, and start the new one via the desktop button) So my question are: 1. Where are the autolaunching application defined (paroli starts automagically) 2. How can I force E to reload the .desktop file and execute it and not the old (cached) one. 3. How can I make sure the E autolaunch the right application? Any idea, documentation, comments are appreciated! Im playing since hours with this problem. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enlightenment and .desktop file (with autostarting)
On Wednesday 06 May 2009 19:04:58 Laszlo KREKACS wrote: Hi! I hope my questions are mainly rtfm ones, so someone can provide me the right links;) Short story: I installed om2009, and after I installed paroli from git. I could launch the new paroli (latest git) from command line. So I thought a little modification in /usr/share/paroli.desktop would be enough. I changed in the desktop file the Exec and TryExec line, but when I clicked on the Desktop button, nothing happened (didnt launch paroli). I even restarted the phone hoping it will magically load. But it loaded instead the old paroli application! even when no .desktop file existed for it. So I suspect there are definietly some caching mechanism inside E, and this is the reason why paroli failed to launch. Because when I changed every name in the .desktop file: Name, GenericName, Comment The icon magically begun to work. But when I start the phone the *old* paroli gets loaded. (I need to close it, and start the new one via the desktop button) So my question are: 1. Where are the autolaunching application defined (paroli starts automagically) 2. How can I force E to reload the .desktop file and execute it and not the old (cached) one. 3. How can I make sure the E autolaunch the right application? Any idea, documentation, comments are appreciated! Im playing since hours with this problem. Best regards, Laszlo Have a look in /etc/X11/Xsession.d/ as there maybe a start script for paroli in there (just a guess as i know thats where zhone starts from) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enlightenment and .desktop file (with autostarting)
On Wed, 6 May 2009 20:04:58 +0200 Laszlo KREKACS laszlo.krekacs.l...@gmail.com said: Hi! I hope my questions are mainly rtfm ones, so someone can provide me the right links;) Short story: I installed om2009, and after I installed paroli from git. I could launch the new paroli (latest git) from command line. So I thought a little modification in /usr/share/paroli.desktop would be enough. I changed in the desktop file the Exec and TryExec line, but when I clicked on the Desktop button, nothing happened (didnt launch paroli). I even restarted the phone hoping it will magically load. But it loaded instead the old paroli application! even when no .desktop file existed for it. So I suspect there are definietly some caching mechanism inside E, and this is the reason why paroli failed to launch. the only cache is a runtime cache in ram - none on disk. and restart of e (including its own restart) will completely rebuild it from disk. it does monitor files and on changes, reads them. there could be a race condition with a partially written file by the time e reads it. so chances are... your command is just wrong. if it can change the name - its loading all the fields, and then running them. e may have a different $PATH in its environment than your shell remember, so use full paths to be explicit. Because when I changed every name in the .desktop file: Name, GenericName, Comment The icon magically begun to work. But when I start the phone the *old* paroli gets loaded. (I need to close it, and start the new one via the desktop button) that'd be starting prolie via some other means - like startup scripts in /etc/X11/Xsession.d - dig around in /etc/X11 So my question are: 1. Where are the autolaunching application defined (paroli starts automagically) 2. How can I force E to reload the .desktop file and execute it and not the old (cached) one. it should do it automatcally. an e restart will force everything to reload (killall -HUP enlightenment). 3. How can I make sure the E autolaunch the right application? the launching you are seeeing is not from e but from oe's Xsession script setup - see above. Any idea, documentation, comments are appreciated! Im playing since hours with this problem. Best regards, Laszlo ___ 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: Why enlightenment?
On Sun, 2009-04-19 at 11:52 +1000, Carsten Haitzler wrote: On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt bne...@gmail.com said: This looks like a great list! I'll go through the points one by one... On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote: Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. I'll have to look into how complicated this would be with GTK, but I'll take your word for it. However, if you change the clock from digital to analog, then you will get layout problems. I thought switching glade(/gtkbuilder) files would be perfect for something like that and with the glade interface developer, making new layouts would be easy for everybody. I'll take your word for it that is really is easier. trust me - e is by far more flexible than gtk in changing look,layout and feel just by changing a theme data file. i wrote gtk's theme system. i also wrote e... :) Yes, I trust you on that. But I don't think theming is always a good thing. That is, however, just a matter of opinion. 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. I really thought finger scrolling would be a task that should be implemented by the touchscreen driver/library software, or if needed the window manager, but not the GUI toolkit. What about right-clicking support? If you put right-clicking support, scrolling, and other emulate a normal mouse behavior in the GUI toolkit, I think you are putting it in the wrong place. 1. absolutely not. scrolling is an app+toolkit thing. scrolling needs to track the mouse position. i can go into all the logic an math why - as it also conflicts with normal use (like dragging a slider, pressing buttons in a scrollable region etc.). the toolkit/app needs to figure out did they want to slide the slider, or scroll the view? for example. trust me that its a toolkit/app problem. The only example I can state here is something I first say implemented by a logitech driver on windows. To scroll you pressed a special button on your mouse anywhere on the screen and then moved the pointer away to start scrolling. The further away from your initial point, the faster you scolled. This worked with all toolkits (including Java SWT, GTK+, Firefox's toolkit). So I can't get myself to trust you on that. 2. right mouse also can be hackishly implemented in the windowing system - but thats wrong, as it has no idea what parts of the screen need a long press for emulating a right mouse. (thats the normal way to do it). this SHOULD be left to the toolkit. only the toolkit knows what parts of the screen are sensitive to a right-mouse press or not. and if it does this... it may as well handle it as along press anyway (as opposed to emulating right-mouse) I thought I could could use my mouse and use the right button on any part of the screen I wanted, without having a toolkit tell me whether I am allowed or not? Even if I have to emulate it some how, if I want to right click on something, the only thing I think the toolkit is allowed to do is sit there and take it ;) If you think about it like that, then finger friendly means: large buttons, nothing where you have to hit the side, and feedback you can see even with your finger on it. correct. also that it doesnt need a right mouse button, that it doesnt rely on mouseovers for input/indication (or position of mouse eg - move mouse to edge of window to begin an auto-scroll in that direction). or that some bits of the ui appear when the mosue is over areas. as the mouse only moves while mouse button 1 is pressed down - you need to work with that. you also need other bits of smart eg - finger-scrolling. to determine if a swipe is a scroll or not, handle momentum of the scroll etc. I still can not see why you need to work with that in the toolkit. Why not go a level higher and try to solve those problems in a toolkit agnostic manner? But if the OpenMoko team thinks that the GUI toolkit is the place to fix scrolling, then I can see why it is a good choice. thats what elementary covers - it's Good list of features, and I would like to use it to congratulate all developers on the elementary toolkit on their achievements. Don't get me wrong, I'm not saying that enlightenment is bad code or crappy work. I started this thread because I couldn't understand the reason why it was chosen. 3. Up-to-date. It's under constant development, and getting better by the day. It's also (Illume and elementary
Re: Why enlightenment?
Effectively you are saying nothing else was good enough. But that is what everybody says when you ask them why they created something, they say I needed it, and it wasn't there already. Could you be more specific on which features you want, and why other toolkits can not deliver them? Or give an example of where other libraries where just to slow? Bram On Sun, 2009-04-19 at 11:28 +1000, Carsten Haitzler wrote: On Thu, 16 Apr 2009 17:11:37 +0200 Bram Neijt bne...@gmail.com said: as such the choice of enviornment, thanks to it running x, is not limited, you can use qt, gtk, sdl, fltk etc. e is a window manager - it happens to also have spawned toolkits that lend themesleves to unique custom ui's and much more flexibility than the larger toolkits. trust me on this - gtk's theme system comes courtesy of me - i wrote it years ago. i know how far you will be able to push gtk (without breaking it and effectively creating a new incompatible toolkit). qt until a few months ago has a major license issue - GPL for a library forces ALL apps to effectively be GPL. for the entire development of gta02 it was GPL. GPL inherently restricts the freedom of app developers to NOT make software GPL (MIT, BSD or any other license they choose). if you chose to ship with a GPL toolkit - then you limit what app developers can do. so qt was right out (and i know a whole bunch of developers who simply dont want todo c++ in order to use qt - they want to use c or something else). so gtk has its limits - also i have heard enough complaints of it being slow - and that is from commercial developers in big electronics houses. they really are not squeakingly happy with gtk and are hunting for other solutions. qt had the license problems until a few months ago. so what other choices do you have if you have eliminated qt for license reasons and you think gtk is just not up to snuff and is unlikely to get there easily without major breaks? True, I expected to like the Freerunner as a phone and thought the whole freedom would just be an added bonus. If the phone isn't that good, I could always fix small bugs and help out. However, it turns out that I can't understand the direction the mainstream development is going, and with this small community, the bugs in other distributions are not small at all. So I seem have to make a choice: put in allot of time, or stick with a product that I can't understand. The last option is just to sell the thing before the value drops to much and buy something else. As you say, choices had to be made and this is it. I don't think I'm closer to understanding the reasoning behind choosing for e, but maybe this is just an opinion, and we should leave it at that. In the meantime I think I'll just have to reset my expectations, and decide what I want to do with this phone. Thank you for your reply. Bram On Thu, 2009-04-16 at 15:02 +0200, arne anka wrote: So what if the company decided to use that money for something you do not want to be part of, or you think they are throwing away your money doing stupid things. Well, I think at that moment you should pawn the product, not endorse it (maybe even publicly denounce it) and then find another company or product you can be happy with. that's a constellation you have to cope with in every commercial product (and even in others, too, though you might not measure your investments in terms of money). what's more, with most companies you don't neither have a saying in what the money is spent for nor do you actually get information about what that company plans are at all. the difference with the freerunner is, that you can install what environment you want and that you are not limited by the decisions the company makes after you bought. with the amount of freedom available, openmoko as company in question cannot be supposed to invest in all and every available technology, be it a desktop environment or merely a toolkit, but instead one way has to be chosen. but om having their money on e does not mean, you are forced to use e. if, on the other hand, you demand that you have a saying in what the company does with your money, clinging to the merely ficitional conception of splitting your money in a part for the actual hardware, a part for development done and a part for development to come -- there won't be many things left you could purchase. btw: that whole question is not at all about e or gtk or qt, but what to expect from a frre device -- and that question in turn has been discussed in extenso already. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Tue, 21 Apr 2009 12:05:44 +0200 Bram Neijt bne...@gmail.com said: i'm going to keep it short as i really dont have time to go into al the details. 1. i am not interested in c++. this gets rid of qt, fltk and a bunch of other toolkits. i know there are enough devs also not interested in c++. 2. this (in terms of major toolkits) gets you down to gtk or something else. so i'll focus on gtk vs efl. 1. gtk's theme engine is limited. it is limited by the code that lays out widgets. you cannot make a theme have extra padding in a widget. yo cannot add layering, text effects or many other things. gtk has no concept of layering between widgets. widgets are laid out flat and should/cannot overlap. 2. gtk is slower. even just start times. try an app that uses efl and one that uses gtk (and that have equivalently complex-looking themes/ui setups). see which one pops up your window first. i have gotten it from developers doing embedded evices to the point where they laughed at how slow gtk was. once they used evas/efl - their apps came up seconds sooner. and efl was playing no tricks to get there. even when they played the dlopen() tricks that maemo does to launch gtk fast - efl still beat gtk - and it was going the long way around. i have, in the meantime added a similar hack to elementary. and it now starts even faster. this is anecdotes directly from people using it. their managers are pressuring them to get apps to appear instantly. or as instantly as possible. they hit a wall with gtk they couldnt - for months, improve. someone decided to try efl and suddenly they were incredibly happy and moving forwards again. gtk - if you begin to do anything interesting with the theme and ui (theme engine) becomes pretty slow with redraws. visibly so on a slow old device. keep your gtk to grey bevels or solid colors with simply looks and it goes fine. get fancy and it comes to a crawl. 3. gtk has no ability to do blending in, aroudn or between widgets sanely because it uses child windows (you would need to introduce compositing to gtk or remove all child windows which will break its api) 4. try do a ui that INST just plain normal widgets with gtk. see where you get. try do xmms (winamp etc.). efl drops into this kind of ui seamlessly as it provides a canvas as the core drawing layer. making such custom ui;s (which many people are rather fond of and make sense in specific cases). try this in gtk (to the point of it being easy): http://www.rasterman.com/files/wp2.avi (i'm not done with it yet). 5. rendering. gtk uses cairo. cairo is full of floating point. the samsung 2442 has NO floating point unit. it's slow as arse without a fpu. many embedded systems have no fpu. add to this rendering other than fp.. this means simple pixel pushing (blending, scaling, etc.). cairo has a software engine of its own - but normally uses xrender. both of these are significantly slower than evas's software engine. by more than a factor of 2. doing the same operations. evas has an xrender engine. it even once had a cairo engine. here i clocked the cairo engine in at being 1/20th the speed of evas's existing software engine. evas also has a OpenGL engine, DirectFB, Quartz, win32, wince, (and here in my own sources i also have a OpenGLES 2.0 engine - sadnly the 3d GLES chipsets i've tested it on simply run at about 1/4 the speed of evas's software engine.. on the same platform... so it's awaiting some miracle to make it speed up to the point of it being useful). it can render to the FB directly (with no x11 involved). flipping between x and fb is a single line of code the app selects on init. thus a 1 liner to have your app work in fb to x11.. or both even without a single recompile or patch. there's an SDL engine, direct3d, memory-buffer renderer direct-draw and even qtopia engine. thats a hell of a lot of display targets. you can switch them simply by varying the init line. gtk does not go here. 6. there are existing meta-object abstraction libraries on top - edje. this allows you to define a complex object and layout in a data file. it splits the look/theme/feel away from the programmer a bit allowing non-programmers to generate them. it allows for defining interactions from events (mouse etc.) signals (virtual events from the app) and animations. thus you can very easily define a more custom layout for an app (eg a whole winamp skin) in a single data file... and just load it - place it where you want and let it go. edje handles the rest for you. the animation, interaction and abstractions for layout. no - it's not perfect. it has limits. but it's something gtk doesnt even vaguely offer. sure you have libglade and to an extent you can begin to do some.. but not all. not as easily. yes. i am saying it wasn't good enough. i started evas and efl because nothing else DID it. and still toolkits are playing catch up. if all you want is your usual grey boxy normal widget ui - gtk is fine. but if you want to get interesting. if you want do
Re: Why enlightenment?
On Tue, 21 Apr 2009 13:00:33 +0200 Bram Neijt bne...@gmail.com said: On Sun, 2009-04-19 at 11:52 +1000, Carsten Haitzler wrote: On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt bne...@gmail.com said: This looks like a great list! I'll go through the points one by one... On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote: Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. I'll have to look into how complicated this would be with GTK, but I'll take your word for it. However, if you change the clock from digital to analog, then you will get layout problems. I thought switching glade(/gtkbuilder) files would be perfect for something like that and with the glade interface developer, making new layouts would be easy for everybody. I'll take your word for it that is really is easier. trust me - e is by far more flexible than gtk in changing look,layout and feel just by changing a theme data file. i wrote gtk's theme system. i also wrote e... :) Yes, I trust you on that. But I don't think theming is always a good thing. That is, however, just a matter of opinion. 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. I really thought finger scrolling would be a task that should be implemented by the touchscreen driver/library software, or if needed the window manager, but not the GUI toolkit. What about right-clicking support? If you put right-clicking support, scrolling, and other emulate a normal mouse behavior in the GUI toolkit, I think you are putting it in the wrong place. 1. absolutely not. scrolling is an app+toolkit thing. scrolling needs to track the mouse position. i can go into all the logic an math why - as it also conflicts with normal use (like dragging a slider, pressing buttons in a scrollable region etc.). the toolkit/app needs to figure out did they want to slide the slider, or scroll the view? for example. trust me that its a toolkit/app problem. The only example I can state here is something I first say implemented by a logitech driver on windows. To scroll you pressed a special button on your mouse anywhere on the screen and then moved the pointer away to start scrolling. The further away from your initial point, the faster you scolled. This worked with all toolkits (including Java SWT, GTK+, Firefox's toolkit). So I can't get myself to trust you on that. that's because there was a SPECIAL BUTTON! a special app can grab that 1 button everywhere (thus its not useful for anything BUT the scrolling). also note.. it's WINDOWS. this is NOT windows. this is X. only the tolkit and app know the context of whats inside a window and only they can (sanely) handle mouse events within that window and know what they were for. be they presses etc. yes - given a SPECIAL button it would be possible to intercept and figur eit out - but then.. how do you know WHICH thing to scroll? you have 2 scrollviews in a window? one on the top, one on the bottom. which scrolls? only the toolkit knows which should (ie which one you intiially pressed). yes you could try faking mousewheel buttons and this wont move the thing WITH the finger by the distance the finger moved. ie DRAG thge thing as far as you dragged with a finger as there is no correlation between a mouse wheel press and how far something moves in pixels. it's a toolkit issue, 2. right mouse also can be hackishly implemented in the windowing system - but thats wrong, as it has no idea what parts of the screen need a long press for emulating a right mouse. (thats the normal way to do it). this SHOULD be left to the toolkit. only the toolkit knows what parts of the screen are sensitive to a right-mouse press or not. and if it does this... it may as well handle it as along press anyway (as opposed to emulating right-mouse) I thought I could could use my mouse and use the right button on any part of the screen I wanted, without having a toolkit tell me whether I am allowed or not? Even if I have to emulate it some how, if I want to right click on something, the only thing I think the toolkit is allowed to do is sit there and take it ;) you can press the button. but only the TOOKIt knows what it should DO with it. is right mouse useful at all - will it do anything? am i just dragging sliders around with the left mouse (and then it is possibly you hold your left mouse down and still for a while when you begin or end a drag. only the toolkit knows if you just
Re: Why enlightenment?
On Tue, 21 Apr 2009 13:46:46 +0200 Pander pan...@users.sourceforge.net said: Carsten, Thanks that you took the time to explain it more in depth. Could you (or others) give me some advise ragarding the following. I'm working on an application that was written by others in PyGTK. I like it because I can write in Python. Advantage of this GTK application is that I and others can run it easily on an Ubuntu desktop. Does something like 'PyEnlightenment' exist? Is this Paroli? If I was to port the application to Paroli or a 'PyEnlightenment', would it also work for noob users on desktops, i.e. can such a toolkit be installed via apt-get from the default Linux distribution repository? yes it does - there are ecore, evas, edje, elementary etc. bindings for python, they may be mostly complete. i don't maintain or use them though. as for apt-get install - you'll need to find some new repositories for that. we are actually preparing a snap of efl right now. elementary isn't included thoguh. -- - 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: Why enlightenment?
Carsten Haitzler (The Rasterman) wrote: On Tue, 21 Apr 2009 12:05:44 +0200 Bram Neijt bne...@gmail.com said: i'm going to keep it short as i really dont have time to go into al the details. 1. i am not interested in c++. this gets rid of qt, fltk and a bunch of other toolkits. i know there are enough devs also not interested in c++. 2. this (in terms of major toolkits) gets you down to gtk or something else. so i'll focus on gtk vs efl. 1. gtk's theme engine is limited. it is limited by the code that lays out widgets. you cannot make a theme have extra padding in a widget. yo cannot add layering, text effects or many other things. gtk has no concept of layering between widgets. widgets are laid out flat and should/cannot overlap. 2. gtk is slower. even just start times. try an app that uses efl and one that uses gtk (and that have equivalently complex-looking themes/ui setups). see which one pops up your window first. i have gotten it from developers doing embedded evices to the point where they laughed at how slow gtk was. once they used evas/efl - their apps came up seconds sooner. and efl was playing no tricks to get there. even when they played the dlopen() tricks that maemo does to launch gtk fast - efl still beat gtk - and it was going the long way around. i have, in the meantime added a similar hack to elementary. and it now starts even faster. this is anecdotes directly from people using it. their managers are pressuring them to get apps to appear instantly. or as instantly as possible. they hit a wall with gtk they couldnt - for months, improve. someone decided to try efl and suddenly they were incredibly happy and moving forwards again. gtk - if you begin to do anything interesting with the theme and ui (theme engine) becomes pretty slow with redraws. visibly so on a slow old device. keep your gtk to grey bevels or solid colors with simply looks and it goes fine. get fancy and it comes to a crawl. 3. gtk has no ability to do blending in, aroudn or between widgets sanely because it uses child windows (you would need to introduce compositing to gtk or remove all child windows which will break its api) 4. try do a ui that INST just plain normal widgets with gtk. see where you get. try do xmms (winamp etc.). efl drops into this kind of ui seamlessly as it provides a canvas as the core drawing layer. making such custom ui;s (which many people are rather fond of and make sense in specific cases). try this in gtk (to the point of it being easy): http://www.rasterman.com/files/wp2.avi (i'm not done with it yet). 5. rendering. gtk uses cairo. cairo is full of floating point. the samsung 2442 has NO floating point unit. it's slow as arse without a fpu. many embedded systems have no fpu. add to this rendering other than fp.. this means simple pixel pushing (blending, scaling, etc.). cairo has a software engine of its own - but normally uses xrender. both of these are significantly slower than evas's software engine. by more than a factor of 2. doing the same operations. evas has an xrender engine. it even once had a cairo engine. here i clocked the cairo engine in at being 1/20th the speed of evas's existing software engine. evas also has a OpenGL engine, DirectFB, Quartz, win32, wince, (and here in my own sources i also have a OpenGLES 2.0 engine - sadnly the 3d GLES chipsets i've tested it on simply run at about 1/4 the speed of evas's software engine.. on the same platform... so it's awaiting some miracle to make it speed up to the point of it being useful). it can render to the FB directly (with no x11 involved). flipping between x and fb is a single line of code the app selects on init. thus a 1 liner to have your app work in fb to x11.. or both even without a single recompile or patch. there's an SDL engine, direct3d, memory-buffer renderer direct-draw and even qtopia engine. thats a hell of a lot of display targets. you can switch them simply by varying the init line. gtk does not go here. 6. there are existing meta-object abstraction libraries on top - edje. this allows you to define a complex object and layout in a data file. it splits the look/theme/feel away from the programmer a bit allowing non-programmers to generate them. it allows for defining interactions from events (mouse etc.) signals (virtual events from the app) and animations. thus you can very easily define a more custom layout for an app (eg a whole winamp skin) in a single data file... and just load it - place it where you want and let it go. edje handles the rest for you. the animation, interaction and abstractions for layout. no - it's not perfect. it has limits. but it's something gtk doesnt even vaguely offer. sure you have libglade and to an extent you can begin to do some.. but not all. not as easily. yes. i am saying it wasn't good enough. i started evas and efl because nothing else DID it. and still toolkits are
Re: Why enlightenment?
On Tue, Apr 21, 2009 at 2:26 PM, Carsten Haitzler ras...@rasterman.com wrote: 4. try do a ui that INST just plain normal widgets with gtk. see where you get. try do xmms (winamp etc.). efl drops into this kind of ui seamlessly as it provides a canvas as the core drawing layer. making such custom ui;s (which many people are rather fond of and make sense in specific cases). try this in gtk (to the point of it being easy): http://www.rasterman.com/files/wp2.avi Wow - awesome! Respect! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Tue, 21 Apr 2009 15:23:46 +0200 Andreas Fischer cyberf...@gmx.net said: Carsten Haitzler (The Rasterman) wrote: http://www.rasterman.com/files/wp2.avi (i'm not done with it yet). This is 100% astonishing and sexy - I want that on my desktop :P Congrats for the good work. it's in e17 in svn :) evas also has a OpenGL engine Sorry for being off-topic, but I've wondered about this for a while... does this mean that e17 will have its own compositing engine? Will it use hardware-accelerated graphics if available? Will that enable other developers to write plugins much like the ones seen in compiz or kwin? no. no compositing engine built-in. there is an extra module (bling) that composits - using xrender. its nothing more than xcompmgr as a module for e. -- - 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: Why enlightenment?
2009/4/21 Andreas Fischer cyberf...@gmx.net: Carsten Haitzler (The Rasterman) wrote: http://www.rasterman.com/files/wp2.avi (i'm not done with it yet). This is 100% astonishing and sexy - I want that on my desktop :P Congrats for the good work. The most exciting thing about e is that it's a combination of bleeding software and arts!!! Usually It's not so easy to have them together :) Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Reading this, I do not consider continuing this discussion useful. Thank you for your reply and happy hacking! Bram On Tue, 2009-04-21 at 21:38 +1000, Carsten Haitzler wrote: On Tue, 21 Apr 2009 13:00:33 +0200 Bram Neijt bne...@gmail.com said: On Sun, 2009-04-19 at 11:52 +1000, Carsten Haitzler wrote: On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt bne...@gmail.com said: This looks like a great list! I'll go through the points one by one... On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote: Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. I'll have to look into how complicated this would be with GTK, but I'll take your word for it. However, if you change the clock from digital to analog, then you will get layout problems. I thought switching glade(/gtkbuilder) files would be perfect for something like that and with the glade interface developer, making new layouts would be easy for everybody. I'll take your word for it that is really is easier. trust me - e is by far more flexible than gtk in changing look,layout and feel just by changing a theme data file. i wrote gtk's theme system. i also wrote e... :) Yes, I trust you on that. But I don't think theming is always a good thing. That is, however, just a matter of opinion. 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. I really thought finger scrolling would be a task that should be implemented by the touchscreen driver/library software, or if needed the window manager, but not the GUI toolkit. What about right-clicking support? If you put right-clicking support, scrolling, and other emulate a normal mouse behavior in the GUI toolkit, I think you are putting it in the wrong place. 1. absolutely not. scrolling is an app+toolkit thing. scrolling needs to track the mouse position. i can go into all the logic an math why - as it also conflicts with normal use (like dragging a slider, pressing buttons in a scrollable region etc.). the toolkit/app needs to figure out did they want to slide the slider, or scroll the view? for example. trust me that its a toolkit/app problem. The only example I can state here is something I first say implemented by a logitech driver on windows. To scroll you pressed a special button on your mouse anywhere on the screen and then moved the pointer away to start scrolling. The further away from your initial point, the faster you scolled. This worked with all toolkits (including Java SWT, GTK+, Firefox's toolkit). So I can't get myself to trust you on that. that's because there was a SPECIAL BUTTON! a special app can grab that 1 button everywhere (thus its not useful for anything BUT the scrolling). also note.. it's WINDOWS. this is NOT windows. this is X. only the tolkit and app know the context of whats inside a window and only they can (sanely) handle mouse events within that window and know what they were for. be they presses etc. yes - given a SPECIAL button it would be possible to intercept and figur eit out - but then.. how do you know WHICH thing to scroll? you have 2 scrollviews in a window? one on the top, one on the bottom. which scrolls? only the toolkit knows which should (ie which one you intiially pressed). yes you could try faking mousewheel buttons and this wont move the thing WITH the finger by the distance the finger moved. ie DRAG thge thing as far as you dragged with a finger as there is no correlation between a mouse wheel press and how far something moves in pixels. it's a toolkit issue, 2. right mouse also can be hackishly implemented in the windowing system - but thats wrong, as it has no idea what parts of the screen need a long press for emulating a right mouse. (thats the normal way to do it). this SHOULD be left to the toolkit. only the toolkit knows what parts of the screen are sensitive to a right-mouse press or not. and if it does this... it may as well handle it as along press anyway (as opposed to emulating right-mouse) I thought I could could use my mouse and use the right button on any part of the screen I wanted, without having a toolkit tell me whether I am allowed or not? Even if I have to emulate it some how, if I want to right click on something, the only thing I think the toolkit is allowed to do is sit there and take it ;) you can press the button. but only the TOOKIt knows
Re: Why enlightenment?
Carsten Haitzler (The Rasterman) wrote: On Tue, 21 Apr 2009 13:46:46 +0200 Pander pan...@users.sourceforge.net said: Does something like 'PyEnlightenment' exist? Is this Paroli? If I was to port the application to Paroli or a 'PyEnlightenment', would it also work for noob users on desktops, i.e. can such a toolkit be installed via apt-get from the default Linux distribution repository? yes it does - there are ecore, evas, edje, elementary etc. bindings for python, they may be mostly complete. i don't maintain or use them though. as for apt-get install - you'll need to find some new repositories for that. we are actually preparing a snap of efl right now. elementary isn't included thoguh. I guess you can install everything easily from SVN (see the get_e.sh by Raster). I'm doing it (using my own scripts BTW) for some months and all works always well. So I'd suggest to compile it in your own machine, then you'll be able to use python as C (of course :P) to write your software... I'm doing this and also with the help of Xephyr I can forget to write for a phone. When finally I compile the code for my little ARM boy :P I'm pretty sure that all is working as expected since the toolkits I'm using are good (also) for it! ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Sun, 19 Apr 2009 21:21:39 +0400 Nikita V. Youshchenko yo...@debian.org said: i considered it but as i couldnt do finger scrolling (middle of the window - swipe to scroll) i chose not to try and push the work back onto the app to adapt to a limited window side. Theoretically it should be possible to implement finger scrolling from the middle of the window starting with some recognizable gesture. Althouht don't know how this could be done at technical level. the problem is... it can't be done... unless: 1. you poll often (there goes battery life as you'll need to poll 10+ times a second). you need to poll and query the mouse position/state. this is not an acceptable solution for an embedded device if you care about battery life. 2. xevie - this is an event redirector extension. ALL mouse events can be put through it. this will add an extra 2 context switches for an vent to get to the app and go through such a redirector (eg the wm). xevie also gets little love from the x developers. other than this, it's not possible as ONLY the client that owns the window a listens for events can get events on it. they are only reported to this client (thanks to button grabs being implicit it). also you would need to walk the entire window tree down from the client window AND monitor all changes AND select for mouse events for all these windows AND still not get hem when you press the screen as mouse vents will be reported to the grabbing owner - ie the one that asked for mouse press and release events. so basically even afetr al the pain of doing things you shouldnt (playing wit the internal window tree of an app's window) it still wont work... so .. back to the above 2 methods - both of which really are sub-optimal in reality - apps should probably handle this themselves. i know e's config dialogs mostly dont fit - but that is a todo item There is also everything else. Lots of X apps are not designed for small screen, and fixing all those looks like much more work than making it possible to access larger-than-screen windows. Btw, these two ways don't exclude each other :) no they dont, but see above. its simply not sane to do it. i havent even covered the conflicts of internal scrollbars, sliders etc. inside the apps - now u cant drag those anymore if the window is too bit as it will scroll the window, not move the scrollbar inside the window or the slider. -- - 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: Why enlightenment?
the problem is... it can't be done... unless: skip Hmm... I've heared about more or less generic gestures implementations. A quick google search gives this: http://www.ubuntugeek.com/gestikk-mouse-gesture-recognition-in-ubuntu.html How do they do it? Nikita ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
i considered it but as i couldnt do finger scrolling (middle of the window - swipe to scroll) i chose not to try and push the work back onto the app to adapt to a limited window side. Theoretically it should be possible to implement finger scrolling from the middle of the window starting with some recognizable gesture. Althouht don't know how this could be done at technical level. in reality - apps should probably handle this themselves. i know e's config dialogs mostly dont fit - but that is a todo item There is also everything else. Lots of X apps are not designed for small screen, and fixing all those looks like much more work than making it possible to access larger-than-screen windows. Btw, these two ways don't exclude each other :) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. The edje file for illume is 5 lines of code. In a language where lots of code is in macro definitions that have no block constructs, so they have to be all on one line... or escape every line ending. I wont say it's better in GTK, but it not exactly trivial for E. - Gunnar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Sun, Apr 19, 2009 at 21:50, Gunnar AAstrand Grimnes gunnar.grim...@dfki.de wrote: I wont say it's better in GTK, but it not exactly trivial for E. It IS trivial. Default theme is large, but you can simply override interesting you classes. Look, how it's done in e-wm-theme-illume-shr theme. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Sat, 18 Apr 2009 19:31:39 -0700 Ali alish...@interchange.ubc.ca said: On Sun, 2009-04-19 at 11:28 +1000, Carsten Haitzler wrote: . so what other choices do you have if you have eliminated qt for license reasons and you think gtk is just not up to snuff and is unlikely to get there easily without major breaks? I've been a fan of fltk for a little while now (have only written the most basic things with it and that was 3-4 years ago), what are your opinions of it in regards to the neo? It's very fast and light, I think Dillo is written in fltk and it's lightning fast with a small footprint. What do you guys think about a stack (on top of debian for convenience) that uses flwm and everything else in fltk? isn't fltk just a wrapper around gtk? -- - 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: Why enlightenment?
On Sun, Apr 19, 2009 at 2:59 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 18 Apr 2009 19:31:39 -0700 Ali alish...@interchange.ubc.ca said: On Sun, 2009-04-19 at 11:28 +1000, Carsten Haitzler wrote: . so what other choices do you have if you have eliminated qt for license reasons and you think gtk is just not up to snuff and is unlikely to get there easily without major breaks? I've been a fan of fltk for a little while now (have only written the most basic things with it and that was 3-4 years ago), what are your opinions of it in regards to the neo? It's very fast and light, I think Dillo is written in fltk and it's lightning fast with a small footprint. What do you guys think about a stack (on top of debian for convenience) that uses flwm and everything else in fltk? isn't fltk just a wrapper around gtk? No, it really is a completely independent toolkit and really lightweight. However, this doesn't make it a good choice if you can avoid it. Sure, if you have 16 MB Ram and 8 MB Rom as only storage it is pretty neat. However, we don't have that limitations, so all the disadvantages hit without bringing any advantages at all (nobody would think of an FLTK-only toolkit in an environment with 128 MB Ram). Raster, you wouldn't use it anyway, because it's written in C++ and as far as I know there are no C bindings :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Sun, 19 Apr 2009 21:50:10 +0200
Gunnar AAstrand Grimnes gunnar.grim...@dfki.de wrote:
1. Theming - it keeps resources low and alows us to do everything we
want with GUI! Take shelf widgets as an example - you can change
their look, even functions - like digital clock instead of analog -
without changin the main code. I don't say it's not possible with
GTK but it way more complicated.
The edje file for illume is 5 lines of code.
In a language where lots of code is in macro definitions that have no
block constructs, so they have to be all on one line... or escape
every line ending.
I wont say it's better in GTK, but it not exactly trivial for E.
- Gunnar
Actually, the illume.edc file for FSO MS5.1 and SHR right now is about
2700 lines, and the default.edc is about ten times that. (NOT claiming
they're small, granted) Having burrowed through each of them several
times from start to finish, I can also say that they could easily be
reduced to 2000 lines and probably under 15,000 lines respectively,
just by eliminating commented-out sections, comments, and
simplifying sections that are 'verbose', like having three lines
rel2 {
relative: 0.75 0.75;
}
when it could be one line with rel2.relative: 0.75 0.75;
But the number of lines isn't a useful measure of much anyway, it
reflects thoroughness as much as complexity.
j
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
This looks like a great list! I'll go through the points one by one... On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote: Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. I'll have to look into how complicated this would be with GTK, but I'll take your word for it. However, if you change the clock from digital to analog, then you will get layout problems. I thought switching glade(/gtkbuilder) files would be perfect for something like that and with the glade interface developer, making new layouts would be easy for everybody. I'll take your word for it that is really is easier. 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. I really thought finger scrolling would be a task that should be implemented by the touchscreen driver/library software, or if needed the window manager, but not the GUI toolkit. What about right-clicking support? If you put right-clicking support, scrolling, and other emulate a normal mouse behavior in the GUI toolkit, I think you are putting it in the wrong place. If you think about it like that, then finger friendly means: large buttons, nothing where you have to hit the side, and feedback you can see even with your finger on it. But if the OpenMoko team thinks that the GUI toolkit is the place to fix scrolling, then I can see why it is a good choice. 3. Up-to-date. It's under constant development, and getting better by the day. It's also (Illume and elementary) is well adjusted to phone. Being under constant development is something I don't like about the toolkit. With the little number of developers that there are for things like this, I would consider it a problem because the apps already written get old sooner. Point 1 and 2 I can understand now. As for point 3, I can't really see how that is a benefit. Thank you very much for writing this mail as I can finally get some insight into why that choice has been made and why it seems so ridiculous to me. Bram ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Thu, 16 Apr 2009 09:32:17 +0400 Nikita V. Youshchenko yo...@debian.org said: I wrote a small dialer in python gtk and use normal applications from debian (gpe-calendar, xvkbd keyboard, midori/firefox/arora/elinks browsers, xchat, icewm window manager). This has give me a pretty stable no surprises around corners environment with lots of applications and let me to concentrate on helping kernel, Xorg and ogsmd development. Is your environment finger-friendly? Btw, I all WMs I've tried until now, either try to resize any window to become full-screen, or just keep windows size as is (so part os out of screen). Both ways make parts of windows inaccessible. Especially configuration dialogs. Tried E17 configuration dialogs (with font/scale set to something visible without a microscope), especially in more options mode? Why not just add scroolbars (in the WM frame I mean)? Especially for configuration dialogs. So if an app was not originally written for small screen, it could still be possible to reach everything in it's window. because screen edges are very hard to access thanks to the bevel, and in x (without conflicting with the apps own scrolling - and that then is only with xevie). also because i just never wrote code to do it. i considered it but as i couldnt do finger scrolling (middle of the window - swipe to scroll) i chose not to try and push the work back onto the app to adapt to a limited window side. in reality - apps should probably handle this themselves. i know e's config dialogs mostly dont fit - but that is a todo item. it's being worked on -- - 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: Why enlightenment?
On Thu, 16 Apr 2009 17:11:37 +0200 Bram Neijt bne...@gmail.com said: as such the choice of enviornment, thanks to it running x, is not limited, you can use qt, gtk, sdl, fltk etc. e is a window manager - it happens to also have spawned toolkits that lend themesleves to unique custom ui's and much more flexibility than the larger toolkits. trust me on this - gtk's theme system comes courtesy of me - i wrote it years ago. i know how far you will be able to push gtk (without breaking it and effectively creating a new incompatible toolkit). qt until a few months ago has a major license issue - GPL for a library forces ALL apps to effectively be GPL. for the entire development of gta02 it was GPL. GPL inherently restricts the freedom of app developers to NOT make software GPL (MIT, BSD or any other license they choose). if you chose to ship with a GPL toolkit - then you limit what app developers can do. so qt was right out (and i know a whole bunch of developers who simply dont want todo c++ in order to use qt - they want to use c or something else). so gtk has its limits - also i have heard enough complaints of it being slow - and that is from commercial developers in big electronics houses. they really are not squeakingly happy with gtk and are hunting for other solutions. qt had the license problems until a few months ago. so what other choices do you have if you have eliminated qt for license reasons and you think gtk is just not up to snuff and is unlikely to get there easily without major breaks? True, I expected to like the Freerunner as a phone and thought the whole freedom would just be an added bonus. If the phone isn't that good, I could always fix small bugs and help out. However, it turns out that I can't understand the direction the mainstream development is going, and with this small community, the bugs in other distributions are not small at all. So I seem have to make a choice: put in allot of time, or stick with a product that I can't understand. The last option is just to sell the thing before the value drops to much and buy something else. As you say, choices had to be made and this is it. I don't think I'm closer to understanding the reasoning behind choosing for e, but maybe this is just an opinion, and we should leave it at that. In the meantime I think I'll just have to reset my expectations, and decide what I want to do with this phone. Thank you for your reply. Bram On Thu, 2009-04-16 at 15:02 +0200, arne anka wrote: So what if the company decided to use that money for something you do not want to be part of, or you think they are throwing away your money doing stupid things. Well, I think at that moment you should pawn the product, not endorse it (maybe even publicly denounce it) and then find another company or product you can be happy with. that's a constellation you have to cope with in every commercial product (and even in others, too, though you might not measure your investments in terms of money). what's more, with most companies you don't neither have a saying in what the money is spent for nor do you actually get information about what that company plans are at all. the difference with the freerunner is, that you can install what environment you want and that you are not limited by the decisions the company makes after you bought. with the amount of freedom available, openmoko as company in question cannot be supposed to invest in all and every available technology, be it a desktop environment or merely a toolkit, but instead one way has to be chosen. but om having their money on e does not mean, you are forced to use e. if, on the other hand, you demand that you have a saying in what the company does with your money, clinging to the merely ficitional conception of splitting your money in a part for the actual hardware, a part for development done and a part for development to come -- there won't be many things left you could purchase. btw: that whole question is not at all about e or gtk or qt, but what to expect from a frre device -- and that question in turn has been discussed in extenso already. ___ 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 -- - 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: Why enlightenment?
On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt bne...@gmail.com said: This looks like a great list! I'll go through the points one by one... On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote: Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. I'll have to look into how complicated this would be with GTK, but I'll take your word for it. However, if you change the clock from digital to analog, then you will get layout problems. I thought switching glade(/gtkbuilder) files would be perfect for something like that and with the glade interface developer, making new layouts would be easy for everybody. I'll take your word for it that is really is easier. trust me - e is by far more flexible than gtk in changing look,layout and feel just by changing a theme data file. i wrote gtk's theme system. i also wrote e... :) 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. I really thought finger scrolling would be a task that should be implemented by the touchscreen driver/library software, or if needed the window manager, but not the GUI toolkit. What about right-clicking support? If you put right-clicking support, scrolling, and other emulate a normal mouse behavior in the GUI toolkit, I think you are putting it in the wrong place. 1. absolutely not. scrolling is an app+toolkit thing. scrolling needs to track the mouse position. i can go into all the logic an math why - as it also conflicts with normal use (like dragging a slider, pressing buttons in a scrollable region etc.). the toolkit/app needs to figure out did they want to slide the slider, or scroll the view? for example. trust me that its a toolkit/app problem. 2. right mouse also can be hackishly implemented in the windowing system - but thats wrong, as it has no idea what parts of the screen need a long press for emulating a right mouse. (thats the normal way to do it). this SHOULD be left to the toolkit. only the toolkit knows what parts of the screen are sensitive to a right-mouse press or not. and if it does this... it may as well handle it as along press anyway (as opposed to emulating right-mouse) If you think about it like that, then finger friendly means: large buttons, nothing where you have to hit the side, and feedback you can see even with your finger on it. correct. also that it doesnt need a right mouse button, that it doesnt rely on mouseovers for input/indication (or position of mouse eg - move mouse to edge of window to begin an auto-scroll in that direction). or that some bits of the ui appear when the mosue is over areas. as the mouse only moves while mouse button 1 is pressed down - you need to work with that. you also need other bits of smart eg - finger-scrolling. to determine if a swipe is a scroll or not, handle momentum of the scroll etc. But if the OpenMoko team thinks that the GUI toolkit is the place to fix scrolling, then I can see why it is a good choice. thats what elementary covers - it's 1. really visible flexible - you can change the look dramatically 2. automatically adapts to a new dpi/screen resolution and size nicely 3. already can adapt to finger size. i.e. make any element that is meant to be pressed/interacted with a finger, at least a finger size in size so it can be hint. 4. you also have to adjust for jitter. when you press a soft fleshy finger on a ts - the touch point moves around as pressure changes. you need to be tolerant of movement within a range and properly interpret it. you can fliter all you like in the ts driver - you will still need to deal with this no matter what as pressure makes the point move and filtering more will affect actual dragging once movement has started. you simply need to handle some hysteresis on drags/swipes/scrolls. you ignore initial jitter/small movements until enough movement has happend in 1 direction to consider it a drag. 3. Up-to-date. It's under constant development, and getting better by the day. It's also (Illume and elementary) is well adjusted to phone. Being under constant development is something I don't like about the toolkit. With the little number of developers that there are for things like this, I would consider it a problem because the apps already written get old sooner. Point 1 and 2 I can understand now. As for point 3, I can't really see how that is a benefit. so getting new improvements quickly (instead of waiting years for it or it never happening) is bad? Thank you very much for writing this mail as I can finally get some
Re: Why enlightenment?
On Sun, 2009-04-19 at 11:28 +1000, Carsten Haitzler wrote: . so what other choices do you have if you have eliminated qt for license reasons and you think gtk is just not up to snuff and is unlikely to get there easily without major breaks? I've been a fan of fltk for a little while now (have only written the most basic things with it and that was 3-4 years ago), what are your opinions of it in regards to the neo? It's very fast and light, I think Dillo is written in fltk and it's lightning fast with a small footprint. What do you guys think about a stack (on top of debian for convenience) that uses flwm and everything else in fltk? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Hey Bram, Bram Neijt wrote: When I tried hackable:1 it did not contain a dialer and had no basic phone functionality, but I will be giving it another try in the near future. That's strange, all of our stable releases have always included the dialer. Maybe you tried a daily build? They're not the same yet... HTH, -- khorben On Wed, 2009-04-15 at 23:19 +0200, Cedric Cellier wrote: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) -- Pierre Pronchery, Hackable devices RD, Bearstech email: ppronch...@bearstech.com 42 boulevard Sébastopol PGP: AE49 5F7D D56A 4BD6 7B1F 75003 Paris, France 8655 125C 0FE6 5566 EBD8 Web: http://bearstech.com Phone: +49 177 472 7481 Phone: +33 6 71 62 42 74 Fax: +49 304 208 1861 Fax: +33 1 42 72 20 03 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
That could very well be what went wrong. I'll put hackable:1 on my list and if I experience problems, I'll let you know. Thanks! Bram On Fri, 2009-04-17 at 13:19 +0200, Pierre Pronchery wrote: When I tried hackable:1 it did not contain a dialer and had no basic phone functionality, but I will be giving it another try in the near future. That's strange, all of our stable releases have always included the dialer. Maybe you tried a daily build? They're not the same yet... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Thomas Seiler wrote: Hi, Why enlightenment? | You see things; and you say, 'Why?' | But I dream things that never were; and I say, Why not? |George Bernard Shaw, Thumbs up, here! It was my reply too (Shaw, you only come up before! :P). By the way if I can give my idea, the switch to Enlightenment has been the best decision ever taken by Openmoko imho. This made (or helped) Illume and Elementary to born, giving us a superior GUI system (both from the usability and look point of view). I don't really understand why E shouldn't be used. It has demonstrate to be the best one, so far. -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
I know this is inflammatory, but I really couldn't resist: You see things; and you say, 'Why not?' But I dream things that never were; and I say, Why not not? Bram On Fri, 2009-04-17 at 17:43 +0200, Marco Trevisan (Treviño) wrote: Thomas Seiler wrote: Hi, Why enlightenment? | You see things; and you say, 'Why?' | But I dream things that never were; and I say, Why not? |George Bernard Shaw, Thumbs up, here! It was my reply too (Shaw, you only come up before! :P). By the way if I can give my idea, the switch to Enlightenment has been the best decision ever taken by Openmoko imho. This made (or helped) Illume and Elementary to born, giving us a superior GUI system (both from the usability and look point of view). I don't really understand why E shouldn't be used. It has demonstrate to be the best one, so far. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Enlightenment is the best choice for Freerunner! 1. Theming - it keeps resources low and alows us to do everything we want with GUI! Take shelf widgets as an example - you can change their look, even functions - like digital clock instead of analog - without changin the main code. I don't say it's not possible with GTK but it way more complicated. 2. Finger scrolling - it works by default. If I know that app is written in Elementary - I know that it's finger-friendly. Also - compare matchbox keyboard and illume one - latter is far more finger-friendly. 3. Up-to-date. It's under constant development, and getting better by the day. It's also (Illume and elementary) is well adjusted to phone. Just my 2 cents. Leonti ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Wed, Apr 15, 2009 at 10:57 PM, Bram Neijt bne...@gmail.com wrote: I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? I haven't seen enlightenment being used for over 4 years, huum ? I use it daily on desktop/laptop and at work for over 4 years. I have friends who use it like me... There are external project which use it too... for example : geekbox is switching to E, Calaos the domotic app, and with the wealth of programs out there which are portable portable doesn't mean usable. and can run on top op Linux, this choice really astounds me. I'm only writing this now, because I see that the next Om release (2009) is going to keep focusing on using it. and it's a great thing !! Most people will not find this discussion productive, but please consider giving me some good pointers as I'm having a hard time to get my head around this. As I see it, all embedded devices running some kind of interface use either QT or GTK (QT Phone, Nokia Internet tablet, Sharp Zaurus..) and there are various applications and standards available. focusing on E doesn't mean you can't run any GTK or QT app. It's really like a pc, if you run gnome, can't you run marble or K3B ? If you run KDE4, can't you run firefox or OpenOffice ? The choice for a standard graphical librairy make sense for the OS, but the OS shouldn't forbid you to use any application you want. Obviously, the intergration is better when application are mainly coded with native libs, but, if we are making a choice between GTK or QT... the debate is the same.. my QT apps won't be integrated as well as GTK's ones on a GTK environment and vice versa. Why then go for enlightenment? cause it's great and fun ;) Hoping this is not to inflammatory, Bram ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Dear Martin, I understand that having a choice is a great freedom, but there is another aspect lurking around the corner here: If you buy a product from a company, part of the money you pay is used to further the development of that company. You not only support it at that moment, you support the way it is heading. So what if the company decided to use that money for something you do not want to be part of, or you think they are throwing away your money doing stupid things. Well, I think at that moment you should pawn the product, not endorse it (maybe even publicly denounce it) and then find another company or product you can be happy with. I hope you can see that, although this may seem like nitpicking, there is more then just freedom to do with the hardware as you please. That is why I would still like to understand the logic behind the choices, even though I have the freedom to just go my own way. Thank you for your reply! Bram On Thu, 2009-04-16 at 00:54 +0200, Martin Bernreuther wrote: Am Mittwoch, 15. April 2009 schrieb Bram Neijt: I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? at least one developer from enlightenment (see http://www.enlightenment.org/p.php?p=contactl=en) was working for OpenMoko (http://wiki.openmoko.org/wiki/Who_is_Who): Carsten Haitzler / raster (http://www.rasterman.com/) If enlightenment is well-suited and if you have somebody with such a good knowledge... And now there's a foundation. So why not. There are other approaches and quite a few distributions (http://wiki.openmoko.org/wiki/Distributions) supporting different ones. You have the choice! Starting as a developer, the decision which framework to use might be hard though... (But if you have a choice, you have to take a decision.) Martin ___ 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: Why enlightenment?
I've used debian and it worked, although screen locking was not implemented yet and most of the functionality is placed in an applet which is not at all finger friendly, but ok. I did an update (apt-get update, apt-get dist-upgrade) and that destroyed my xsession configuration and left me with only a terminal. That is when I decided to try switching back to the main stream and try to at least start using it as a phone. In doing that I was so disappointed by it that I couldn't help but start this thread. As most have pointed out, I'll probably be heading back because this is what freedom is all about (as soon as the next FSO milestone is reached I'll probably give it another try). Thank you for your reply. Bram On Thu, 2009-04-16 at 01:25 +0300, Timo Juhani Lindfors wrote: Bram Neijt bne...@gmail.com writes: Saying that the libs are dedicated to the Neo sounds like my worst nightmare: no application anywhere ever uses them.. except for some of I have had these same thoughts for months. Fortunately it is perfectly possible to use freerunner without using E at all. I wrote a small dialer in python gtk and use normal applications from debian (gpe-calendar, xvkbd keyboard, midori/firefox/arora/elinks browsers, xchat, icewm window manager). This has give me a pretty stable no surprises around corners environment with lots of applications and let me to concentrate on helping kernel, Xorg and ogsmd development. ___ 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: Why enlightenment?
In theory this sounds like a good idea, but I think in practice the scrollbars would have to be accessible in the middle of the screen. Because the OpenMoko screen has an edge around it[1], using the edges of the screen means pushing your finger inside a 90* corner and sliding it. Not something I would want to do in every day use I think. I think it may probably be best to not have any functionality at the sides of the screen (in the area half a finger wide around the edges). But that is just my 2cents. Maybe there is a VNC server which already has this functionality and you can test it out by running a VNC server and use a VNC client with that functionality to try it? Good luck and thanks for your reply. Bram [1] Lower then it's surroundings, the screen is recessed? Not sure here :) On Thu, 2009-04-16 at 09:32 +0400, Nikita V. Youshchenko wrote: Why not just add scroolbars (in the WM frame I mean)? Especially for configuration dialogs. So if an app was not originally written for small screen, it could still be possible to reach everything in it's window. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
So what if the company decided to use that money for something you do not want to be part of, or you think they are throwing away your money doing stupid things. Well, I think at that moment you should pawn the product, not endorse it (maybe even publicly denounce it) and then find another company or product you can be happy with. that's a constellation you have to cope with in every commercial product (and even in others, too, though you might not measure your investments in terms of money). what's more, with most companies you don't neither have a saying in what the money is spent for nor do you actually get information about what that company plans are at all. the difference with the freerunner is, that you can install what environment you want and that you are not limited by the decisions the company makes after you bought. with the amount of freedom available, openmoko as company in question cannot be supposed to invest in all and every available technology, be it a desktop environment or merely a toolkit, but instead one way has to be chosen. but om having their money on e does not mean, you are forced to use e. if, on the other hand, you demand that you have a saying in what the company does with your money, clinging to the merely ficitional conception of splitting your money in a part for the actual hardware, a part for development done and a part for development to come -- there won't be many things left you could purchase. btw: that whole question is not at all about e or gtk or qt, but what to expect from a frre device -- and that question in turn has been discussed in extenso already. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Saying it is designed for handheld devices still sound to me like focusing on reimplementing something specially for a kind/set of devices. Instead of the much more productive (IMHO) molding technology into a handheld. I still can't get around the feeling that using e is like re-inventing the wheel for a smaller car. In the end you want something that works in the same way the user expects it to. Although e has a history of ecstatically pleasing features, I never found it any good to work with. I always found it to be cool but never usable (much like wobbly windows in compiz). Maybe then I will never really get the decision, but if you would like to elaborate even further, please consider doing so. As for SHR you mention, I didn't want to try SHR because the wiki[1] states: GSM network is lost after one day of uptime: restart your FR once a day! in the list of known issues. But maybe I should give it a try after all. Bram [1] http://wiki.openmoko.org/wiki/SHR On Thu, 2009-04-16 at 00:30 +0200, Johny Tenfinger wrote: No, you didn't understand me. It isn't dedicated for Neo. It's designed for handheld devices. Like Neo. And under that environment you can still use other toolkits. And when I said about good apps I was thinking about phone apps. And it seems that SHR has really good, e17 phone apps. They would be perfect, if only there is opimd support and some today screen :) 2009/4/16, Bram Neijt bne...@gmail.com: Saying that the libs are dedicated to the Neo sounds like my worst nightmare: no application anywhere ever uses them.. except for some of the programs written specially for the Neo. That would imply that, if you ever want to use an application on the Neo, you will have to port it (or live with the overhead of running multiple GUI toolkits at the same time). Saying we only need good apps sounds like a big understatement of the problem. The open source world is full of good apps, the problem is: not only do we need good apps, they need to be coded from scratch. I'm not familiar with the layout possibilities of e, however in my experience, the more freedom you give the developers, the more horrid the design :(. This often leeds to differently sized fonts, with buttons sized to the text they contain, and no place for the user to start or stop looking at the application. I've even seen interfaces where you where never sure weather something was a button or not, let alone what would happen if you tried to click on it. Most developers are like people making their first Powerpoint presentation. Everybody has seen those: everything has a different color, size, and it all flies around with sound effects. Bram On Wed, 2009-04-15 at 23:35 +0200, Johny Tenfinger wrote: E libraries seems to be a fastest and lightnest on Neo hardware. When using proper theme of course. And they provide very nice way for layouting. I was sceptic about e too, but when I see that libs in action (from both user and developer side), I'm sure that was good decision. There is even Illume and Elememtary, which are dedicated to devices like Neo. We only need good apps, which are using those libs. 2009/4/15, Cedric Cellier ri...@happyleptic.org: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ 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 ___ 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: Why enlightenment?
True, I expected to like the Freerunner as a phone and thought the whole freedom would just be an added bonus. If the phone isn't that good, I could always fix small bugs and help out. However, it turns out that I can't understand the direction the mainstream development is going, and with this small community, the bugs in other distributions are not small at all. So I seem have to make a choice: put in allot of time, or stick with a product that I can't understand. The last option is just to sell the thing before the value drops to much and buy something else. As you say, choices had to be made and this is it. I don't think I'm closer to understanding the reasoning behind choosing for e, but maybe this is just an opinion, and we should leave it at that. In the meantime I think I'll just have to reset my expectations, and decide what I want to do with this phone. Thank you for your reply. Bram On Thu, 2009-04-16 at 15:02 +0200, arne anka wrote: So what if the company decided to use that money for something you do not want to be part of, or you think they are throwing away your money doing stupid things. Well, I think at that moment you should pawn the product, not endorse it (maybe even publicly denounce it) and then find another company or product you can be happy with. that's a constellation you have to cope with in every commercial product (and even in others, too, though you might not measure your investments in terms of money). what's more, with most companies you don't neither have a saying in what the money is spent for nor do you actually get information about what that company plans are at all. the difference with the freerunner is, that you can install what environment you want and that you are not limited by the decisions the company makes after you bought. with the amount of freedom available, openmoko as company in question cannot be supposed to invest in all and every available technology, be it a desktop environment or merely a toolkit, but instead one way has to be chosen. but om having their money on e does not mean, you are forced to use e. if, on the other hand, you demand that you have a saying in what the company does with your money, clinging to the merely ficitional conception of splitting your money in a part for the actual hardware, a part for development done and a part for development to come -- there won't be many things left you could purchase. btw: that whole question is not at all about e or gtk or qt, but what to expect from a frre device -- and that question in turn has been discussed in extenso already. ___ 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: Why enlightenment?
On Thu, Apr 16, 2009 at 16:47, Bram Neijt bne...@gmail.com wrote: As for SHR you mention, I didn't want to try SHR because the wiki[1] states: GSM network is lost after one day of uptime: restart your FR once a day! in the list of known issues. But maybe I should give it a try after all. I don't know who posted that known issue on wiki. I have never heard about it. Maybe it's some old problem, since before I joined to SHR community. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Johny Tenfinger schrieb: On Thu, Apr 16, 2009 at 16:47, Bram Neijt bne...@gmail.com wrote: As for SHR you mention, I didn't want to try SHR because the wiki[1] states: GSM network is lost after one day of uptime: restart your FR once a day! in the list of known issues. But maybe I should give it a try after all. I don't know who posted that known issue on wiki. I have never heard about it. Maybe it's some old problem, since before I joined to SHR community. I'm not sure if it it was the same problem as mentioned in the wiki, but I've experienced something similar with the latest (as of some weeks ago) SHR Testing, GSM died on me every now and then, usually after a number of phone calls/SMS messages, and usually more often than just once a day. On the bright side, I didn't have any problems after upgrading to SHR unstable. Of course, YMMV, it's unstable after all, but trying can't hurt, can it? :) HTH, Konstantin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Now testing is equal unstable ;) And before that unstable was more stable than testing :D ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Why enlightenment?
I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? I haven't seen enlightenment being used for over 4 years, and with the wealth of programs out there which are portable and can run on top op Linux, this choice really astounds me. I'm only writing this now, because I see that the next Om release (2009) is going to keep focusing on using it. Most people will not find this discussion productive, but please consider giving me some good pointers as I'm having a hard time to get my head around this. As I see it, all embedded devices running some kind of interface use either QT or GTK (QT Phone, Nokia Internet tablet, Sharp Zaurus..) and there are various applications and standards available. Why then go for enlightenment? Hoping this is not to inflammatory, Bram ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
E libraries seems to be a fastest and lightnest on Neo hardware. When using proper theme of course. And they provide very nice way for layouting. I was sceptic about e too, but when I see that libs in action (from both user and developer side), I'm sure that was good decision. There is even Illume and Elememtary, which are dedicated to devices like Neo. We only need good apps, which are using those libs. 2009/4/15, Cedric Cellier ri...@happyleptic.org: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ 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: Why enlightenment?
When I tried hackable:1 it did not contain a dialer and had no basic phone functionality, but I will be giving it another try in the near future. Thank you for your reply. Bram On Wed, 2009-04-15 at 23:19 +0200, Cedric Cellier wrote: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ 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: Why enlightenment?
Saying that the libs are dedicated to the Neo sounds like my worst nightmare: no application anywhere ever uses them.. except for some of the programs written specially for the Neo. That would imply that, if you ever want to use an application on the Neo, you will have to port it (or live with the overhead of running multiple GUI toolkits at the same time). Saying we only need good apps sounds like a big understatement of the problem. The open source world is full of good apps, the problem is: not only do we need good apps, they need to be coded from scratch. I'm not familiar with the layout possibilities of e, however in my experience, the more freedom you give the developers, the more horrid the design :(. This often leeds to differently sized fonts, with buttons sized to the text they contain, and no place for the user to start or stop looking at the application. I've even seen interfaces where you where never sure weather something was a button or not, let alone what would happen if you tried to click on it. Most developers are like people making their first Powerpoint presentation. Everybody has seen those: everything has a different color, size, and it all flies around with sound effects. Bram On Wed, 2009-04-15 at 23:35 +0200, Johny Tenfinger wrote: E libraries seems to be a fastest and lightnest on Neo hardware. When using proper theme of course. And they provide very nice way for layouting. I was sceptic about e too, but when I see that libs in action (from both user and developer side), I'm sure that was good decision. There is even Illume and Elememtary, which are dedicated to devices like Neo. We only need good apps, which are using those libs. 2009/4/15, Cedric Cellier ri...@happyleptic.org: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ 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: Why enlightenment?
Bram Neijt bne...@gmail.com writes: Saying that the libs are dedicated to the Neo sounds like my worst nightmare: no application anywhere ever uses them.. except for some of I have had these same thoughts for months. Fortunately it is perfectly possible to use freerunner without using E at all. I wrote a small dialer in python gtk and use normal applications from debian (gpe-calendar, xvkbd keyboard, midori/firefox/arora/elinks browsers, xchat, icewm window manager). This has give me a pretty stable no surprises around corners environment with lots of applications and let me to concentrate on helping kernel, Xorg and ogsmd development. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
No, you didn't understand me. It isn't dedicated for Neo. It's designed for handheld devices. Like Neo. And under that environment you can still use other toolkits. And when I said about good apps I was thinking about phone apps. And it seems that SHR has really good, e17 phone apps. They would be perfect, if only there is opimd support and some today screen :) 2009/4/16, Bram Neijt bne...@gmail.com: Saying that the libs are dedicated to the Neo sounds like my worst nightmare: no application anywhere ever uses them.. except for some of the programs written specially for the Neo. That would imply that, if you ever want to use an application on the Neo, you will have to port it (or live with the overhead of running multiple GUI toolkits at the same time). Saying we only need good apps sounds like a big understatement of the problem. The open source world is full of good apps, the problem is: not only do we need good apps, they need to be coded from scratch. I'm not familiar with the layout possibilities of e, however in my experience, the more freedom you give the developers, the more horrid the design :(. This often leeds to differently sized fonts, with buttons sized to the text they contain, and no place for the user to start or stop looking at the application. I've even seen interfaces where you where never sure weather something was a button or not, let alone what would happen if you tried to click on it. Most developers are like people making their first Powerpoint presentation. Everybody has seen those: everything has a different color, size, and it all flies around with sound effects. Bram On Wed, 2009-04-15 at 23:35 +0200, Johny Tenfinger wrote: E libraries seems to be a fastest and lightnest on Neo hardware. When using proper theme of course. And they provide very nice way for layouting. I was sceptic about e too, but when I see that libs in action (from both user and developer side), I'm sure that was good decision. There is even Illume and Elememtary, which are dedicated to devices like Neo. We only need good apps, which are using those libs. 2009/4/15, Cedric Cellier ri...@happyleptic.org: If you'd prefer using Qt or GTK, both have dedicated distros. For instance, hackable:1 is the continuation of the initial OpenMoko software stack that was based on GTK. As to why openmoko guys decided one day to sacrifice all the work already done with GTK and to go for a plain new framework, well you should as well ask Why those Moai on the Easter island ? :-) ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Am Mittwoch, 15. April 2009 schrieb Bram Neijt: I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? at least one developer from enlightenment (see http://www.enlightenment.org/p.php?p=contactl=en) was working for OpenMoko (http://wiki.openmoko.org/wiki/Who_is_Who): Carsten Haitzler / raster (http://www.rasterman.com/) If enlightenment is well-suited and if you have somebody with such a good knowledge... And now there's a foundation. So why not. There are other approaches and quite a few distributions (http://wiki.openmoko.org/wiki/Distributions) supporting different ones. You have the choice! Starting as a developer, the decision which framework to use might be hard though... (But if you have a choice, you have to take a decision.) Martin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
On Wed, 15 Apr 2009 22:57:57 +0200 Bram Neijt bne...@gmail.com wrote: I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? I haven't seen enlightenment being used for over 4 years, and with the wealth of programs out there which are portable and can run on top op Linux, this choice really astounds me. I'm only writing this now, because I see that the next Om release (2009) is going to keep focusing on using it. For awhile Openmoko had hired Enlightenment's lead developer (Rasterman), so that probably explains their predisposition to using it. E17 also has the advantage of being both slick (in terms of resources) and looking damn good. This has nothing to do with the GUI used by the apps, any more then using fluxbox on a desktop would affect my ability to run gnome or kde applications. As I see it, all embedded devices running some kind of interface use either QT or GTK (QT Phone, Nokia Internet tablet, Sharp Zaurus..) and there are various applications and standards available. Why then go for enlightenment? Hoping this is not to inflammatory, Bram What do you mean by standards in there are various applications and standards available ? As a full-blown window manager, enlightenment will do everything any other full-featured window manager can do (well, except have releases that aren't just snapshots). Also, remember that Qt Phone and the Nokia tablets use their own gui libraries too (Qtextended and hildon respectively), that applications have to be ported to in order to look native. I'm not familiar with Sharp Zaurus-based distros, but don't they normally use gpe software, which is in most openmoko distro's repos? -- Joseph Booker signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
I wrote a small dialer in python gtk and use normal applications from debian (gpe-calendar, xvkbd keyboard, midori/firefox/arora/elinks browsers, xchat, icewm window manager). This has give me a pretty stable no surprises around corners environment with lots of applications and let me to concentrate on helping kernel, Xorg and ogsmd development. Is your environment finger-friendly? Btw, I all WMs I've tried until now, either try to resize any window to become full-screen, or just keep windows size as is (so part os out of screen). Both ways make parts of windows inaccessible. Especially configuration dialogs. Tried E17 configuration dialogs (with font/scale set to something visible without a microscope), especially in more options mode? Why not just add scroolbars (in the WM frame I mean)? Especially for configuration dialogs. So if an app was not originally written for small screen, it could still be possible to reach everything in it's window. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Marco Trevisan (Treviño) wrote: In the latest months the enlightenment world has got many updates, but unfortunately the distros available for the FR don't provide the latest versions of the E stack. This is quite normal since they have to share a tested environment, but it makes so hard to use the latest tools (also because the e libs have frequent changes). That's why today I've given to my Toolchain another challenge :P: compiling E from svn (but following the OE bitbakes configurations)... After some hours, I got it and I was able to run the latest illume code in my phone, but without breaking my Om2008.12 installation. In fact I've installed all my new data to /usr/e17, that's why the default e installation that comes with Om2008.12 is not touched at all. Since I was asked for it by some users, I've uploaded newer packages of the latest e17 svn compiled for being installed in /usr/e17 not to break any installation [1]. Follow the previous provided instructions to install it. It includes also elementary; you can try it with: DISPLAY=:0 LD_LIBRARY_PATH=/usr/e17/lib elementary_test Unfortunately this build (and the previous one) isn't compatibile with latest libeWebkit that I've planned to recompile to make it work with eve (the new ewww name ;)). Bye. [1] http://downloads.tuxfamily.org/3v1deb/openmoko/e17-illume-elementary%2bsvn20090402.tar.bz2 -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
shr-unstable is now using very hot new enlightenment revision ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Johny Tenfinger wrote: shr-unstable is now using very hot new enlightenment revision ;) Yes I know that... But I mostly use Om2008 so to stay a little more on the bleeding edge I have to compile, and I've always done for months :P -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Openmoko unstable and anything based on fso/milestone5.5 has stayed current to the newest revision of enlightenment for over a month now. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
window full screen via enlightenment _remote
Hi, is it somehow possible to send a fullscreen command via enlightenment_remote to a application window? Or to have it in the illume simple_menu? Thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment doesn't want to run anymore
My best guess would be that either your config is causing a problem (something along the lines of rm -r ~/.e may fix ... or maybe more xserver specific configs) or something from angstrom was pulled in and not removed or overwritten. If you are getting a segfault then the latter is probably more likely. yea, already tried rm -r ~/.e didn't help, tried md5summing all those enlightenment specific init and theme files and those enlightenment binaries, all is like it was when newly installed, it should be some other package i pulled from angstrom or something In the end, when playing with repositories outside the control of OM, you have to be prepared to reflash or delve deep to clean up the mess, if one occurs. i guess i'll just flash a new image, thanks alot for your time Sarton. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment doesn't want to run anymore
no one has any idea what the segfault could be caused from? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment doesn't want to run anymore
Flyin_bbb8 wrote: no one has any idea what the segfault could be caused from? I haven't seen the original mail but it's most likely a botched update/missing library or incompatible library/binary. Make sure you're not mixing repos and/or stick to a stable branch. Reflash is all I can suggest. Good luck. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment doesn't want to run anymore
here's the original mail i installed were pythm , mplayer then i uninstalled them, after a reboot the screen shows starting atd daemon:atd. last thing and nothing after, i tried running /etc/init.d/xserver-nodm start, and looked at log in /tmp/x.log # RUN INIT: /usr/bin/enlightenment_init '/usr/share/enlightenment/data/init/illume_init.edj' '1' '0' 'Enlightenment' '0.16.999.050' # Segmentation fault # ESTART: 1.77762 [0.95707] - test file format support # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 # waiting for X server to shut down FreeFontPath: FPE built-ins refcount is 2, should be 1; fixing. this is with illume as default_profile, i change that to ASU and i get the following, i can see the booting screen with the green bar for around 0.2 second then back to the atd , now /tmp/x.log shows # RUN INIT: /usr/bin/enlightenment_init '/usr/share/enlightenment/data/init/asu_init.edj' '4' '0' 'Enlightenment' '0.16.999.050' # ESTART: 2.46682 [1.61394] - test file format support # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 # waiting for X server to shut down E17 INIT: XINERAMA CHOSEN: [0], 480x640+0+0 # FreeFontPath: FPE built-ins refcount is 2, should be 1; fixing. where can i go from here!? another thing worth mentioning is that couple of days ago the thing stopped at starting atd daemon:atd. again but Xglamo wasn't starting, i went to check /usr/bin/Xglamo to find that it's 0 bytes!, i just scp a new one from a 2008.12.tar.gz back to freerunner and it worked again. and no i only added angstrom repo to install mplayer then removed it , i wonder what 1011 exit code means? # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment doesn't want to run anymore
Flyin_bbb8 wrote: here's the original mail i installed were pythm , mplayer then i uninstalled them, after a reboot the screen shows starting atd daemon:atd. last thing and nothing after, i tried running /etc/init.d/xserver-nodm start, and looked at log in /tmp/x.log # RUN INIT: /usr/bin/enlightenment_init '/usr/share/enlightenment/ data/init/illume_init.edj' '1' '0' 'Enlightenment' '0.16.999.050' # Segmentation fault # ESTART: 1.77762 [0.95707] - test file format support [...snip...] # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 and no i only added angstrom repo to install mplayer then removed it , i wonder what 1011 exit code means? # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 Unfortunately I don't have the time to trace your error. This is probably a question only a dev could answer or someone with intimate knowledge of rc components. My best guess would be that either your config is causing a problem (something along the lines of rm -r ~/.e may fix ... or maybe more xserver specific configs) or something from angstrom was pulled in and not removed or overwritten. If you are getting a segfault then the latter is probably more likely. In the end, when playing with repositories outside the control of OM, you have to be prepared to reflash or delve deep to clean up the mess, if one occurs. Good luck! Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[2008.12] Enlightenment doesn't want to run anymore
hey, i have been updating software on my freerunner last things i installed were pythm , mplayer then i uninstalled them, after a reboot the screen shows starting atd daemon:atd. last thing and nothing after, i tried running /etc/init.d/xserver-nodm start, and looked at log in /tmp/x.log # RUN INIT: /usr/bin/enlightenment_init '/usr/share/enlightenment/data/init/illume_init.edj' '1' '0' 'Enlightenment' '0.16.999.050' # Segmentation fault # ESTART: 1.77762 [0.95707] - test file format support # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 # waiting for X server to shut down FreeFontPath: FPE built-ins refcount is 2, should be 1; fixing. this is with illume as default_profile, i change that to ASU and i get the following, i can see the booting screen with the green bar for around 0.2 second then back to the atd , now /tmp/x.log shows # RUN INIT: /usr/bin/enlightenment_init '/usr/share/enlightenment/data/init/asu_init.edj' '4' '0' 'Enlightenment' '0.16.999.050' # ESTART: 2.46682 [1.61394] - test file format support # run-parts: /etc/X11/Xsession.d/90xXWindowManager exited with code 1011 # waiting for X server to shut down E17 INIT: XINERAMA CHOSEN: [0], 480x640+0+0 # FreeFontPath: FPE built-ins refcount is 2, should be 1; fixing. where can i go from here!? another thing worth mentioning is that couple of days ago the thing stopped at starting atd daemon:atd. again but Xglamo wasn't starting, i went to check /usr/bin/Xglamo to find that it's 0 bytes!, i just scp a new one from a 2008.12.tar.gz back to freerunner and it worked again. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Helge Hafting wrote: Marco Trevisan (Treviño) wrote: - Now you may also configure E, from the wrench, to use the software_16 rendering engine (it causes less quality, but more speed) and a lower framerate value... Where exactly would that be? I tried the wrench, and waded through a multitude of options. But I didn't find this software_16 thing. Or does it require something beyond your /usr/e17/ tree? Something that might be lacking from SHR? SHR should use that rendering setting by default, in illume-.svn you've to go to the wrench - Advanced - Engine - Default Engine - SOFTWARE_16 ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Fri, Jan 9, 2009 at 5:47 AM, Marco Trevisan (Treviño) m...@3v1n0.net wrote: In the latest months the enlightenment world has got many updates, but unfortunately the distros available for the FR don't provide the latest versions of the E stack. This is quite normal since they have to share a tested environment, but it makes so hard to use the latest tools (also because the e libs have frequent changes). That's why today I've given to my Toolchain another challenge :P: compiling E from svn (but following the OE bitbakes configurations)... For your information, Raster has the kindness now and then to keep us (the SHR team) in touch and to give us information on which version of e-wm we should build. If you try unstable, it's generally close to HEAD, but sometimes HEAD doesn't compile, or generates problems. For a time it was UTF8 not being handled. These days it's the dictionnary being slow as hell. Don't worry, as soon as a stabler version will hit the ground, we'll ship with it. -- Julien Cassignol http://www.ainulindale.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Helge Hafting wrote: Marco Trevisan (Treviño) wrote: - Now you may also configure E, from the wrench, to use the software_16 rendering engine (it causes less quality, but more speed) and a lower framerate value... Where exactly would that be? I tried the wrench, and waded through a multitude of options. But I didn't find this software_16 thing. Or does it require something beyond your /usr/e17/ tree? Something that might be lacking from SHR? SHR should use that rendering setting by default, in illume-.svn you've to go to the wrench - Advanced - Engine - Default Engine - SOFTWARE_16 ;) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Joel Newkirk wrote: On Fri, 09 Jan 2009 05:47:14 +0100, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Soon, I'd like to give a newer try to guarana and enjoy (not forgetting the latest elemetary stuffs!)... :P Bye... ;) Thank you for this. :) Please post Elementary when you can - it's utilized for Raster's Alarm as well as the SHR telephony apps. Ok, btw I'm not so sure that the crashes you've witht the SHR tools are due to that library only... Maybe they simply have been linked with an older library, so there could be a symbols incompatibility. Maybe removing the LD_LIBRARY_PATH env variable could fix this issue (so making the non-e apps using the /usr/lib libraries)... I've not tested it so much since I'm using an Om2008-based distro and there some efl apps (like neon) crashes too. -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
I'm not sure if you are factoring this into your considerations or not, but all the apps that segfault when launched from GUI do NOT segfault when run from SSH. They all work just fine. Moreover, if the alarm clock app (which segfaults from GUI) is run because the alarm is going off, it works fine. However, these apps do still segfault after running from a GUI terminal (I use vala-terminal) on the phone. The alarm segfaults immediately after the debug output stating that it is starting elementary (or something to that effect, all I remember is that it crashes right after mentioning elementary). -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Mon, Jan 12, 2009 at 9:02 PM, The Digital Pioneer digitalpion...@gmail.com wrote: I'm not sure if you are factoring this into your considerations or not, but all the apps that segfault when launched from GUI do NOT segfault when run from SSH. They all work just fine. Moreover, if the alarm clock app (which segfaults from GUI) is run because the alarm is going off, it works fine. However, these apps do still segfault after running from a GUI terminal (I use vala-terminal) on the phone. The alarm segfaults immediately after the debug output stating that it is starting elementary (or something to that effect, all I remember is that it crashes right after mentioning elementary). The LD_LIBRARY_PATH is probably getting set, or changed, after the GUI is run but is properly set for terminal sessions. Try writing a script that sets the proper environment and then run the apps from the GUI using that script. If it works then you need to find where in the GUI setup the environment is getting changed. Angus -- Angus Ainslie http://www.handheldshell.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Angus Ainslie wrote: On Mon, Jan 12, 2009 at 9:02 PM, The Digital Pioneer digitalpion...@gmail.com wrote: I'm not sure if you are factoring this into your considerations or not, but all the apps that segfault when launched from GUI do NOT segfault when run from SSH. They all work just fine. Moreover, if the alarm clock app (which segfaults from GUI) is run because the alarm is going off, it works fine. However, these apps do still segfault after running from a GUI terminal (I use vala-terminal) on the phone. The alarm segfaults immediately after the debug output stating that it is starting elementary (or something to that effect, all I remember is that it crashes right after mentioning elementary). The LD_LIBRARY_PATH is probably getting set, or changed, after the GUI is run but is properly set for terminal sessions. Try writing a script that sets the proper environment and then run the apps from the GUI using that script. If it works then you need to find where in the GUI setup the environment is getting changed. If you've changed the /usr/bin/enlightenment_start.oe as I've suggested, surely the LD_LIBRARY_PATH is affected. So, removing that parameter from there would fix the issues, since e17 should take the E_PREFIX var to get the needed libraries from the /usr/e17 path. I've just tested this in my Om2008 environment, and now I can run with no problem my old efl apps (neon, omview, om-settings...). -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
OK! Got it. In my GUI, LD_LIBRARY_PATH was set to /usr/etc/e17: while in SSH it was empty. I wrote a script that simply unsets LD_LIBRARY_PATH and runs the first parameter and it works. :D I just added it to the commands to run in all the .desktop files, and voila! It's fixed (dirtily, but effectively). Here's the script, if anyone wants to copy it. It's hardly worth copying though, it's so simple #!/bin/bash unset LD_LIBRARY_PATH $1 -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Fri, 09 Jan 2009 05:47:14 +0100, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Soon, I'd like to give a newer try to guarana and enjoy (not forgetting the latest elemetary stuffs!)... :P Bye... ;) Thank you for this. :) Please post Elementary when you can - it's utilized for Raster's Alarm as well as the SHR telephony apps. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Sat, 10 Jan 2009 03:40:19 -0500 Joel Newkirk freerun...@newkirk.us babbled: nb. anyone using elementary... http://trac.enlightenment.org/e/wiki/Elementary i wrote a quick intro to it... hello world and a this is what it is and how it looks/works :) On Fri, 09 Jan 2009 05:47:14 +0100, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Soon, I'd like to give a newer try to guarana and enjoy (not forgetting the latest elemetary stuffs!)... :P Bye... ;) Thank you for this. :) Please post Elementary when you can - it's utilized for Raster's Alarm as well as the SHR telephony apps. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - 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: On the Enlightenment Bleeding Edge
Thanks for working on this. I tried this new enlightenment on top of SHR. It looks good and starts quickly, but unfortunately I can't use it. Problems: * None of the SHR phone apps works. Dialer, Contacts, Messages all fail with segmentation faults now. So I have to revert, because I need the phone. * quite a few apps show with blank icons. No big deal because the name is still there. Probably just some path problem - that I could fix myself if it weren't for the phone-app problems. Rebooting the phone didn't change anything. I'll revert for now. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Marco Trevisan (Treviño) wrote: - Now you may also configure E, from the wrench, to use the software_16 rendering engine (it causes less quality, but more speed) and a lower framerate value... Where exactly would that be? I tried the wrench, and waded through a multitude of options. But I didn't find this software_16 thing. Or does it require something beyond your /usr/e17/ tree? Something that might be lacking from SHR? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Advanced-Engine. Framerate is under Advanced-Performance but is awkward to use there - instead use the variation under Display-Framerate. j On Fri, 09 Jan 2009 11:40:49 +0100, Helge Hafting helge.haft...@hist.no wrote: Marco Trevisan (Treviño) wrote: - Now you may also configure E, from the wrench, to use the software_16 rendering engine (it causes less quality, but more speed) and a lower framerate value... Where exactly would that be? I tried the wrench, and waded through a multitude of options. But I didn't find this software_16 thing. Or does it require something beyond your /usr/e17/ tree? Something that might be lacking from SHR? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Fri, Jan 9, 2009 at 4:35 AM, Helge Hafting helge.haft...@hist.no wrote: Thanks for working on this. I tried this new enlightenment on top of SHR. It looks good and starts quickly, but unfortunately I can't use it. Problems: * None of the SHR phone apps works. Dialer, Contacts, Messages all fail with segmentation faults now. So I have to revert, because I need the phone. * quite a few apps show with blank icons. No big deal because the name is still there. Probably just some path problem - that I could fix myself if it weren't for the phone-app problems. Rebooting the phone didn't change anything. I'll revert for now. I'm having exactly the same issues. :( I notice, however, that the phone apps work from SSH. Just not from GUI. Anyone know how to revert the icons, and/or have any idea why the phone apps segfault when launched from GUI now? For me, the segfaulting apps are Alarm, Dialer, Contacts, and Messages. All 4 can be run from SSH without a problem. -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
On Fri, 9 Jan 2009 15:18:27 -0600, The Digital Pioneer digitalpion...@gmail.com wrote: On Fri, Jan 9, 2009 at 4:35 AM, Helge Hafting helge.haft...@hist.no wrote: Thanks for working on this. I tried this new enlightenment on top of SHR. It looks good and starts quickly, but unfortunately I can't use it. Problems: * None of the SHR phone apps works. Dialer, Contacts, Messages all fail with segmentation faults now. So I have to revert, because I need the phone. * quite a few apps show with blank icons. No big deal because the name is still there. Probably just some path problem - that I could fix myself if it weren't for the phone-app problems. Rebooting the phone didn't change anything. I'll revert for now. I'm having exactly the same issues. :( I notice, however, that the phone apps work from SSH. Just not from GUI. Anyone know how to revert the icons, and/or have any idea why the phone apps segfault when launched from GUI now? For me, the segfaulting apps are Alarm, Dialer, Contacts, and Messages. All 4 can be run from SSH without a problem. -- Thanks, The Digital Pioneer Something those failing apps ALL have in common: Elementary. Not an answer, but hopefully a useful clue. Might be a problem relating to /usr/share/elementary/themes - the edj file they all use for their visual appearance lives there. Or it might simply be an incompatibility between the already-installed Elementary and the new E17, requiring a newly-build Elementary to match. I've installed this E17 build under 2008.12 in my NAND, will try it under SHR on uSD later tonight or tomorrow and see what I see. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
On the Enlightenment Bleeding Edge
In the latest months the enlightenment world has got many updates, but
unfortunately the distros available for the FR don't provide the latest
versions of the E stack. This is quite normal since they have to share a
tested environment, but it makes so hard to use the latest tools (also
because the e libs have frequent changes).
That's why today I've given to my Toolchain another challenge :P:
compiling E from svn (but following the OE bitbakes configurations)...
After some hours, I got it and I was able to run the latest illume code
in my phone, but without breaking my Om2008.12 installation.
In fact I've installed all my new data to /usr/e17, that's why the
default e installation that comes with Om2008.12 is not touched at all.
If you want to try this too, you could simply follow these steps:
- extract this archive [1] to / (it will automatically put all the
needed data in /usr/e17)
- editing the /usr/bin/enlightenment_start.oe script by adding the
following code before of exec enlightenment_start $E_PROFILE:
export E_PREFIX=/usr/e17
export LD_LIBRARY_PATH=$E_PREFIX/lib:$LD_LIBRARY_PATH
export PATH=$E_PREFIX/bin:$PATH
(you've also to check that your enlightenment profile is set to
illume in /etc/enlightenment/default_profile)
- mv ~/.e/e/config /dev/null (or to any other location)
- Restart your xserver with /etc/init.d/xserver-nodm {stop,start}
- Now you may also configure E, from the wrench, to use the
software_16 rendering engine (it causes less quality, but more
speed) and a lower framerate value...
- if you prefer, you can also use an illume theme coming with SHR or
Om2008.12, simply put it in ~/.e/e/themes/illume.edj
Ok, now you've a fresh install of Enlightenment running instead of the
default one (that can be resumed with a simple rm -rf /usr/e17), but
nothing more... However I didn't made this effort just to get the newest
environment (also if I'd be able to :P), but my final wish was giving a
try to ewww and libeWebKit [2]!
In few words webkit is going to support the EFL toolkit and Gustavo
Barbieri wrote a nice first implementation of this library in the ewww
(test?)browser.
Since the day I saw the announcement I wanted to try it in my phone, and
after that I got webkit compiled I had been able to see ewww in action:
[3], [4], [5]! Also if it's very young, it's so nice: very light, fast
and supports natively (thanks to the efl) the finger scrolling (that,
unfortunately, is quite slow :|)!
However, to try this too :P, you have just to extract to / this archive
[6] that will put to /usr/e17 the ewww data and the libewebkit library.
To run it (I was too lazy for adding a .desktop file :D):
DISPLAY=:0 LD_LIBRARY_PATH=/usr/e17/lib /usr/e17/ewww
I think that this could really become our browser in a near future...!!!
Soon, I'd like to give a newer try to guarana and enjoy (not forgetting
the latest elemetary stuffs!)... :P
Bye... ;)
[1]
http://downloads.tuxfamily.org/3v1deb/openmoko/e17-illume%2bsvn20090109.tar.bz2
[2]
http://blog.gustavobarbieri.com.br/2008/12/22/webkit-efl-interface-prototype/
[3] http://3v1n0.net/openmoko/ewww-3v1n0.net.png
[4] http://3v1n0.net/openmoko/ewww-flickr-Freerunner.png
[5] http://3v1n0.net/openmoko/ewww-google.png
[6]
http://downloads.tuxfamily.org/3v1deb/openmoko/ewww-libeWebKit%2bgit20090109.tar.bz2
--
Treviño's World - Life and Linux
http://www.3v1n0.net/
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
Marco Trevisan (Treviño) wrote: To run it (I was too lazy for adding a .desktop file :D): DISPLAY=:0 LD_LIBRARY_PATH=/usr/e17/lib /usr/e17/ewww Small typo: DISPLAY=:0 LD_LIBRARY_PATH=/usr/e17/lib /usr/e17/bin/ewww -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: On the Enlightenment Bleeding Edge
OK, I changed out the illume.edj file, but I still have a nasty icon set, and three apps (Contacts and Settings and pythm) have no icons. How do I revert back to the old icons? Also, in the startup config, I told it to add mplayer to the desktop (just to see what it did) and it does nothing (I assume it runs mplayer, but what good is that??) so how do I get rid of that icon? It's not in /usr/share/applications. :( -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is it possible to keep ASU Enlightenment profile...
I don't want to go off topic but is it possible to use matchbox keyboard under Enlightenment(specifically, under 2008.x of course)? On Mon, Jan 5, 2009 at 10:46 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Mon, 05 Jan 2009 01:39:19 -0800 Vasili Sviridov vsviri...@exceede.com babbled: Daniel Nöthen wrote: I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'll try the SOFTWARE fix. Thanks. Yeah, I've looked into in, and since Illume is E's module with keyboard integrated it'd be impossible to use it standalone. That brings the question - why such a coupled design?? it's more efficient. starts faster. uses less ram. re-uses buts of e's core to save duplication of work and it just was easier. but its available any time if u use e +illume - it just may have been made very hard to access by system integrators. if u want to use illume's keyboard outside of e - well you can't. but if u have e (and the illume module) you can. it's lurking there waiting to be turned on. -- - 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 -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is it possible to keep ASU Enlightenment profile...
Daniel Nöthen wrote: I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'll try the SOFTWARE fix. Thanks. Yeah, I've looked into in, and since Illume is E's module with keyboard integrated it'd be impossible to use it standalone. That brings the question - why such a coupled design?? V. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is it possible to keep ASU Enlightenment profile...
On Mon, 5 Jan 2009 10:52:12 +0100 Atilla Filiz atilla.fi...@gmail.com babbled: absolutely. if you add a .desktop file for it the Category=Keyboard - it'll even be listed in illumes keyboard config dialog - just select it. (mbkbd doesnt come with a .desktop by default). I don't want to go off topic but is it possible to use matchbox keyboard under Enlightenment(specifically, under 2008.x of course)? On Mon, Jan 5, 2009 at 10:46 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Mon, 05 Jan 2009 01:39:19 -0800 Vasili Sviridov vsviri...@exceede.com babbled: Daniel Nöthen wrote: I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'll try the SOFTWARE fix. Thanks. Yeah, I've looked into in, and since Illume is E's module with keyboard integrated it'd be impossible to use it standalone. That brings the question - why such a coupled design?? it's more efficient. starts faster. uses less ram. re-uses buts of e's core to save duplication of work and it just was easier. but its available any time if u use e +illume - it just may have been made very hard to access by system integrators. if u want to use illume's keyboard outside of e - well you can't. but if u have e (and the illume module) you can. it's lurking there waiting to be turned on. -- - 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 -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme -- - 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: Is it possible to keep ASU Enlightenment profile...
On Mon, 05 Jan 2009 01:39:19 -0800 Vasili Sviridov vsviri...@exceede.com babbled: Daniel Nöthen wrote: I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'll try the SOFTWARE fix. Thanks. Yeah, I've looked into in, and since Illume is E's module with keyboard integrated it'd be impossible to use it standalone. That brings the question - why such a coupled design?? it's more efficient. starts faster. uses less ram. re-uses buts of e's core to save duplication of work and it just was easier. but its available any time if u use e +illume - it just may have been made very hard to access by system integrators. if u want to use illume's keyboard outside of e - well you can't. but if u have e (and the illume module) you can. it's lurking there waiting to be turned on. -- - 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: Is it possible to keep ASU Enlightenment profile...
This seems to be a bit outdated, but there you go: http://www.ginguppin.de/node/15 Atilla Filiz wrote: I don't want to go off topic but is it possible to use matchbox keyboard under Enlightenment(specifically, under 2008.x of course)? On Mon, Jan 5, 2009 at 10:46 AM, The Rasterman Carsten Haitzler ras...@rasterman.com mailto:ras...@rasterman.com wrote: On Mon, 05 Jan 2009 01:39:19 -0800 Vasili Sviridov vsviri...@exceede.com mailto:vsviri...@exceede.com babbled: Daniel Nöthen wrote: I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I'll try the SOFTWARE fix. Thanks. Yeah, I've looked into in, and since Illume is E's module with keyboard integrated it'd be impossible to use it standalone. That brings the question - why such a coupled design?? it's more efficient. starts faster. uses less ram. re-uses buts of e's core to save duplication of work and it just was easier. but its available any time if u use e +illume - it just may have been made very hard to access by system integrators. if u want to use illume's keyboard outside of e - well you can't. but if u have e (and the illume module) you can. it's lurking there waiting to be turned on. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com mailto:ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ 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: Is it possible to keep ASU Enlightenment profile...
I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... I don't know how to use the illume keyboard on ASU. But to stop illume segfaulting all the time you need to set the the Engine from SOFTWARE_16 to SOFTWARE in the wrench-menu. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is it possible to keep ASU Enlightenment profile...
... but use Illume's keyboard? Default one in 2008.12 sucks so bad... :( I want to keep ASU profile because if i switch to illume it keeps segfaulting at random actions and intervals... Vasili. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.12] Enlightenment not starting anymore.
On Sat, 27 Dec 2008 15:14:11 +0100, Ivar Mossin ivar.mos...@gmail.com wrote: So now I try to install the suggested package: r...@om-gta02:~# opkg -force-downgrade install http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk Downloading http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk Multiple packages (e-wm and e-wm) providing same name marked HOLD or PREFER. Using latest. Multiple packages (e-wm and e-wm) providing same name marked HOLD or PREFER. Using latest. Installing e-wm (0.16.999.050+svnr37988-r0.1) to root... Collected errors: * ERROR: Package e-wm (parent e-wm) is not available from any configured src. * Failed to download e-wm. Perhaps you need to run 'opkg update'? Which failed. Let's see if there is an e-wm installed: r...@om-gta02:~# opkg list_installed | grep e-wm r...@om-gta02:~# opkg -force-depends remove e-wm No packages removed. So, as far as I can see, the package is in fact not installed. (I did remove it earlier to try to fix the problem). As we see, I don't have the angstrom repository included (anymore), I have run an opkg update and installing the package still wants the newer version. From where does opkg get the information that there is a newer version? There is also no e-wm currently installed on the system. Where does this leave me? What would be a plausible next step? I'm pretty much at a loss, unless it has the angstrom package cached somewhere. Take a look around /tmp, and /var/cache or /var/spool and look for ipks. Opkg stores the lists of available packages in /var/lib/opkg. Another question. When I wanted to install mplayer, which I didn't find in the normal repository, I could of course just install the opk file directly, but then I would not be notified of any updates on that package. So how would I be able to keep the angstrom repository without letting it upgrade all the other packages as well? Thanks for the help so far. Therein lies the problem. :) I don't know of any way currently to accomplish that. The 'correct' solution is to petition for desired packages that are in some 'other' feed to be built for your feed. In this case, that means asking for mplayer to be available in the 2008.x feed. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[2008.12] Enlightenment not starting anymore.
Angstrom is up to svnr27988 now so I'm guessing that's exactly where it got
that. It's a BAD idea to do an upgrade from a 'foreign' repo - pulling
specific packages from a different feed is one thing, but letting it
autonomously replace whatever it wants is a recipe for a broken system...
take a look with opkg list_installed | grep e-wm and see what version of
e-wm is currently in place.
You tried opkg -force-downgrade install
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk;
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk%22
and it failed?Either it's already/still installed (the 27988 version)
or Angstrom is still in the opkg repo lists in /etc/opkg, so if that failed
maybe try opkg -force-depends remove e-wm;opkg install
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk;.
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk%22.
You can open up an ipk with ar x {pkgname.opk} which will give you
control.tar.gz and data.tar.gz (the latter contains the files) but I'd
advise against trying to install most things that way...
j
--
Joel Newkirk
http://jthinks.com http://jthinks.com/ (blog)
http://newkirk.us/om http://newkirk.us/om (FR stuff)
I thought I didn't do an 'opkg upgrade' with the angstrom repository
included. But as we see, I did get the angstrom e-wm at some point. So
that must indeed have happened.
Let's first look at my current opkg repositories:
r...@om-gta02:/etc/opkg# grep . *
Multiverse-feed.conf:src/gz daily-Multiverse
http://downloads.openmoko.org/repository/Multiverse
all-feed.conf:src/gz om-dev-all
http://downloads.openmoko.org/repository/Om2008.8/all
arch.conf:arch all 1
arch.conf:arch any 6
arch.conf:arch noarch 11
arch.conf:arch arm 16
arch.conf:arch armv4t 21
arch.conf:arch om-gta02 26
armv4t-feed.conf:src/gz om-dev-armv4t
http://downloads.openmoko.org/repository/Om2008.8/armv4t
om-gta02-feed.conf:src/gz om-dev-om-gta02
http://downloads.openmoko.org/repository/Om2008.8/om-gta02
This seems fine to me. So I do an update:
r...@om-gta02:~# opkg update
Downloading http://downloads.openmoko.org/repository/Multiverse/Packages.gz
Inflating http://downloads.openmoko.org/repository/Multiverse/Packages.gz
Updated list of available packages in /var/lib/opkg/daily-Multiverse
Downloading http://downloads.openmoko.org/repository/Om2008.8/all/Packages.gz
Inflating http://downloads.openmoko.org/repository/Om2008.8/all/Packages.gz
Updated list of available packages in /var/lib/opkg/om-dev-all
Downloading http://downloads.openmoko.org/repository/Om2008.8/armv4t/Packages.gz
Inflating http://downloads.openmoko.org/repository/Om2008.8/armv4t/Packages.gz
Updated list of available packages in /var/lib/opkg/om-dev-armv4t
Downloading
http://downloads.openmoko.org/repository/Om2008.8/om-gta02/Packages.gz
Inflating http://downloads.openmoko.org/repository/Om2008.8/om-gta02/Packages.gz
Updated list of available packages in /var/lib/opkg/om-dev-om-gta02
So now I try to install the suggested package:
r...@om-gta02:~# opkg -force-downgrade install
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk
Downloading
http://downloads.openmoko.org/repository/Om2008.8/armv4t/e-wm_0.16.999.043+svnr36882-r14.01_armv4t.opk
Multiple packages (e-wm and e-wm) providing same name marked HOLD or
PREFER. Using latest.
Multiple packages (e-wm and e-wm) providing same name marked HOLD or
PREFER. Using latest.
Installing e-wm (0.16.999.050+svnr37988-r0.1) to root...
Collected errors:
* ERROR: Package e-wm (parent e-wm) is not available from any configured src.
* Failed to download e-wm. Perhaps you need to run 'opkg update'?
Which failed. Let's see if there is an e-wm installed:
r...@om-gta02:~# opkg list_installed | grep e-wm
r...@om-gta02:~# opkg -force-depends remove e-wm
No packages removed.
So, as far as I can see, the package is in fact not installed. (I did
remove it earlier to try to fix the problem).
As we see, I don't have the angstrom repository included (anymore), I
have run an opkg update and installing the package still wants the
newer version. From where does opkg get the information that there is
a newer version? There is also no e-wm currently installed on the
system. Where does this leave me? What would be a plausible next step?
Another question. When I wanted to install mplayer, which I didn't
find in the normal repository, I could of course just install the opk
file directly, but then I would not be notified of any updates on that
package. So how would I be able to keep the angstrom repository
without letting it upgrade all the other packages as well?
Thanks for the help so far.
___
Openmoko community mailing list
community@lists.openmoko.org
