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 ------------------------------------------------------------------------------ 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
