evas_font_dir.c:723 already check for if (!font) so I do think it will case overwritten in this part.

@woohyun
Exactly, what data EDC/EINA type we should use to compile/decompile EDC files into Edje, and still be able to read these values.

Yes it passes

In D9280#194357, @woohyun wrote:

@ali.alzyod

I also think parse_int(i) ("i" would be increased till the end of the input) can be used instead of string.

In edje_cc_handler.c , you can check how to use parse_int() easily :)

In T8297#145463, @tasn wrote:

Because the Button widget uses the basic text object which doesn't support markup.

Are there any reason for button or other widgets to not implement Efl.Text.Content.Markup instead of Efl.Text.Content.Plain
I think it is great feature and already implemented, so why not to use it

@tasn @woohyun
Following classes implements the cursor interface (Old design)
Efl.Canvas.Layout_Part_Text
Efl.Canvas.Layout_Part_Invalid

In T8306#145434, @tasn wrote:

Efl2.Text.Content.Markup. See T8297

Not sure I follow. The first two I already said we need, and are in the interface.
What interface ?

efl_text_markup_interactive_cursor_markup_insert
efl_text_markup_interactive_markup_range_get
efl_text_markup_interactive_markup_range_set

You don't need to range set, you just insert the markup again. So range get -> markup insert.

Events :

• Menu,Open Exist
• Menu,Closed Exist
• Menu,Preopen New allow the user to init menu (like add items) before opening it.

Do we really need two interfaces? we can combine them into one interface, since no one really uses interface Efl2.Text.Content.Plain but instead will use interface Efl2.Text.Content.Markup
So I think combining them into one make sense.

interface Efl2.Text.Content
|├ (P) markup
|├ (P) text
|├ (P) bidi_delimiters

In D9309#192156, @tasn wrote:

OK, just wanted to flag it because it looks like css but it behaves quite differently.

This is related to T8067
At this point I am not using CSS styles, But in some point in future we will have something like evas_textblock_css_style_set("color:rgba(255,255,255,1.0);"); which will be converted to EFL style which is "color=rgba(255,255,255,1.0)"

Well, markup handling is external to the text object, we can implement a "legacy_markup" class that translates legacy markup to current one and legacy applications can use. How does that sound?

I still hate there is no background compatibility, thats why I suggested having restriction Mode (NONE, RESTRICTED), where NONE will work the same as legacy one, but for restricted mode, we can add new rules that should be followed.

I have two comments:

is it ok now ?

First:
These functionality already implemented and working, but you want to remove them, (At Widget/Canvas level)
So you are the one needs to give good argument why to remove them,

and the font_size_factor example is not right, the widget will not inherit this font other widget, and EFL was work fine for so long without this feature and we can add it at markup level
If Markup can not be implemented externally it is ok, this will give us dynamic why to make a lot of additional features along the way,

Again, you misread what I said and this is not actually what's going on.
I plan on bringing back style_user, or the style stack. Essentially meaning you have two styles per object. I accidentally removed it, or maybe it was removed by Efl.Canvas.Text and I just forgot to add it back.

evas_object_textblock_style_user_push is legacy API, and with latest changes you can not use it with efl_canvas_text.

I meant the reading. Again we are talking about reading, not writing. I'm saying that in these other platforms you can't sensibly read the value and do something with it. Like you can't do with the EFL. Don't get hung up on the details. The point is that you can't do what you want to do here.

I got the syntax a bit wrong, sorry, but the value is still a string, and the user can't just get it and do something with it, which is what we are talking about here. Not without a lot of parsing, and even with the parsing (understanding what 100% means), they would still need to analyze the whole hierarchy. So I think you're making my argument for me on why this is bad to let people do it.

We are not talking about dataType of these properties, font size can be string/float/double/int, this is another discussion. but for this discussion, I can say you did not approve such approach on other frameworks.

I don't know what you mean by "I" and where exactly during run-time, and how will you hook on layouting?

As for having to look at our documentation, see the link I just posted to @segfaultxavi, it can and will be very short: https://developer.gnome.org/pygtk/stable/pango-markup-language.html

