On Tue, Jul 23, 2013 at 12:53 AM, Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> wrote:
> On Mon, Jul 22, 2013 at 5:12 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
>> 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'.
>
>
> 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
