Re: [E-devel] [Patch] Elementary : Elm_slider widget enhancements – modular design to display indicator text at the top of slider.

[Sumanth K. M. <sum...@sa...>]

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/enl...@li.../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) <ra...@ra...>
> 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 <bar...@pr...>
> Cc: "cs...@sa..." <cs...@sa...>, TheRasterman
> <"CarstenHaitzler<raster"@rasterman.com>, Enlightenment developer list
> <enl...@li...>,
> "GustavoSverzutBarbieri<barbieri"@profusion.mobi
> Message-ID: <201...@ra...>
> Content-Type: text/plain; charset=UTF-8
> 
> On Mon, 28 May 2012 11:54:25 -0300 Gustavo Sverzut Barbieri
> <bar...@pr...> said:
> 
>> Hi Somanth,
>> 
>> On Mon, May 28, 2012 at 7:07 AM, Sumanth Krishna Mannam
>> <sum...@sa...> 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)    ra...@ra...
> 
>
> ------------------------------