Why enlightenment?

[Carsten Haitzler (The Rasterman)]

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... :)

> > 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
> insight into why that choice has been made and why it seems so
> ridiculous to me. 
> 
> Bram
> 
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com