[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Edje min size calculation bug
From:       Cedric BAIL <cedric.bail () free ! fr>
Date:       2013-07-23 0:00:29
Message-ID: CAGv1asUy-Os+JdDxTaAnWHhTCfLY7LkSqgN4GmrwBqfJ0LpWCw () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 23, 2013 at 12:53 AM, Gustavo Sverzut Barbieri
<barbieri@profusion.mobi> wrote:
> On Mon, Jul 22, 2013 at 5:12 AM, Cedric BAIL <cedric.bail@free.fr> wrote:
>> Hello,
>>
>> On Fri, Jul 19, 2013 at 10:51 PM, Gustavo Lima Chaves
>> <glima@profusion.mobi> wrote:
>> > Hi, Edje people (Cedric, Raster, mainly).
>> >
>> > When centering two or more parts on a broader layout, with no use of
>> > offsets (think scalable interfaces), it's of great use to have these
>> > sub-parts bundled in a subgroup, which can easily be
>> > centered. However, Edje has a bug when calculating the minimum size of
>> > a (sub) group of this kind:
>> >
>> > collections {
>> >    group {
>> >       name: "group";
>> >
>> >       parts {
>> >          part {
>> >             name: "bg";
>> >             type: RECT;
>> >             mouse_events: 0;
>> >             description {
>> >                state: "default" 0.0;
>> >                color: 0 255 0 100;
>> >             }
>> >          }
>> >
>> >          part {
>> >             name: "padding";
>> >             type: RECT;
>> >             mouse_events: 0;
>> >             description {
>> >                state: "default" 0.0;
>> >                min: 50 0;
>> >                max: 50 -1;
>> >                align: 0 0.5;
>> >                rel1 {
>> >                   relative: 0 0;
>> >                }
>> >                rel2 {
>> >                   relative: 0 1;
>> >                }
>> >             }
>> >          }
>> >
>> >          part {
>> >             name: "elm.text";
>> >             type: TEXT;
>> >             mouse_events: 0;
>> >             description {
>> >                state: "default" 0.0;
>> >                align: 0 0.5;
>> >                rel1 {
>> >                   to_x: "padding";
>> >                   relative: 1 0;
>> >                }
>> >                rel2 {
>> >                   to_x: "padding";
>> >                   relative: 1 1;
>> >                }
>> >                text {
>> >                   min: 1 0;
>> >                   text: "blablabla";
>> >                   font: "Sans";
>> >                   size: "30";
>> >                }
>> >             }
>> >          }
>> >       }
>> >    }
>> > }
>> >
>> > Naturally, the parent group of that one would look like
>> >
>> > part {
>> >    name: "broader_group";
>> >    type: GROUP;
>> >    mouse_events: 0;
>> >    source: "subgroup";
>> >    scale: 1;
>> >    description {
>> >       state: "default" 0.0;
>> >       min: SOURCE;
>> >       rel1.relative: 0.5 0;
>> >       rel2.relative: 0.5 1;
>> >    }
>> > }
>> >
>> > thus, enforcing its minimum size calculation via min: SOURCE.
>> >
>> > Edje, however, miscalculates the horizontal size of "group". Try
>> > running 'edje_player -g=group FILE_WITH_GROUP_COMPILED.edj' on the 1st
>> > (inner group). Then, start resizing edje_player's window horizontally,
>> > make it smaller. You'll see that it goes past 50 pixels from the
>> > string's ending, exactly the size of the white rectangle in X! Edje
>> > simply overlaps those minimum sizes together (rectangle's explicit
>> > 50px min + text's implicit min: *1* 0), instead of adding them, to
>> > generate a minimum size to the group!
>> >
>> > Can anyone help here?
>>
>> I think the problem is somewhere else. The size of the text object is
>> only calculated by _edje_part_recalc_single_min . This means that
>> edje_size_min_restricted_calc only see an object of size 0 that want
>> to be bigger but never can, because we define the requested size
>> before calling min (that even if we have the space for that part).
>> This is why edje complain about a missing 'fix'.
>
>
> This last part makes no sense to me. Elaborate?

The size of the elm.text part is only due to "min: 1 0". That affect
the final size, but not the requested size. So during a restricted min
calc, that part keep requesting a different size than its final size.
This lead the restricted min calc to finally discard that part and
believe it require it to be fixed (when it really does not).
--
Cedric BAIL

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]