Why enlightenment?

[Bram Neijt]

On Sun, 2009-04-19 at 11:52 +1000, Carsten Haitzler wrote:
> On Sat, 18 Apr 2009 12:13:08 +0200 Bram Neijt <bneijt at gmail.com> said:
> 
> > This looks like a great list! I'll go through the points one by one...
> > 
> > On Sat, 2009-04-18 at 01:03 +0200, Leonti Bielski wrote:
> > > Enlightenment is the best choice for Freerunner!
> > > 
> > > 1. Theming - it keeps resources low and alows us to do everything we
> > > want with GUI! Take shelf widgets as an example - you can change their
> > > look, even functions - like digital clock instead of analog - without
> > > changin the main code. I don't say it's not possible with GTK but it
> > > way more complicated.
> > I'll have to look into how complicated this would be with GTK, but I'll
> > take your word for it. However, if you change the clock from digital to
> > analog, then you will get layout problems. I thought switching
> > glade(/gtkbuilder) files would be perfect for something like that and
> > with the glade interface developer, making new layouts would be easy for
> > everybody.
> > 
> > I'll take your word for it that is really is easier.
> 
> trust me - e is by far more flexible than gtk in changing look,layout and feel
> just by changing a theme data file. i wrote gtk's theme system. i also wrote
> e... :)
Yes, I trust you on that. But I don't think theming is always a good
thing. That is, however, just a matter of opinion.


> > > 2. Finger scrolling - it works by default. If I know that app is
> > > written in Elementary - I know that it's finger-friendly. Also -
> > > compare matchbox keyboard and illume one - latter is far more
> > > finger-friendly.
> > I really thought finger scrolling would be a task that should be
> > implemented by the touchscreen driver/library software, or if needed the
> > window manager, but not the GUI toolkit. What about right-clicking
> > support? If you put right-clicking support, scrolling, and other
> > "emulate a normal mouse" behavior in the GUI toolkit, I think you are
> > putting it in the wrong place.
> 
> 1. absolutely not. scrolling is an app+toolkit thing. scrolling needs to track
> the mouse position. i can go into all the logic an math why - as it also
> conflicts with normal use (like dragging a slider, pressing buttons in a
> scrollable region etc.). the toolkit/app needs to figure out "did they want to
> slide the slider, or scroll the view?" for example. trust me that its a
> toolkit/app problem.
The only example I can state here is something I first say implemented
by a logitech driver on windows. To scroll you pressed a special button
on your mouse anywhere on the screen and then moved the pointer away to
start scrolling. The further away from your initial point, the faster
you scolled. This worked with all toolkits (including Java SWT, GTK+,
Firefox's toolkit). So I can't get myself to trust you on that.

> 
> 2. right mouse also can be hackishly implemented in the windowing system - but
> thats wrong, as it has no idea what parts of the screen need a long press for
> emulating a right mouse. (thats the normal way to do it). this SHOULD be left to
> the toolkit. only the toolkit knows what parts of the screen are sensitive to
> a right-mouse press or not. and if it does this... it may as well handle it as
> along press anyway (as opposed to emulating right-mouse)
I thought I could could use my mouse and use the right button on any
part of the screen I wanted, without having a toolkit tell me whether I
am allowed or not? Even if I have to emulate it some how, if I want to
right click on something, the only thing I think the toolkit is allowed
to do is sit there and take it ;)

> > If you think about it like that, then finger friendly means: large
> > buttons, nothing where you have to hit the side, and feedback you can
> > see even with your finger on it.
> 
> correct. also that it doesnt need a right mouse button, that it doesnt rely on
> "mouseovers" for input/indication (or position of mouse eg - move mouse to edge
> of window to begin an auto-scroll in that direction). or that some bits of the
> ui appear when the  mosue is over areas. as the mouse only moves while mouse
> button 1 is pressed down - you need to work with that.
> 
> you also need other bits of smart eg - finger-scrolling. to determine if a
> swipe is a scroll or not, handle momentum of the scroll etc.
I still can not see why you need to work with that in the toolkit. Why
not go a level higher and try to solve those problems in a toolkit
agnostic manner?

> > But if the OpenMoko team thinks that the GUI toolkit is the place to fix
> > scrolling, then I can see why it is a good choice.
> 
> thats what elementary covers - it's
> 
Good list of features, and I would like to use it to congratulate all
developers on the elementary toolkit on their achievements. Don't get me
wrong, I'm not saying that enlightenment is bad code or crappy work. I
started this thread because I couldn't understand the reason why it was
chosen.

> 
> > > 3. Up-to-date. It's under constant development, and getting better by
> > > the day. It's also (Illume and elementary) 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?
That seems to me like a "fallacy of many questions". If it is important,
please consider rewriting that last question.

Greets,
  Bram