On Sun, Oct 24, 2010 at 3:35 AM, Iván Briano (Sachiel) <sachi...@gmail.com> wrote: > I'll use the classic "I'm drunk" excuse to top-post. If you don't like > it, I have a bunch of "go fuck yourself" responses for you to choose. > > From my point of view, the EFL as it stands now has two conflicting > philosophies: That of Evas+Edje and that of Elementary. > > Evas and Edje make for custom interfaces in any way the developer wants, > forgetting years and years of toolkits forcing their way into the layout of an > application. > Elementary, on the other hand, uses that power to change the look of an > application that still follows the teachings of old, but still leaving > all of the > responsibility of how the layout will be to the programmer. > > These are two fundamentally different ideas that have to be taken into account > every time we pretend to decide which is the course to follow. It is > not possible > to follow the generic way of Evas+Edje with Elementary if we want the toolkit > to > be an easy way for programmers to build applications, nor can we > pretend Elementary > to be easy to use if the intention is for it to be so generic that > every user can > have his own idea of how things should look by just playing with the > theme without > having to mess with a single line of code. > > That's my biggest conflict with it and probably the reason why things > like hoversel and > hoverlist, toggle and magnetslider, flippicker and diskpicker, among > others exist. It's > the difference between having a base of code that lets you do > something and having > the theme decide how that option will be presented to the user, and > having a bunch of > pre-made widgets that any developer can plug anywhere so the user > always sees things > in the same way but with more or less rounded corners. > > So, before getting into a big debate on what should be there and what > should not, I believe > it's important to state where each of us stands, because we risk a lot > of time getting lost > discussing things that are not just an opinion on how to do something > specific, but how to > express the idea of how that specific should be done. Lots of time has > been wasted on this > already if you go through mailing-list archives and IRC logs, and I > don't think it's worth it.
well, given the ideas proposed in my mail and other discussion, the point is not to let everything "rough", just to avoid duplicating code that is inherently similar. For instance, these diskpicker/flippicker, although have different visualization, have the same concepts: you want to show a collection of stuff where a single one is chosen. you know I'm one that always suggest to not over engineer stuff and get things done, they were done, and now we can look back and see how similar they are. Now it's time to evaluate it and see if optimizations are possible (not performance optimizations, rather generic improvements). > Personally, I believe there's nothing wrong with having two toolkits > available, as long as it > doesn't end in the EWL vs. ETK that we've been through already. One of > them would be the > easy to use, quick builder of simple applications that anyone new to > "the new way" of building > things can use, and another one that is a thin layer on top of Evas > and Edje to provide some > helpers, common cases and just-glue for those that don't want the > common widgets and prefer > to have everything done their way, while still getting the benefits > pre-made toolkits provide, like > config (fingersize, scale, thumbscroll) or focus mechanism. All of > this can be arguably done in > one toolkit, but we have either started with the wrong foot or proved > that that's not the case. > All in all, after so many years of development and people outside > obviously not grasping so > easily the Evas+Edje way, I guess that thing of having two toolkits > it's not something we want > to start a release with, but we can't pretend to have something that > goes both ways when > even those that are already part of the community don't still grasp the > concept. > And before that last phrase starts a flamewar, go into Elementary's > code and look through > its history how different widgets were written. I'm pretty sure you'll > find my point proven > that way. yeah, I almost agree fully, but I still don't think these concepts are conflicting as you stated in the first part of your text. Elementary was always written under pressure, first from swiss telecom, then samsung. While this made it grow fast and mostly work although being done in record time, we have few edges left to cut. At some point we'll have to look back, analyse what was done and refactor some bits. Okay, going mad about possibilities will bring us no good, but we already have couple of real use cases that we can fit with minimum efforts. Also, worths a note about competitors: Nokia, just like Samsung, loves to have these specific purpose widgets and as soon as they got Qt they started to develop multiple libraries to provide these. Even with the help of C++ language sugar to make it simpler, they ended with a stupidly big widget set on top of QGraphicsView (our Evas), from simple things like a text list to complex things like "editable contacts list" that would even query the contacts db for you. The final code was huge, like couple of times bigger than Qt itself. And it was supposed to make life easy, once most stuff were ready already it was just plumbing the signals. Guess what? It did not work, and they tried it couple of times (different implementations). Now take something completely different. Flash or HTML. God, what do they provide? Almost NOTHING. They just don't impose stupid limits that you have to work around. On top of it people create some specific purpose libraries (let's call them extensions), and way more applications are created using it than anything else. Okay, you do have tools like DreamWeaver and like to help, but you get the point. I'd say we're currently closer to Flash/HTML, after all we don't have the thousand widget libraries yet. But should we create these thousand widget libraries? I'd say no. At the other hand, we don't want to spend hours managing low-level Evas_Object ourselves, like listening to size hints changes to recalculate the scene, or listening to theme and finger size stuff. The widgets do make sense, but it would be nice with a simple 1-line change we could change a flippicker to diskpicker, right? The rest of the code still adds items, get the selected one... If we want something else, then we can provide just that "something else", not creating all the machinery inherently for these stuff, like managing children (hints, del, ...) Anyway, my first mail was long, your was long and this third is way long.... I'd like people to reply to my first mail with +1 (like) +0 (no strong opinion, but favorable), -0 (no strong opinion, but against) or -1 (dislike). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
