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



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).