Page MenuHomePhabricator

Refactor Text subclass
Open, TODOPublic


Move efl.text.markup.cursor_markup_insert to efl.text.cursor.

Merge, efl.text.format, efl.text.annotate in efl.text.markup.

Make efl.text.markup a mixin (So that an object doesn't need to implement markup parsing itself and that later on we can provide other markup parser).

Remove range in favor of a simpler API to insert node.

cedric created this task.Dec 3 2017, 6:17 PM
cedric updated the task description. (Show Details)Dec 3 2017, 6:25 PM
cedric updated the task description. (Show Details)Dec 3 2017, 6:39 PM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:53 AM
bu5hm4n edited projects, added efl: layout engine; removed Restricted Project.Jun 11 2018, 9:27 AM

A #Goal ticket should not be set to a milestone.

zmike edited projects, added efl: api, efl (efl-1.22); removed Restricted Project.

Regarding "Make efl.text.markup a mixin", I've been doing some research:
Efl.Ui.Frame, Efl.Ui.Progressbar, Efl.Ui.Grid_Default_Item, Elm.Slider and Efl.Ui.List_Default_Item all implement the Efl.Text_Markup interface.
They all implement the markup property through the ELM_PART_MARKUP_DEFAULT_IMPLEMENT macro:

efl_text_markup_set(efl_part(obj, efl_ui_widget_default_text_part_get(obj)), markup);

And here I am confused because I cannot find the implementation for efl_text_markup_set(), or why an interface has an implementation at all :(

Looks to me like that macro should be replaced by a method at the Efl.Ui.Widget level.

zmike added a comment.Jan 23 2019, 9:50 AM

You're proposing that Efl.Ui,Widget implement markup and that the other classes you cited use the widget methods?

That would make it explicit what is already there in the implementation, since those classes are actually delegating to Efl.Ui.Widget their markup handling, through macros.

zmike added a comment.Jan 23 2019, 9:57 AM

Okay, firing up the code cannons

Initial thoughts: P266

This causes some pretty significant issues:

  • triggers method name conflict (cursor_new)
    • eolian: efl_ui_text.eo:317:7: function 'cursor_new' conflicts with another symbol (at efl_text_cursor.eo:96:7)
  • will result in a ton of new unimplemented methods from bringing in text_cursor to efl_ui_widget

Which makes me wonder if the text_markup interface should get split somehow such that the markup property can exist by itself without dragging in cursor stuff; most users of markup probably just want to set text and not use cursors.

We have already some classes split among interactive and non-interactive versions (efl_text_interactive, efl_ui_scrollable_interactive.eo). In the Markup case, the interactive version could include the cursor handling, and it wouldn't look weird.

zmike lowered the priority of this task from High to TODO.
zmike closed subtask T7591: efl.text as Resolved.Mar 11 2019, 10:47 AM
zmike moved this task from Backlog to Needs experts on the efl: api board.Jun 12 2019, 7:35 AM