Re: root almighty
Hi Max, I've run as a regular user on Debian, but updates would break most of it. If you are going to try it on Debian, then don't forget the DBus and /dev rights to be set correctly. I have not seen any technical issues with using a normal user[1] and I'm all for it. As far as I know, nobody has enough leadership to get a distribution to actually do this. (If you ask me, this is the likely root of why the OpenMoko phone sucks). Greetings and happy hacking, Bram On Tue, 2009-05-19 at 13:53 +0700, Max wrote: > Hello. > > As far as I know most (all?) distributions for FR use root account to > run phone application and to access device via ssh. To my mind this > introduce great security risk. > > At the same time on my Ubuntu by default root is unable to logon anyhow > and everything is done via sudo. This lets me think that there is no > need to use root account on FR - at least not for running phone > application and for remote access. > > I wonder - is there distribution which tried to address this issue? > Are there any plans to use regular user instead of root in om2009? > Maybe using package-kit (which works via dbus btw) and policy-kit might > help? > > best regards, > Max. > > > ___ > 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: Mer on OpenMoko devices ?
Google thinks you should read this: http://goshawknest.wordpress.com/2009/03/28/maemomer-on-freerunner/ Bram On Fri, 2009-05-01 at 11:26 +0200, Olivier Berger wrote: > Hi. > > Anyone know if http://wiki.maemo.org/Mer (or bits of it) could run on > OpenMoko devices ? > > Best regards, ___ 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 said: > > > On Sun, 2009-04-19 at 11:52 +1000, Carsten Haitzler wrote: > > > On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt 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
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 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 > >
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 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. > > > > > &
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?
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: [Debian] on Freerunner feed back
As you mention, debian may not be the right project to try to focus on a subset of apps. I'll have to retry hackable:1 and try SHR before I start trying to mold a community of like-minded on top of debian ;) I don't think I have enough of an overview to not end up being counter productive. Give it a few months and I should be able to direct my comments to the right people, making it easier on everybody. Happy hacking! Bram On Fri, 2009-04-17 at 15:37 +0200, arne anka wrote: > > I may even start a thread about that in a > > few months. > > well, why not yet? you seem to have some rather clear ideas, given > your > remarks. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] on Freerunner feed back
A few mailings back I was told that Zhone is never going to be a proper dialer. Zhone is ment to be a debugging and feature testing application for the FSO framework. I don't think patching Zhone is going to be of any use. I don't know if there is anybody in the debian community who is going to stand up and say: these are the apps we should be working on and this is what the gui should look like. I may even start a thread about that in a few months. I think if you like Edj (the e gui stuff) then you should focus on getting Paroli ported to debian as that is going to be the default for Om2009. (Somebody may even already be working on this) Also, personally, I think screen locking is more important then auto rotating, but any help is welcome. Happy hacking! Bram On Fri, 2009-04-17 at 11:20 +0200, Thomas Bellembois wrote: > What I would like to do: > -find a usable configuration to use a PIM suite (synchronized with my > desktop PC) to replace my Palm TE2. > -configure the WIFI > -install Navit and buy reiseplaner maps > -make the autorotate work > -make Zhone fully usable > > I would like to know I somebody could have a fully functional > freerunner > under debian ? Thanks in advance for your answers. > ___ 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?
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?
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 : > > 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 : > >> > 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?
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 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?
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=contact&l=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?
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 : > > 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?
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
Why enlightenment?
I know this question must have come up once before, but I couldn't find any real answer online, so I'm posting it here. Why enlightenment? I haven't seen enlightenment being used for over 4 years, and with the wealth of programs out there which are portable and can run on top op Linux, this choice really astounds me. I'm only writing this now, because I see that the next Om release (2009) is going to keep focusing on using it. Most people will not find this discussion productive, but please consider giving me some good pointers as I'm having a hard time to get my head around this. As I see it, all embedded devices running some kind of interface use either QT or GTK (QT Phone, Nokia Internet tablet, Sharp Zaurus..) and there are various applications and standards available. Why then go for enlightenment? Hoping this is not to inflammatory, Bram ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
