Why enlightenment?

[Bram Neijt]

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