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
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
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