You are talking about markup, and for markup I am 100% with you, and it is dynamic because it is a script
For UI_TExt properties, these should not depend on script, they are values

I will try to split this into two main categories
(1) Setting style at the object level.

For most users setting font size should be as simple as     **efl_text_font_size_set(ui_text, 25);**   instead of **efl_text_style_set(ui_text, "font_size=25");**
It will create alot of issues with first time users like "font_size" or "fontsize" or "font-size"  and he needs to look at our documention to understand,
I do not think it is good Idea to use special script to do simple things as setting object font size.

I think it is fine

@woohyun @tasn
I think we can stick with what we already have, in the previous EFL_UI_TEXT, since changes may need to be done on ecore level.
And what we already provided fair functionality for any user

All changes ready in this pull request into your branch
https://github.com/Enlightenment/efl/pull/3

I would expect a bug if ot actaully is NULL, so i would put some EINA_SAFETY_ON_NULL_XXX macro after the two for loops. Which would also not require to check ot in the next few if's.

This will never happen, this patch just to fix compilation warning you have

init with null

A small suggestion to check D9490
If colors are save as bytes there are optimized techniques to avoid float point calculation. (I do not know if this is useful here :) )

We compare what we have with Android and IOS, I think we already have quite decent support, I think we will need to modify ecore to add additional support.

@tasn Please note these functions/events are not suggestions, they are actually used in edje_entry but we do not have them in the new design.

evas_textblock_cursor_line_geometry_get
It was only ever used to get the line number (now line_number_get). If you want to get the geometry of a line you can get a range geometry, but again, no one ever needed/used that.

1- It is used for in edje_entry to get the geometry of the line, not line number only
2- no one ever needed/used that How do you know that? we internally use it, so it is logical other people use it too.
3- you can get a range geometry But I will need to create two cursors, then delete them after getting the range, is this efficient?

@tasn
While porting from edje_entry we notice missing cursor functions
evas_textblock_cursor_line_geometry_get
evas_textblock_cursor_cluster_coord_set
evas_textblock_cursor_line_coord_set
evas_textblock_cursor_line_char_first
evas_textblock_cursor_line_char_last
evas_textblock_cursor_cluster_next
evas_textblock_cursor_cluster_prev

I have two notes:

@tasn
Can you please explain more about cursor handle? We read the documentation and I do not see why would the user use it if he already has copy function

One Question:
We are talking about TextDirection (which is related to text object and its content), Not LayoutDirection which can be applied to other types of objects (Child of containers for example)?

For following event in RawEditable:
preedit,changed: void; Called when entry preedit changed
In legacy code this event expect info to be passed to it (not void)

