* Gustavo Sverzut Barbieri <barbi...@profusion.mobi> [2010-10-23 21:05:20 -0200]:
> 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. Mmm, -0 here. Does not hurt nor bloat to have them. > - panel + panes = panel. make a hide action, and enable/disable > this action. make resizeable behavior configurable. +0 Yeah, seems to make sense. > - image + photo = image. refactor fill property to make it work > with inside/outside (bool -> enum) +1. > - menu + hoverlist = menu, with hoverlist-based implementation? > menus currently lack scroll, and we're about to move sub-menus to > their own widget anyway. +0. > - 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"? +0. Kinda tough this specific move, but has sense in it. > - 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. > -0 Mmmm, yeah. Maybe glue diskpicker and spinner, then? Diskpicker really needs love WRT to its view, it offends the users :) > > 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) +1. > > > DROP > - elm_check (see unification) > - elm_frame (useless, same as elm_layout) +0 Maybe to drop it at the pre-made layouts in the theme, then. > - 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). +0 same as layout. > - 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) +1. > - elm_separator. yet another layout thing being moved to application. +0 same as layout. > - 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. > -0. Why to drop it totally? It's simpler than genlist, does its job at the places one does not need the generic one... Also, we have elc stuff relying on it. > 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. +0. Maybe for some of the stuff being moved to edc layout things, have macros building the layout for us, with the same name as a <widget>_add()? > - 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. > +1 I personally hate this duplication. Big time. > > 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 -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems ------------------------------------------------------------------------------ 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
