Different application size depends on the location of the window visibility setting in the code relative to resize_object
Open, Pending on user inputPublic



As said in the title, if the visible_set of the window is set before or after content_set (= resize_object_add), the application will seem different.

See https://pastebin.com/k85RwTU9. The last two lines order make the world different. If the win visibility line is removed (as it should be default), it behaves too.

I remember this behavior was existing in legacy as well


JackDanielZ added a project: efl.
jpeg added a subscriber: jpeg.Sep 17 2017, 9:27 PM

content_set and resize_object_add are very different (one is a swallow the other is a stacked box).
The behavior in legacy was similar indeed... and I absolutely hate it. Visibility and size are properties, not actions, IMHO order of operations shouldn't matter.
I wonder if we shouldn't just always postpone the visibility set in this case. show() should always be called after everything else, in legacy, as that's how the calculations will work best.

The problem is that the app seems ok if content is set AFTER visible, not before.

While I can't at the moment provide a solution for the general "order" issue, I believe that there is a specific issue with label.
I am basing my observation from test_label.c.

See the following snippet: P208. It is derived from test_label@test_label.c, (other boxed labels removed).

  • It is faulty. We see it on start.
  • This is the only test where we have the resize_object_add and show(win) in a reversed order.
  • Reversing the order to the "correct" one breaks everything, even in the original test.
  • Omitting this specific label (the one in P208) from the original test shows proper results (at least it looks like it does).

There's some odd size evaluation going on with elm_label.
This is why wrap_width_set was added as part of its API (although, it's not used here).

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:51 AM
bu5hm4n edited projects, added efl: display system, efl: widgets; removed Restricted Project.Jun 11 2018, 7:36 AM
zmike lowered the priority of this task from High to Pending on user input.Jun 20 2018, 8:59 AM
zmike added a subscriber: zmike.

I think this should actually be resolved now, as all sizing is deferred until the first pre-render. Can you check?

Well now, it seems that visibility doesn't impact on the size. However, the window size setting position impacts on it.

See code https://pastebin.com/cYc7CyJn

If you compile this code, it seems totally broken. If the line 31 is set after line 69, it is ok.

zmike added a comment.Jul 11 2018, 7:48 AM

I think this is basically expected behavior for legacy; sizing has always been flaky.

For the future we should probably add flags to the window internally for methods like this so that sizing_eval doesn't clobber them? This should be a new task for #goal I think...