Added two more examples
1 - Like here when you type @ followed by a username, that kind of auto completion (no need to actually do the pop-up menu, it's more about finding the correct place to put it.
2- Show word suggestions in the context menu, when you long-press on the word
3- Undo/Redo Example Updated

@tasn can you please take a look at (Undo/Redo Example):
https://github.com/Ali-Alzyoud/EFL2_EXAMPLES/pull/2/files

I do not know why I can not get this warning!
Anyway, this will fix it D9903

oops, Sorry

gcc or clang ?

@zmike do you have special configuration for compilation? (I did not get this error by default)

@tasn @woohyun
I see that a lot of stuff split between (efl.ui.internal.interactive and efl.ui.text) in what already founded in EFL.

@tasn
For password properties : (password_mode and replacement_char)
Will it stay on Raw_Editable or we will move it to efl.canvas.text?
I am asking this because these options are implemented directly on evas_object_textblock level

It was designed this way so you could set a background color e.g. in the style, and just turn it on and off. It's not something I changed, it was designed this way by @raster like 15 years ago. :)
I'm not wedded to this, I'm OK with changing this, but this only solves it for background. Strikethrough may have different styles (like dashed). We can also change strikethrough and backing and etc to be on by default when you set a > > colour for example. That would be a nice solution I think without breaking this ability or without adding complexity.

You are right, it was designed this way, if it is on by default (or when color is set) this would be great

@tasn
1
Regard these two properties which contain only on/off values:
1- Efl2.Text.Style.Properties.background_type
2- Efl2.Text.Style.Properties.strikethrough_type

@tasn for Undo/redo example
We do not have undo/redo functionality, So this will test events (implementation of undo/redo will be handled by user). right?

• upload new font file

In D9053#183037, @bu5hm4n wrote:

Still does not pass tests.

@tasn @cedric
Why do not we use Efl.Gfx.Color interface with style Efl2.Text.Style,Properties
So we can set color with various formats that Efl.Gfx.Color Allow (or extend in future)

• add panel_layout
• add prediction
• add autocapition
• add imf_event

@tasn @woohyun , edje_entry have these functionality (missing in efl.ui.internal.interactive)

Anchor and Items ?
Like _anchors_update, _anchors_update_check, etc and Items functions like _edje_entry_item_geometry_get, _item_obj_del_cb, etc

@tasn No it is not, we are updating/porting current Efl.Ui.Internal.Interactive.c file with edje_entry.c
Do we need to port filter functions like _text_filter_text_prepend or _text_filter_markup_prepend, ... etc?

Changes are in D9838

I mean missing parts in efl.ui.internal.interactivetext

@woohyun These are main parts needs port from entry_edje:

• Preedit Functinality (Missing Parts)
• Anchor Functinality (Missing Parts)
• SELECTION_CLEARED events (replace some of SELECTION_CHANGED)
• Port missing Keyboard handling functionality
  1. Undo/Redo (I think there should be way to trigger them by code)
  2. Selection
• Cursor_Manual_Change
• Filters --This needs new design logic
• Cursor down/up --This needs new design logic

update

In D9628#182979, @bu5hm4n wrote:

This break compilation without harfbuzz.

We collected features we could not find in :
T8151#141680

Comparing Legacy to new Design we could not find following functionality:

How user can do text selection by code using new design (Raw_Edit)?

can we make efl2_text_attribute_factory_ref/unref return same passed pointer instead of void ?

@tasn Please take look when you have time

How about create subtask for main topics to discuss
-Documentation
-Missing Functinality
...
And in Each task we will create subtask for issues regard main topic.
this make it more easy to review and disucss than keep adding comments and scrolling up/down

Where do you like to add comments: here or in Git ?
Like documentation issue, missing functionality compare to legacy, .. etc.

@tasn
Regard this task
Should we make our start point :

At this stage
For example We will replace events like _edje_emit("selection,cleared") with efl_event_callback_call(EFL2_TEXT_RAW_EDITABLE_SELECTION_CLEARED), right ?

code convention

@tasn thank you.
D9819

https://github.com/Ali-Alzyoud/EFL2_EXAMPLES/commit/096d3cea318be85df1972402f52e6545027bbe98

I will create github repo.

I think the first step would be to anyway move edje_entry to its own objec

Do you mean EO object ?

This is repo for the examples :

I think we can reuse the code in efl.ui.internal.interactive, and move the remaining from edje_entry into Efl.Text.Raw_Editable

1- Regard performance and memory, I think real test with heavy use on Text Widget can convince both of us, I hope we can find time to do it before release.

This is orthogonal to this issue. This needs to be done regardless if you change it as you suggested or not.

I like your idea, I will try to find better way so you can add your comments

This example about spell check (it is very bad Sorry), lets use it as starting point (comments start with //ali.m points about challenge I had)
Note Please forget about memory leak at this point

By lightweight I mean:
1- Less memory, it is not required to store extra information about selection/interactive/ .. etc.
2- Less internal processing

a -  Less checks (isSelectable,isEditable)) for example when widget is clicked
b - In label for example when you set content, you do not need to reset selection/interactive/ ...etc

3- Less initialization processing/time

If we replace all edje_entry functionality to be in Efl2.Text.Raw_Editable, it will make Raw_Editable feature rich object. (it is ok when used with efl.ui.text).

I suggest small Idea
Property to read scale_factor (Width, Height).