Hello,
On Fri, Jul 19, 2013 at 10:51 PM, Gustavo Lima Chaves
<gl...@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'.
I am wondering why we don't set the proper size for the text object
and only affect the min size for it. I guess there is a reason. Raster
? Tom ?
--
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
