On Mon, Oct 25, 2010 at 10:04 AM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > Wow, I'm amazed how receptive Raster was... will it rain today? :-) > > > On Mon, Oct 25, 2010 at 3:55 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: >> On Sat, 23 Oct 2010 21:05:20 -0200 Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> said: >> >>> 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. >> >> i'd say there is a borderline between check and toggle. check never changes >> its >> label - in fact it has just 1 label, 1 icon and an on and off state. toggle >> is >> toggling between 2 labelled states. with an added label to describe what ua >> re >> toggling and icon. so... i'd say check should stay - but toggle and >> magentslider are close enough to be merged into an N state slider. > > Although I dislike not having it in check, I agree moving toggle to > magnet would make sense. Actually handling N states would work for a > request I have for enjoy: easier rating widget. I was thinking about > doing it in slider with 0-5 values and discrete steps of 1, but magnet > would work for that case as well. > > >>> - menu + hoverlist = menu, with hoverlist-based implementation? >>> menus currently lack scroll, and we're about to move sub-menus to >>> their own widget anyway. >> >> hmm hoverlist and hoversel i think can just merge to hoversel. menu though i >> think is another thing entirely - desktop versions may want to implement >> menus >> as external windows for desktop mode. for embedded mode put them inline in >> the >> canvas. > > hoversel and hoverlist diverges just because one adds a button to > trigger the hoverlist. Much like fileselector -> fileselector_button. > > >>> - 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). >> >> that's be sensible. they really are selectors of 1 of N items. an item being >> icon+label? (icon itself reduces to "any other widget anyway"). > > I guess item_class would fit here. It would just provide label_get(), > icon_get() and del(). We could use them to present coverflow like with > the central widget showing artist, album, ... > > >>> QUESTION: how to handle interactions? just catch some gestures and >>> report them as signals, like "elm,action,swipe,left"? >> >> u dont just have swipe.. you have "how far u swiped" and "did you stop half >> way >> then swipe back - how far?". here you really just have to handle the drags >> themselves and do the right thing. > > yeah, we could have these as signals. but always provide them? Or just > load a gesture detection based on some data.item: "gestures" "swipe > tap". each of them would send signals or messages as appropriated > (swipe sends dx,dy as message; tap sends "elm,gesture,tap,2" for > double tap). > > >>> - 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. >> >> i'm really not a fan of the spinner right now. > > nobody is. but how to make something as nice as slider that is > editable? Maybe after a timeout at the same position, and if editable, > it will slide in an entry where values can be edited? > > >>> 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) >> >> keep hoversel as it is i'd say. thats what demos are for. people will find >> the >> thing they want and "see it" and go "i want that" and learn the name fast. >> changing name here just creates pain for existing code. > > well, why not have that popup feature for hoversel as well? In a world > properly composited it would make sense. Until then we can leave the > setting to operate inside a single window. Effectively they have the > same purpose: show options for a context. Just menu provides > sub-options (sub menus). > >
Hoversel is not tied to a button, it can be a popup menu just as well, and it actually is currently. The longpress menu in entry is using hoversel. >>> - 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). >> >> ok. suggestion for frame, bubble and layout. provide #define macros to >> provide >> compat api's then using layout. deal? (we can put in warnings in them to say >> they will be dropped and please use the layout api instead) > > Sure. We can do such compatibility for now, I don't really want to > break everything immediately, but encouraging people to use labeling > 1.0 is shoot in the foot. > > >>> - 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) >> >> well then - what do you do about making useful pre-made "works" widgets. >> saving >> code. saving hooking together a whole bunch of callbacks and filling things >> in >> etc.? ok - maybe it shouldnt be a widget. maybe it should be part of a util >> api that hooks up savers for you- that loads and fills for you? > > if you check the widget and how one would do it, what's the most > difficult part? file handling! Not widget. The signal connection is > super simple. But reading file, managing stdio errors and all is a > PITA. maybe offer utilities in eina/ecore like file_read_full() > file_write_full()? If we're worried about blocking, it's ecore > otherwise it's eina. We have that in Systemd and I find it very > helpful (as well as file_read_one_line(), to manage things that are > known to be one liners, like /sys values). > > >>> - 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. >> >> it's still much simpler than genlist. unless you want to remove the need for >> item classes and make genlist simpler in that regard... also genlist defers >> filling- list never does. you'd need genlist to do the above. > > what's the problem with deferred? people that rely on object with list > are mostly in trouble (as we've noticed the hard way inside ProFUSION > by abusing base_get() -- changes to the list may reset the items!) > > see what I've wrote to glima in another mail. we can provide helpers > for common cases like text, or text + icon. > > and in the long run, this will save people from mistakes. It already > happened that for "easiness, go elm_list as it is simpler and should > do" and then we see it was not enough and then we go back having to > convert everything to genlist to do it... definitely bad. > > as said, we can just label it as deprecated and remove at 1.1, 1.2... > whatever future version. > > >>> 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. >> >> no. it needs to stay as it ALSO has to specially handle sizing for wrapping >> of >> text etc. the only reason wrapping vaguely works at ALL is entry/label work >> to >> MAKE it work. as such edje won't be getting that feature before an elm 1.0... >> so label stays. >> >>> - 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 see a world of hurt happening if you remove them. in fact it will... so >> don't. this is a no. > > i knew it. But at least mark them as deprecated? Suggesting layouts > instead? We can provide canned layouts as I said. > > BTW, elm_box/elm_table are already a wrapper around > evas_box/evas_table. Just that due some brokeness we've introduced in > elm_box/table WRT size hints, we had to keep the original algorithm as > well, otherwise it would break people apps. If we deprecate the > functions, people will then fix their apps to provide correct hints > and the custom algos can die. > > > -- > 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
