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. 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. On Sat, Oct 23, 2010 at 9:05 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > Given the discussion started by Dave in the other thread, I'd like to > check the overall opinion on the following: > > UNIFICATION > - check + toggle = toggle. just different styles. Default style is > the best for each environment, but one can still force toggle or > check. > - panel + panes = panel. make a hide action, and enable/disable > this action. make resizeable behavior configurable. > - image + photo = image. refactor fill property to make it work > with inside/outside (bool -> enum) > - menu + hoverlist = menu, with hoverlist-based implementation? > menus currently lack scroll, and we're about to move sub-menus to > their own widget anyway. > - diskpicker + flippicker + carousel = carousel (name) with > implementation that manages choosing items from a collection. In an > ideal world the theme would say how many pre/post elements it handles > and the item would have to implement an Elm_Carousel_Item_Class with > label_get, icon_get and del. This would enable, based on the widget > style, presentation of icon, label and in any number (think of a music > coverflow that the central element shows the artist and album names). > QUESTION: how to handle interactions? just catch some gestures and > report them as signals, like "elm,action,swipe,left"? > - spinner + slider = range(?). basically they allow selecting a > number from a range, but one allows editing while the other does not. > spinner is particularly bad WRT usage atm. > > > CHANGES > - rename colorpicker to colorselector (matches fileselector) > - hoversel to combobox or selection_box? (not really sure if > needed, but people know it with that name) > > > DROP > - elm_check (see unification) > - elm_frame (useless, same as elm_layout) > - elm_bubble (useless, same as elm_layout. provides useful > automatic send of signals, but it is very specific purpose and these > signals could be made automatic inside elm_layout, helping generally > when parts need to behave differently whenever swallows were done). > - elm_notepad (quite useless as it does not export much of > editing, just links changed signal to save the file. I'm more more > inclined to drop it and in future releases just something else with > toolbar to control styles, like bold, italic, font faces and so on... > without actually saving the file, that's the simplest part of it, the > style management is the hard part) > - elm_separator. yet another layout thing being moved to application. > - elm_list. it had a reason as we did not had elm_genlist. However > we could have some helpers for genlist, like some canned item classes. > > I know I'll be bashed again by Raster, but I'd like to request > consideration to drop the following as well: > - elm_label. It's just a stupid legacy we carry from elsewhere > and have no good purpose in EFL. The only use of it right now is to > workaround the lack of ellipsis in Edje's TEXTBLOCK, we could just > move this work around inside Edje until someone does the proper fix, > that way we also get ride of complaints why Edje's part do not work. > - elm_table and elm_box. Also a stupid legacy we carry from > elsewhere. Having them, and particularly using them ourselves do no > good other then redirecting people from the correct way to do layouts: > elm_layout. We can just have canned layouts for vertical and > horizontal boxes, avoiding applications to set things like padding for > themselves, doing so is bad as we all know... they would just do > another layout and use it, with paddings being in theme and not > application. > > > I know there are some "hard" changes here, like touching elm_list and > elm_check... but as we did not label it 1.0, we could avoid getting > them on 1.0... or if we do, do with EINA_DEPRECATED marks and remove > them at 1.1 > > -- > 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 > ------------------------------------------------------------------------------ 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
