Why enlightenment?

[Carsten Haitzler (The Rasterman)]

On Tue, 21 Apr 2009 13:00:33 +0200 Bram Neijt <bneijt at 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 <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.

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 clicked on a slider and dragged it or not. windowing system has no
clue. it's dumb).

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

the toolkit IS a higher level. windowing system and window manager are LOWER
level. toolkit is as high as you get before being in the app itself. as its the
highest level until the app it knows the most about context and meaning of
things in a window - what they do, when, how and where. what their intended use
is. windowing system, window manager etc. have no visibility on this. they are
workhorses doing grunt-work. wm does some grunt and otherwise is in a separated
domain devoid of knowing whats up inside an app's window.

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

see other mail :)

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

not really - but things improving is good. if things just stagnate and dont
change you are stuck where you are. bugs, lack of features, tools, uses, etc.
will plague you and you continually work around them or just give up and dont
do them. it's never a bad thing for thnigs to get better quickly. if they are
constantly unstable - that is bad. but reduced instability and more features..
is good. especially if it comes rapidly.

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