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 <bne...@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 <bne...@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. > _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community