Page MenuHomePhabricator

Support new interface for modifying part's description of Edje
Open, Incoming QueuePublic


  1. There is no official way to modifying part's description of Edje. But, sometimes, we need to change some of them.

For example, we can change line wrap or ellipsis mode by efl_part() and text interfaces.
But, all calculations of text are performed based on Edje's part description.
If an object wanted to show full text everytime, it might have "description.text.min: 1 0;" in text part to have minimum width for full text.
In this case, to see line break or ellipsis, we need to change text.min: 0 1; or text.min: 0 0;. (will not expand minimum width for full text but expand vertically or not)

  • ex) efl_canvas_layout_part_text_min_expandable_set/get efl_canvas_layout_part_text_max_expandable_set/get
  • The above new interfaces could be called from elementary or Applications when some text properties are changed.
id213sin created this task.Feb 9 2018, 1:52 AM

Regarding wrap,ellipsis, font, size, color etc. - this can be done for Edje. I'll add a task with some of the specifics.

As for text.min/max: I am wondering about the fixed description option.
How do you want to incorporate this in the API (how to name it, how does it work with text.min/max, and can we merge this logic in the same API?).

For text.min/max - I think this should be a hint in some proper namespace like Efl.Layout.Calc.
So, efl_layout_calc_part_text_min_set() for efl_part would be better (thus avoid duplicating API for user operations in for Elementary widgets).
For example: efl_layout_calc_part_text_min_set with the mask EFL_LAYOUT_CALC_PART_TEXT_MIN_NONE(0)/WIDTH(1)/HEIGHT(2).

We will have to add a new Efl.Layout.Calc_Part interface, implement in both Edje and Elmentary, and to use this via efl_part if we want to allow users to manipulate the widgets.

I think that's pretty much what needs to be done.
However, I would like to discuss here about the calculation process you intend for the TEXTBLOCK part.

you can change the text.min etc. via signals and have the theme do whatever it feels it right for the INTENDED result. the idea is to communicate at a high level, not a low one.

After a brief chat on IRC it seems that signal-based changes do not persist over reloads of the theme, and in general there is room to consider a property-based solution.
I think that a user-definition solution should suffice.

custom changing description from api also won't persist in theme changes... it's no different. the widget has to remember such state and re-apply on any theme change (file_set on the edje object).

Right. However, this solution does not exist at the moment, so we're going to have to introduce those properties and do the re-applying internally.
The user of the widget won't be able to do that without this extra functionality.

After further discussion, it seems inevitable to support overriding of part properties via API calls.
Indeed, internally we need to ensure the penalty is minimized, both in memory and speed, as explained in the following:

  • Memory: as we want to avoid memory bloat (by introducing more fields to the Edje_Real_Part struct). We rather use a dynamic data structure (e.g. hashmap).
  • Speed: querying a dynamic data structure will require optimizations, as edje's calculation code is a hotpath.

Regardless, this opens a possibility to further the usage of overriding edje parts' properties, so a proper API should be introduced.
As suggested from a discussion with @raster on irc, some decent MACROS and a few functions should abstract this usage, so the implementation can be improved to minimize the penalty here.

As for implementation details: for starters, I suggest to check an (UNLIKELY) flag, like EDJE_PART_OVERRIDDEN to restrict querying the data structure for overridden data (or: just query if the data structure is empty. either way).

@id213sin, I was wondering about the following use-case: if a style is defined in the .edc file: base: "font=Sans font_size=14 color=#000, and a call to:

efl_text_normal_color_set(efl_part(layout, "text), 100, 100, 100, 255);

How should it be handled? Should the color from the style get overridden?
When implementing the Efl.Text.* properties in Canvas.Text, I implemented based on the opposite, that is that set properties are the "default" properties, and the style has a higher priority.

Do you think I should prioritize properties that are set using efl_text_xxx calls?