Page MenuHomePhabricator

Supporting text interface to control text properties and size calculation rule.
Open, Pending on user inputPublic

Description

From elm_entry to our new efl_ui_text, it changes its Edje group when ever its properties are changed.
As you can see, there are group names in "_efl_ui_text_theme_group_get()" which are used for changing Edje group.
To customize theme for elm_entry or efl_ui_text, we need to customize whole groups.
(ex. elm/entry/base-single/default, elm/entry/base-charwrap/default, elm/entry/base/default and etc)

  • It is hard to understand/find out every group names which are used in elm_entry or efl_ui_text.
  • It is a waste of memory for loading additional Edje's groups.
  • It is bad for performance same as _style_set() function.

So, I want to suggest the following things to improve simplicity of customization and better performance.

  1. Use only one Edje's group for default elm_entry or efl_ui_text. (ex. elm/entry/base/default)
  2. Allows to change elm.text part's properties.
    • line wrap
    • ellipsis
    • size calculation rule (ex. description.text.min, description.text.max) for satisfying the above two things.
  1. Allows to control size calculation rule by developer explicitly. Currently, the following things are only controllable by modifying/customizing its theme. It's an annoying work.
    • Horizontally/Vertically expandable.
    • Horizontally/Vertically not expandable with ellipsis or scroll.
    • Horizontally/Vertically expandable till reach to the given max limits.
  1. Allows the interface for satisfying above requirements to other widgets which have text parts.
id213sin created this task.Nov 1 2017, 3:55 AM
id213sin updated the task description. (Show Details)Nov 1 2017, 4:02 AM
id213sin added subscribers: woohyun, eunue, raster and 2 others.

@herdsman ping :) Could you update your idea on this task ?

I am in favor of limiting Edje regarding text theming.
In fact, I remember that at some point we considered removing most of Edje's functionality (text included) and move the calculations to the widgets.
That was the main motivation behind the Efl.Ui.Text widget, that actually skips the text size calculation logic of Edje. It is accomplished by querying its current state (line-wrap, scrollable, multiline).

  1. Allows to change elm.text part's properties.
    • line wrap
    • ellipsis

How should this be prioritized over the style set by the theme?
If a developer has a text widget with a theme:

text { 
    style: "style_with_ellpsis_and_nowrap"; //" ellipsis=1.0 wrap=none"
}

Efl.Text properties are implemented in Canvas.Text to have lower priority over set styles.
That is, a call such as efl_text_wrap_set(efl_part(obj, "ui_text"), WORD_WRAP);, if simply forwarded to efl_text_wrap_set(text_real_obj, WORD_WRAP); will not change the word wrap, as the style has set NONE for linewrap.
Canvas.Text is meant to work this way so that styles can be overlaid.

Possible solutions for this:

  1. Move styles out of Canvas.Text API and handle them in Edje via usage of properties (map wrap=none to efl_text_wrap_set(obj, WRAP_NONE). This will allow us to override the set properties of the default style.
  2. OR we populate a "user-style" for the text part on efl_text_wrap and efl_text_ellipsis calls, and apply it on the text real part object.

Note that option (2) implies we may need to have a user style for each real object (though, we could share those user style strings with additional handling).

  • size calculation rule (ex. description.text.min, description.text.max) for satisfying the above two things.

This is not part of Efl.Text. What API should we introduce here? Efl.Canvas.Layout.Part_Text.text_min/max_hint?

  1. Allows to control size calculation rule by developer explicitly. Currently, the following things are only controllable by modifying/customizing its theme. It's an annoying work.
    • Horizontally/Vertically expandable.
    • Horizontally/Vertically not expandable with ellipsis or scroll.
    • Horizontally/Vertically expandable till reach to the given max limits.

Is this not the same as the description.text.min/max? If so, so yes let's where this API should be introduced (namespace).

  1. Allows the interface for satisfying above requirements to other widgets which have text parts.

I am especially concerned about adding user calls to set description.text.min/max. Edje is designed (unless I am mistaken and you are welcome to correct me) to work from the theme for most (if not all) of the calculation logic. This feels like bad practice for users.
Not sure if this is the correct approach.
@raster, @jpeg, @cedric?

ProhtMeyhet triaged this task as Pending on user input priority.Sep 22 2018, 10:38 AM
ProhtMeyhet added a project: efl.
ProhtMeyhet added a subscriber: ProhtMeyhet.

anything happend here? might add goal tag?