On Mon, 25 Jun 2012 12:27:26 +0000 (GMT) Sumanth Krishna Mannam <sumant...@samsung.com> said:
review... incoming! 1.- design notes. this ALWAYS creates the popup_base even if the swallow for popup doesnt exist. since this is new we need to detect this by checking for the part - its a new feature and old themes wont support it. 2.- you always create the popup object regardless if theme supports this or not 3.- your hide/show logic of the popup object is not good. you should emit signals from the base to "show popup" THEN popup is shown, another signal to hide the popup. also perhaps some kind of signal/message passing to the popup of its current drag position etc. and some proxying of signals/messages from bae to popup so bsase can do things like fade the popup in and out or change its color as its dragged around. 4. you dont listen to move+resize callbacks on popup_base rect. this is what you should use to figure out current popup position and size. 5. with popup show/hide u want to actually have some negotiation on hide. ie emit signal to say "begin hiding now" and popup signals back when done - but only when responding to show/hide signals form the popup main edje. when slider object ITSELF is shown/hidden u forcibly show/hide popup. code things: early on u replace a fixed buffer with an alloca -> i dont get it. its a fixed size alloca. why? this one: - char buf[1024]; + buf = alloca(128); + snprintf(buf, 128, sd->indicator, sd->val); you also move it higher up in scope for no good reason. :) i'd fix that anyway. so patch as it stands can't go in because it "breaks" backwards compatibility. it also has too many things that need improving. :( now the question is.. do i just quickly do this now, or does this wait for the next release cycle? > Hi, > > I made a patch with an edje object displaying text during the Slider drag > state. (The module design is been dropped, instead, we integrated it with the > default widget code. Refer to: > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg41850.html) > > The position and geometry can be controlled by a swallowed rectangle as the > indicator popup is placed exactly over its location. > The popup (edje) object can be moved as per the invisible swallowed part so > the popup display is totally controlled by theme/style (can adjust the offset > or the size of indicator popup). > > The indicator stacking issue can be resolved in slider widget and the default > theme look & feel remains unchanged with this patch. > > Can someone please review the code and merge it with upstream repository. > > > Thanks & Regards, > Sumanth > > > > Date: Tue, 29 May 2012 08:52:27 +0900 > > From: Carsten Haitzler (The Rasterman) <ras...@rasterman.com> > > Subject: Re: [E-devel] [Patch] Elementary : Elm_slider widget > > enhancements ? modular design to display indicator text at the top of > > slider. > > To: Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > > Cc: "csm...@samsung.com" <csm...@samsung.com>, TheRasterman > > <"CarstenHaitzler<raster"@rasterman.com>, Enlightenment developer list > > <enlightenment-devel@lists.sourceforge.net>, > > "GustavoSverzutBarbieri<barbieri"@profusion.mobi > > Message-ID: <20120529085227.569f569fb880f2c59a4c4...@rasterman.com> > > Content-Type: text/plain; charset=UTF-8 > > > > On Mon, 28 May 2012 11:54:25 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > >> Hi Somanth, > >> > >> On Mon, May 28, 2012 at 7:07 AM, Sumanth Krishna Mannam > >> <sumant...@samsung.com> wrote: > >> > Hi, > >> > > >> > We designed the module based approach for mainly the following reasons: > >> > > >> > 1. ? Default indicator is displayed at the top of touch area. > >> > ? ? ?What if we want to show the popup at the left side/ right side/ > >> > bottom of the touch point? > >> > ? ? ?- ?A dedicated dynamic module can handle the indicator orientation > >> > in the module code itself. > >> > >> These can be easily defined by the theme by using Edje object data. > >> E17 makes uses of those to let the border say if the window is > >> transparent or not, etc. But try to use object geometry as well, maybe > >> defining that the object will be displayed exactly centered with the > >> parent will do? > > > > indeed. all of this can be done with an edje object, some geometry tracking > > of a sepcific part in the base slider object (swallow invisible rectangle, > > track position/size of this rect, place indicator object at geometry of > > this rect, but on a higher layer, use signals to tell it it has been > > dragged, or needs repositioning to some side (left, right, top, bottom). > > > >> > 2. There may be some cases where we need to display indicator popup in a > >> > separate window. It is left up to the module to decide how & where to > >> > display. > >> > >> Same, define as a theme Edje object data. If so, create the window and > >> show it as overlay. Just take care to handle the non-windowed systems, > >> doing a nice fallback (ie: framebuffer). > > > > i'd advise avoiding this like the plague (creating of a window). basically > > because it breaks with fb and with wayland it's not possible in the same way > > due to no absolute window positioning (we don't have any relative > > positioning api's atm for that). it's solvable inline. if the "popup > > object" overlaying the slider on some higher layer is gong to be obscured > > (bvy boundary of window OR by something like an overlayed vkbd or indicator > > maybe outside of the window), then switch direction. ie dont show "above", > > but show "below". so u need to support 2 modes, and if the default > > intersects a hinding boundary, choose the other. this will only fail if the > > screen is set up as such that both sides of the slider are obscured - this > > scenario would be one where the slider is the size of the whole window (or > > screen)... kind of a real corner case. :) > > > >> > So considering the above extendibility options, we proposed the Slider > >> > indicator modular approach. More over it will not change current > >> > indicator style. > >> > > >> > If you feel that there is no need for these enhancements, we can very > >> > well bring the feature in the widget code itself. I can make a patch > >> > with the default indicator, always showing on the top of touch area. > >> > >> IMO they are not mandatory now. The positioning can be easily solved > >> by overlay/indicator geometry. Remember that in Edje/Evas objects can > >> overflow as they wish and they will be visible. anyway. The window > >> one can be done later, if needed. > > > > yes. if ever needed elm can do this itself, but i don't think we need it, > > and it just is going to create problems imho. > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------ -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
