Page MenuHomePhabricator

RFC: Text interfaces design proposal
Open, Incoming QueuePublic

Description

General description

This is the first part of the proposal. It currently doesn't address anything about Evas (so no entry or elementary stuff), those will follow shortly and this task description will be live-updated as I go.

Efl.Canvas.Text

Efl.Canvas.Text is the main "textblock" object. Its role is just drawing text, formatting it, and manipulating it (only from code, no user input).
It's essentially what textblock is at the moment, but with a few important changes:

  • The concept of formatting has changed. You no longer have standalone format items, but rather annotate a text range (Efl.Text.Annotation.Factory). This is much faster and more robust.
    • You manipulate this object using functions rather than free text.
  • Markup is no longer a core part of the textblock object, but is rather implemented by external "utilitiy" functions that translate markup to annotations and vice versa.

Efl.Text.Cursor

This is the main object you use to manipulate textblock text. They are properly Eo objects when exposed, but just lightweight structures internally.
Having them as objects means can also emit events when they e.g. change - This feels like a good idea but could also keep the lightweight implementation that's currently there and just implement utility functions.

You just use it like we currently use cursors.

Efl.Text.Annotation.Factory

This is the main object used to manipulate the annotations. The way it works is a similar concept to a transaction.
You create an object of this type when you want to annotate a textblock and you can keep it alive until the textblock is deleted.
You then set all the wanted formats on the object (with potentially clearing it first) and then insert it to the textblock once ready.

For example (in psuedo code):

an_factory = Efl.Text.Annotation.Factory()
an_factory.clear() // Only needed if the object is already dirty
an_factory.color_set("red")
an_factory.insert(red_cursor_start, red_cursor_end) // makes the text in range red

an_factory.weight_set(BOLD)
an_factory.insert(cursor_start, cursor_end) // makes the text in range red + bold because we haven't cleared the object.

Efl.Text.Item.Factory

Almost identical to Annotation but used to insert items rather than annotations.

Efl.Text.Raw_Editable

Needs a better name, but is essentially what edje_entry was, but not tied to an edje object
It accepts user input, handles selection, IMF, and what not.
Need to decide, but it's probably NOT theme aware. So has no theme. Need to figure out how this comes to play with selection, cursor and etc, though I think it can work. At worst it can have hooks for objects for that.
XXX: Instead of an object it could probably be *internal* utility functions that just set the correct callbacks and handling.

Efl.Ui.Text

Previous elm_entry. Will have a theme with a place to swallow the raw_edit object it's composited of. Can also be made scrollable.
Theme will have all of the components that are currently there (cursor, selection, scroller, label, non scroller) but instead of a textblock part you'd have a textblock swallow object. The style for the textblock would have to be in variables and parsed the same way markup is parsed.

Open questions (I'm not sure what to do)

  • ATSPI stuff - what should be done with them

Implementation

The implementation has now moved to the actual .eo files in my devs/tasn/ifaces. All the eo files which name starts with efl2_ are the new one I created so please review them. They are constantly being updated and my notes are marked with FIXME.

You can also now comment about naming, but please don't comment about missing docs or stuff that are obviously in progress. Thanks!

Related Objects

StatusAssignedTask
Opentasn
Openwoohyun
Resolvedwoohyun
Openwoohyun
Resolvedwoohyun
Openwoohyun
Wontfixwoohyun
Invalidali.alzyod
Openwoohyun
Resolvedtasn
Opentasn
Openwoohyun
Openwoohyun
Openwoohyun
Openwoohyun
Openwoohyun
Openwoohyun
Openwoohyun
Openwoohyun
Resolvedtasn
Resolvedtasn
Openwoohyun
Openwoohyun
Openwoohyun
There are a very large number of changes, so older changes are hidden. Show Older Changes
tasn added a comment.Aug 20 2019, 6:27 AM

So each user want to create Markuptext should create his own Markup builder ?! I do not think this is good for user

That's a bit of an unfair statement, as the code I showed was only about html -> markup conversion. The only part there that was "create your own" is having <span font_weight="bold"> vs efl_text_font_weight_set(an, BOLD). The rest is the translator layer structure.
So what you're arguing here is that having the code be:

str = ""
for node in html_nodes_from_url("https://www.enlightenment.org"):
   if node.is_plain_text: str += node.content
   if node.tag == 'b': # Assumes a slightly different HTML parser API than above, otherwise it would even more complex
       start = len(str)
       str += node.content
       an = annotation_new()
       efl_text_font_weight_set(an, BOLD)
       an->annotation_insert(str, start, start + len(node.content))
   ....

Is significantly better, which I disagree with. More than that though, it's surely much less efficient.
Given that markup *is* API too, I don't see how using the functions rather than markup text directly is any easier in the html translation case.

I look into other framework so I do not reinvent the wheel, Also give ability to user to do things as he can in other platforms

Building Markup(Rich) text is done in most platorms on specific object, not textView/Canvas
Android, UIKit, Appkit, Qt, GTK So I do not think they do it without any use cases.

How do you create Pango markup in GTK detached from a Pango object? I don't think you can, and I don't know enough about the rest, but I suspect (as I said before) that it was just an API design choice rather than anything else.
Though even if you can, and you think that there's a reason why they all made this decision, could you uncover this reason? I'd love to improve this API if there's a reason, but I don't see the point of just copying others blindly.

In my example, why did you assume data is in HTML format, it could be anything andmaybe building it without annoatation could be very hard (you need to do it from scratch).

could you uncover this reason? I'd love to improve this API if there's a reason, but I don't see the point of just copying others blindly.

This is not the job of textblock/textview to create and manipulate markup text.
textblock/View layout and render text.

tasn added a comment.Aug 20 2019, 6:43 AM

I think either I'm misunderstanding you, or not explaining myself well enough because your messages seem to support my point, I'll try to explain what I mean again.

In my example, why did you assume data is in HTML format, it could be anything andmaybe building it without annoatation could be very hard (you need to do it from scratch).

Was just an example! The same applies to if your data is a json string, or is written in sign language. You need a translation layer from your super special format to efl markup. Doesn't matter how you twitst it, it will look something like what I wrote. You have a parser and from it you generate markup.

Could you maybe provide a psuedo code example of such a translation layer (similar to what I used) where you think annotations are drastically superior to just inserting text like the example I showed above? The only such example that comes to mind is if you explicitly serialise annotations and text separately in a structure format. Though if you are doing that, then there's no preprocessing to be done. You can just keep this structure and apply it to the text object when needed. Because I don't think we are talking about the same thing.

could you uncover this reason? I'd love to improve this API if there's a reason, but I don't see the point of just copying others blindly.

This is not the job of textblock/textview to create and manipulate markup text.
textblock/View layout and render text.

I don't know why you quoted the line you quoted, because it doesn't seem to be directly relevant, though I completely agree with this statement, which is exactly why I separated the whole markup concept *away* from textblock. Textblock under my proposal doesn't understand markup, doesn't even know it exists and doesn't care. It's just a random format we chose for serialisation that's not relevant to textblock.

Let me ask my questions again: where is your Pango example, and can we think of a reason to have it? Because I really can't.

+GTK
https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html
(Iterators and Markup are implemented on Markup Object(GtkTextBuffer) level )

In pango case as I see it (I am not expert in it, and it is hard to compare with efl, because it expose lot of things).
https://developer.gnome.org/pango/stable/pango-Markup.html
https://developer.gnome.org/pango/stable/pango-Text-Attributes.html
Parsing Markup text is not done on Text Layout, there are specific part responsible for parsing and building markups(Text + TextAttributes)

I mean why we need to attach this funcinality (Create and manipulate markups ) to be part of canvas, why cannot to expose it, and everyone can use it canvas and other objects and users (everyone), Why do we need to hide it in TextBlock

tasn added a comment.Aug 20 2019, 8:53 AM

+GTK
https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html
(Iterators and Markup are implemented on Markup Object(GtkTextBuffer) level )

In pango case as I see it (I am not expert in it, and it is hard to compare with efl, because it expose lot of things).
https://developer.gnome.org/pango/stable/pango-Markup.html
https://developer.gnome.org/pango/stable/pango-Text-Attributes.html
Parsing Markup text is not done on Text Layout, there are specific part responsible for parsing and building markups(Text + TextAttributes)

I know you have text attributes in pango, which are the equivalent of our text annotations. Though I don't see how you can apply them on a string in order to generate a markup like you said above.

tasn added a comment.EditedAug 20 2019, 8:58 AM

I mean why we need to attach this funcinality (Create and manipulate markups ) to be part of canvas, why cannot to expose it, and everyone can use it canvas and other objects and users (everyone), Why do we need to hide it in TextBlock

Please rephrase, I don't understand what you are trying to say.

Though from what I did manage to read, it seems like you understood the opposite of what I was trying to say. Let me repeat this again: textblock in my proposal has no notion of markup. It doesn't understand <b>, it doesn't understand &nbsp; it doesn't understand any of that. So we are not hiding anything in textblock because textblock isn't even aware of it!

Again, as said above, you keep on making claims like "so everyone can use it", could you please add some example code for an example use case you have in mind so I can actually understand you?

I'm spending a lot of time trying to understand what you are writing and thinking and it's very hard for me without concrete examples. I'd really appreciate if you take more time to read what I wrote and think about what I'm trying to say and if you still don't agree, give a proper response with examples and code supporting your case, like I've been doing. Thanks!

@tasn @ali.alzyod

I also like the idea of @cedric to keep all the discussions here.
But, because we only have limited time for this work, I think it can be good to talk in chat for long discussion.
(And then, let's share the result here)

How do you think about this ? :)
I opened one chat for Text discussion ~ Z169 (if there is another existing chat room for text discussion, please invite me ~)

Let's talk about exposing text features from textblock ~

@tasn This is the example:

eflMarkupObject mrkpObj;         // this is formatted text (Not string, instead conatins formatNodes, and textNodes)
Cursor c1 = new Cusror(mrkpObj)  //Cursor work on this object
Cursor c2 = new Cusror(mrkpObj)  //Cursor work on this object
anFactory an= new Annotation_Factory();
an.SetWeight(BOLD)
an.Insert(c1, c2);

// This what I mean that there are no dependancy on TEXTBLOCK
// cursor are not attachted to text bokc

EflTextBlock tb;
tb.setMarkupObject(mrkpObj);
tb.setMarkupString(mrkpObj.toString());

What I am trying to clarify that, we should have attribtedTextObject (MarkupTextObject), Where Textblock and all widget expect it as input to along with plainText

tasn added a comment.Aug 21 2019, 6:14 AM

Thank you. This is what I thought I understood. As discussed on Z169, I don't see the value in this and I debunked all of the specific potential benefits you raised there.

I think it is best to discuss other parts too, current discussion could be discussed in better way.

Second Part:
Font
1- Why Font is interface rather than class?
2- Font does not have Size (Point/Pixel) property
3- Some styles need to move to this class, like bold/italic/ ...etc.


tasn added a comment.Aug 21 2019, 6:57 AM

I think it is best to discuss other parts too, current discussion could be discussed in better way.

Second Part:
Font
1- Why Font is interface rather than class?

It's already explained with examples in the original post.

2- Font does not have Size (Point/Pixel) property

I didn't want to change what's already there in the efl. The font are "unit sizes" (don't remember which unit) and they just scale with the rest of the system. If you want to allow pixel perfect font sizes, take it up with @raster. :)

3- Some styles need to move to this class, like bold/italic/ ...etc.

They are already in this interface.


Please try to read my proposal more carefully, as these are things that are already addressed. Especially the 3rd point. Weight and slant are 2 of like 8 properties of this interface, hard to miss.

It's already explained with examples in the original post.

What post ?

I didn't want to change what's already there in the efl. The font are "unit sizes" (don't remember which unit) and they just scale with the rest of the system. If you want to allow pixel perfect font sizes, take it up with @raster. :)

We will not change what we have already, even "unit size" property is ok, how would user change font size of textblock?

Please try to read my proposal more carefully, as these are things that are already addressed. Especially the 3rd point. Weight and slant are 2 of like 8 properties of this interface, hard to miss.

Sorry, Maybe if we use more common names like italic/Bold it will be much simple to figure them out by normal users

tasn added a comment.Aug 21 2019, 7:11 AM

It's already explained with examples in the original post.

What post ?

This one, scroll all the way to the top.

I didn't want to change what's already there in the efl. The font are "unit sizes" (don't remember which unit) and they just scale with the rest of the system. If you want to allow pixel perfect font sizes, take it up with @raster. :)

We will not change what we have already, even "unit size" property is ok, how would user change font size of textblock?

Using the Efl.Text.Font interface, again already addressed above, please read the proposal.

Please try to read my proposal more carefully, as these are things that are already addressed. Especially the 3rd point. Weight and slant are 2 of like 8 properties of this interface, hard to miss.

Sorry, Maybe if we use more common names like italic/Bold it will be much simple to figure them out by normal users

If you don't understand something (like had no idea what weight and slant were), please ask, or better yet, Google. Adding comments on a proposal you don't fully understand is a waste of time.

As for your comments, both italic and bold are not the correct terminologies. More so, in CSS (as common as it gets) and GTK (the two I know well) it's called "font-weight" (same as here) and "font-style" with the full name font *slant* style, so again the same as here.

I'm not that crash hot on Efl.Text.Annotation.Factory. Certainly as a name... Wouldn't Efl.Text.Range be better and as part of the constructor/construction of the range you have to pass 2 cursors? the question now would be - does the range keep tracking the cursors or is it fixed and the cursors are just used as markers for begin/end when u construct or set/change them later? so more:

r = Efl.Text.Range()
r.color_set("red");
r.range_set(cursor_start, cursor_end);
r.weight_set(BOLD);

Once you set the range the range attaches it to the Efl.Canvas.Text object the 2 cursors are attached to implicitly? The range object becomes a child obj of the text obj and thus is destroyed along with the text obj? Now should range_set just USE the cursor values at the time so you can now re-use the same cursors to rang_set() on another range obj with different positions (you moved the cursors around).? What you have seems to be a range factory we can re-use but once you've inserted a range into the text obj.. then what? how do i manipulate it later?


I assume Efl.Text.Item.Factory is for non-text/string items? Like the inline images we can do in current textblock? how does this work with the text STRINGS and the ranges applied to them? How does deleting or modifying text affect items?


As for STRICT text with formatting separate with your annotations... what does \n or\t then mean in a string? how do you add newlines? is this an item or what? because regular ye-olde ascii inlines SOME formatting like these and devs tend to expect it unless u say its markup then they think tags are how this is done?


@property halign

What if people want 1 paragraph left and one right and one center aligned?

@property valign

As a global - yes, but we will need valign within a line too... is it aligned to the base (so ascent/descent all come from the same point) or center/top/bottom - etc.

@property wrap
@property line_spacing
@property line_spacing_factor

Same as above? different paragraphs... ? a lot of the properties here could do with a rethink on these points?


Efl.Text.Item.Factory - I'm also not hot on this like annotations above - similar reasons...

I think this brings up a whole discussion on what is text. is \n and \t text? are they to be invalid chars or ignored? just rendered at "boxes" or blank and ignored? We need a way of inserting content that is a "image here" or "newline here (break line and go down 1 and start formatting at origin of line now" or other items we insert into the text. how should they be represented in a sane way that they are easily addressable later on etc. I don't think this proposal makes this clear (at least to me)?


@bu5hm4n: And the emitting of a single event might walk this whole list. So maybe its better to connect them via API instead of events (just as a comment)

I think he has a very good point here. I also smell a lot of overhead with events here...

@tasn
Again Font should not be interface, Are there font-able objects other than font object?
If my class use font object then he composite inside, not adopt new interface, do you have any example from other platforms ?

Using the Efl.Text.Font interface, again already addressed above, please read the proposal.

I search all the post, and did not see size other than this <span size=12 color=...>

If you don't understand something (like had no idea what weight and slant were), please ask, or better yet, Google. Adding comments on a proposal you don't fully understand is a waste of time.

I am worry about normal user not myself :)
https://developer.apple.com/documentation/appkit/nsfont/1535194-italicangle?language=objc
https://developer.android.com/reference/android/graphics/Typeface
https://doc.qt.io/qt-5/qfont.html#italic
Design phase never waste time, so to pick simple and more popular naming is always good

Lets discuss this one first :

interface Efl.Text.Font
Can also be applied to annotations
functions and properties:
@property font

can you please help me understand what is this @property font?
Is it string ? why it has same name as interface ?

tasn added a comment.Aug 21 2019, 8:26 AM

Lets discuss this one first :

interface Efl.Text.Font
Can also be applied to annotations
functions and properties:
@property font

can you please help me understand what is this @property font?
Is it string ? why it has same name as interface ?

It's the same as what's currently there in the existing efl_text_font.eo file.

ali.alzyod added a comment.EditedAug 21 2019, 8:34 AM

This is clear things up, to know that we are based on current existing stuff

So how about break this @property font
Into :
@property fontfamily
@property fontSize
To make it more clear what does it mean.

tasn added a comment.Aug 21 2019, 10:17 AM

@tasn
Again Font should not be interface, Are there font-able objects other than font object?
If my class use font object then he composite inside, not adopt new interface, do you have any example from other platforms ?

Yes, potentially part_text, and I want to expose the old "text" (not textblock") object as an eo object too, so that one too.

Using the Efl.Text.Font interface, again already addressed above, please read the proposal.

I search all the post, and did not see size other than this <span size=12 color=...>

Here it is: "XXX Should probably be removed and instead have a way to set an annotation like object on the object. Or maybe it should be a "part interface"". Search for that. It refers to the style property and explains how you'd set annotation on the object.

If you don't understand something (like had no idea what weight and slant were), please ask, or better yet, Google. Adding comments on a proposal you don't fully understand is a waste of time.

I am worry about normal user not myself :)
https://developer.apple.com/documentation/appkit/nsfont/1535194-italicangle?language=objc
https://developer.android.com/reference/android/graphics/Typeface
https://doc.qt.io/qt-5/qfont.html#italic
Design phase never waste time, so to pick simple and more popular naming is always good

I have X amount of hours I can spend on doing this, I could spend them on doing work, or I can spend them on bikeshedding based on misinformation ("more common names like italic/Bold" implies the current naming is bad). So we can definitely waste time...

The android example is a joke. You can't refer to it as a good example. It literally has an enum consisting of BOLD/BOLD_ITALIC/ITALIC...

The qt example that you gave also uses weight and for italic it uses both style and italic (which do the same, implying it's some compat thing).

Anyhow, CSS has more marketshare than all of the above combined.

tasn added a comment.Aug 21 2019, 10:56 AM

This is clear things up, to know that we are based on current existing stuff

So how about break this @property font
Into :
@property fontfamily
@property fontSize
To make it more clear what does it mean.

Good point! If memory serves the reason why they were originally together was because this was how freetype works (it was created long before I joined), but I added a note to change this. Thanks!

ali.alzyod added a comment.EditedAug 21 2019, 10:51 PM

@tasn How about Break discussion of each topic/class/interface to its own sub-task.

For Example in Font sub-task we will discuss font related stuff

tasn added a comment.Aug 22 2019, 1:24 AM

Thanks for the suggestion, but I think that would make it harder for me rather than easier. The concepts are very much connected (e.g. Font on its own means nothing, how is it used?) and often there's overlap.

I'm happy to move to email, a tool that was actually meant for discussions, but I understand there's resistance, so let's keep it here.

I think we want to search another name for *font* in general, font does sound like it is representing a font itself, but it is not. I would go for *fontable*, since it expresses that this receives font-properties, but is not a font. (I am bad at naming, happy to have something besser fitting here)

tasn added a comment.Aug 22 2019, 1:51 AM

I think we want to search another name for *font* in general, font does sound like it is representing a font itself, but it is not. I would go for *fontable*, since it expresses that this receives font-properties, but is not a font. (I am bad at naming, happy to have something besser fitting here)

That's a great point, thanks for bringing this up! I personally don't like "fontable" or any other similarly made up word, but it definitely can't be "Font" either because as you said, it's confusing. Efl.Text.Attributes.Font is too long. Maybe Efl.Text.Attrs.Font? Efl.Text.Style.Font? I think this better implies it's an interface... Obviously the formatting interfaces will also move under this namespace. Thoughts?

What's the guideline for this in the EFL? Grepping through the sources I see a mix of both "able"-type interfaces and just normally named.

tasn added a comment.Aug 22 2019, 2:31 AM

I'm not that crash hot on Efl.Text.Annotation.Factory. Certainly as a name... Wouldn't Efl.Text.Range be better and as part of the constructor/construction of the range you have to pass 2 cursors? the question now would be - does the range keep tracking the cursors or is it fixed and the cursors are just used as markers for begin/end when u construct or set/change them later? so more:

r = Efl.Text.Range()
r.color_set("red");
r.range_set(cursor_start, cursor_end);
r.weight_set(BOLD);

Once you set the range the range attaches it to the Efl.Canvas.Text object the 2 cursors are attached to implicitly? The range object becomes a child obj of the text obj and thus is destroyed along with the text obj? Now should range_set just USE the cursor values at the time so you can now re-use the same cursors to rang_set() on another range obj with different positions (you moved the cursors around).? What you have seems to be a range factory we can re-use but once you've inserted a range into the text obj.. then what? how do i manipulate it later?

They are just markers for the initial insertion, they are not attached to it. Think of it like any other cursor operation, it's just used for the location.

There are a few reasons for the factory (as discussed extensively on IRC). Having a factory lets us have an Eo object to interact with when manipulating the annotation (let's call it Span from now on) object but not necessarily have an Eo object for every annotation. The thing is, you can have A LOT of annotations, as you need to annotate the whole document to keep its size. So just creating all of them (even if they are unreffed and killed internally), it's still a lot of object creation and destroying. I think we actually have object cache exactly for these cases, but still, it's annoying and heavy for no reason. The factory lets you just create as many lightweight handles as you want - easily, and only save references to whatever you want.


I assume Efl.Text.Item.Factory is for non-text/string items? Like the inline images we can do in current textblock? how does this work with the text STRINGS and the ranges applied to them? How does deleting or modifying text affect items?

Not sure I fully get you, but I think it's something we addressed on IRC. Items in this context are *only* visual items. Span (above) is for changing the look and feel. Items is for having a character like item (e.g. an image or whatever else you want to embed). Items in the text are represented with the unicode [OBJ] (OBJECT REPLACEMENT CHAR) and are really just part of the text. You can attach metadata to them to change their size and how they are rendered. For example, internally, "item_insert" of this interface inserts an [OBJ] and its metadata. Just like we have now.


As for STRICT text with formatting separate with your annotations... what does \n or\t then mean in a string? how do you add newlines? is this an item or what? because regular ye-olde ascii inlines SOME formatting like these and devs tend to expect it unless u say its markup then they think tags are how this is done?

\n is a newline, \t is a tab. You just enter it like normal text. So if you think for example about the browser, text_set behaves like a .txt file, and markup_set behaves more like an .html file.

If you go the plaintext route you just enter text and you can decorate it *afterwards*. This is extremely useful with dynamic text when the user edits a text entry, or e.g. a code editor with syntax highlighting. Or a rich text editor where you have "real" formatting (e.g. the user wants bold) and "temporary" (e.g. an underline because of a spelling mistake).

If however your usecase is setting a known-in-advace or non-editable string, you'll probably just use the markup utils to set the text.


@property halign

What if people want 1 paragraph left and one right and one center aligned?

I was gonna reply "oops :)", but it's actually something I already addressed in the notes there! Yup, it needs to move to something annotations can use.

@property valign

As a global - yes, but we will need valign within a line too... is it aligned to the base (so ascent/descent all come from the same point) or center/top/bottom - etc.

That's a good point, should add it to ascent.

@property wrap
@property line_spacing
@property line_spacing_factor

Same as above? different paragraphs... ? a lot of the properties here could do with a rethink on these points?

Same as above, I already have a note to decide. Good feedback that you also think that these should be applicable to formatting.


Efl.Text.Item.Factory - I'm also not hot on this like annotations above - similar reasons...

I think this brings up a whole discussion on what is text. is \n and \t text? are they to be invalid chars or ignored? just rendered at "boxes" or blank and ignored? We need a way of inserting content that is a "image here" or "newline here (break line and go down 1 and start formatting at origin of line now" or other items we insert into the text. how should they be represented in a sane way that they are easily addressable later on etc. I don't think this proposal makes this clear (at least to me)?

We already covered this on IRC, though \n and \t are text yes. Everything that you have a unicode char for is text. Again, textblock doesn't have a notion of markup, so for textblock \n is text. Same as Paragarph-separator and unicode newline character (different to \n). Those are text. :)

We can attach metadata (or formatting annotations) to change behaviour of characters (e.g. \t), though most of the future extensions (so crazy object behaviours like bullet points) would be done using [OBJ] and custom items.


@bu5hm4n: And the emitting of a single event might walk this whole list. So maybe its better to connect them via API instead of events (just as a comment)

I think he has a very good point here. I also smell a lot of overhead with events here...

Already addressed this, my proposal actually does *the opposite* because it splits the events to different objects. :)

In T8151#140714, @tasn wrote:

What's the guideline for this in the EFL? Grepping through the sources I see a mix of both "able"-type interfaces and just normally named.

Yeah, we named things blaable if it serves, but it does not sound good here.
In general, be carefull with too many ".". A namespace just for one interface is ... weird. However, we can come back to the namespace once the basics are done (I think its too early to nitpick the ns). I am happy with the general transported message of the new names ... :)

I will send you email regard Spans.

For Font

From what I understand only TextCanvas and TextBlockCanvas have a real implementation for Font Interface, where both will have 2 implementation for this interface, other widget can not really implement these interfaces, but they will keep forward calls to internal textblock/textobject.

For me having font Interface is hard to understand, Font can live by it self (I try to search for any similar approach in other popular frameworks but I did not find any).

Example and use cases to have font object.
Example (1):
Create Font Object, and use it in multiple Text Elements/widgets, buttons, ... etc.
Which save resources a lot (like when using system default font),

Example (2)
Create multiple font Objects (for example in application splash screen/loading)
Then I can use these font object in my text block/widgets/buttons,. .. etc

ali.alzyod edited subscribers, added: AbdullehGhujeh; removed: abdullah.Aug 22 2019, 3:28 AM
Font f = new Font("Arial",25);
TextBlock t;
Button b;
Label c;

t.font = b.font = c.font = f;// this is shared for all objects
tasn added a comment.Aug 22 2019, 4:21 AM
Font f = new Font("Arial",25);
TextBlock t;
Button b;
Label c;

t.font = b.font = c.font = f;// this is shared for all objects

Let's chat off-band before we continue discussion because I feel like we are misaligned on the fundamentals and that needs to be solved before we can continue discussing.

As for this example, yeah, it looks pretty, but when you think on what it involves in C: refcounting, allocations, immutability (so re-allocations) and whatnot, for only little (any?) benefit, you realise it's actually not worth it.

tasn updated the task description. (Show Details)Aug 22 2019, 10:12 AM
tasn added a comment.Aug 22 2019, 10:17 AM

I change a few things based on the discussions of the last few days. I added a very rough sketch of the Raw_Editable object. It needs much more work, but I suspect this one will only be finalised after it's at least partially implemented. I suspect it'll probably be very similar to what efl_ui_text.eo has (when it comes to the context menu/imf stuff like autocaptial), just probably cleaned up and trimmed down.

tasn updated the task description. (Show Details)Aug 22 2019, 10:17 AM
tasn added a comment.Aug 22 2019, 10:34 AM
  1. I do not know how all those objects are connected with each other, however: When benchmarking lately, you could observe that we very often spent a lot of time in emitting events, due to the fact that the event callback list is getting giantly long. And the emitting of a single event might walk this whole list. So maybe its better to connect them via API instead of events (just as a comment)

Another comment about this one: in Eo we have API to check if anyone is listening to a certain callback and keep a cache of this result (there are also events to help us keep this up to date). This was created for a couple of reasons, but one of them was so we can just not call "callback_call" for events that happen a lot when we don't need to (as an optimisation). So in case you encountered this issue elsewhere, this may be what you're looking for.

tasn updated the task description. (Show Details)Aug 22 2019, 10:53 AM

Actually, I also added my initial thoughts regarding the elm_entry layer because there really not that much to it. So on a high level this is the complete proposal of how things are going to look. There are still a lot of comments here, and even more comments I have for myself, so a lot of things can and will still change, though conceptually they will stay the same (or at least follow some of the notes in the comments). I'll keep on translating my notes to something readable and update this document. :)

tasn added a comment.Aug 24 2019, 7:16 AM

It looks like there aren't many (any?) high level objections to this proposal for now other than @ali.alzyod's which I believe I already addressed on a call we had.
I'm therefore thinking it may be time to take this proposal one step further. I plan on creating .eo files based on this proposal in addition to writing more detailed usage examples and descriptions (a longer version of what's currently there in the General Description section). This will exposed a lot of details that are currently opaque in the design description above (such as property types and method parameters) and include better detailed inheritance structure and will also include events.
The more detailed guides will also shed light on how I envision using the text objects will look like.

Important note: the proposal above, as laid out, is still incomplete, and during this process I'll also iron out those missing details and include missing objects/widgets (such as the Efl.Text.Simple -> currently the simple text object) and missing classes/interfaces that are needed for the inheritance tree (such as a base class for the object factory).

So, what do I want from you? Please let me know ASAP if you have any reservations regarding the current design, concrete or otherwise.

Thanks!

@tasn
Here is my comments on current design


Efl.Text.Annotation.Factory

I will add my comments(If I have any) after eo file structure finished

  • How about this, Add immediate functionality(static) to Annoation.Factory

    Efl.Text.Annotation.Factory.annotate(TagName,TagValue,start_cursor,end_cursor);//No need for clear function no internal state reserve

    This will allow user to apply annotations without need to create Annoation.FactoryObject, for purpose of simple apply annoations
  • IMO Attributed Text is clear

Raster hates annotation. Span is a bit confusing. How about Attribute (like Pango)? Something else?


class Efl.Text.Item.Factory
I will add my comments(If I have any) after eo file structure finished

  • Will we have to define Items types, Item Objects, … etc ?
  • Can user able to create complex objects For example Span in Span, or ListItem inside ListItem ?

interface Efl.Text.Content

  • @property text : Is this Plain Text ? get/set content without formats/styles
  • @property MarkupText : will be available too ?
  • @property paragraph_direction : shouldn't this be in a different interface (Paragraph Style) ? If we have paragraph style, then I think alot of stuff will move there, example <ps style=”direction:right”>

interface Efl.Text.Font

  • How about naming it to FontDescription/FontStyle interface
  • @property size : May be specify what is this size unit (ptSize,pxSize, ... etc)
  • @property Size_Unit : it can accept enum, FontUnit.Point,FontUnit.Pixel,FontUnit.Em, .. etc) for future uses
  • I think we can help user with functionality to retrieve all available fonts on the system

interface Efl.Text.Format
It is not very easy to differentiate between Style and format, I understand this as property of textblock object it self, not the content.

  • @property valign : I this is already founded/conflict with efl.text.style property
  • @property visiblityMode:
instead of password property user can user visiblity mode to control such features.  (It may also replace multiline property too)
VisiblityMode (Enum)   like Normal,Password,HideContent,.. Etc
Handle visibility of textblock content, where we can view it as password or normal text. (May be extend it with more options like PlainText, PasswordNoEcho, .. etc)

interface Efl.Text.Style
From what I read from “interface Efl.Text.Format” this interface should be applied on Efl.Text.Content rather than Efl.Canvas.text Object

  • @property underline2_color
  • @property glow2_color
  • @property halign
  • @property valign

how about use more clear naming for these properties


class Efl.Canvas.Text

  • @property legacy_newline : Do we need this in new interface ?
  • calculate_character_count : I think this can be calculated using TextBlock.Content.Text.Length
  • cursor_new : Does not Cursor constructor expect to be like: Cursor(Efl.Canvas.Text tc), so why do we need this ?
  • @property Main_cursor: User can use this property directly to interact with TextBlock, without the need to create new cursor each time he interact with it, and save that curosr.

class Efl.Text.Cursor

  • Does cursor Object have Text.Style? for example If I insert text using cursor, how to apply styles ?
  • @property content
1- Does this mean cluster before or after the cursor position (this could be dependant if text is RTL or LTR)
2- I think return single entity using this property is much simpler to implement, because with RTL/LTR text if we return pointer to content, it could mean rearrange text before return them.

-@property geometry: Is it same as current interface ?, what if user want to know current cursor position ? is it Rect/Point ?

  • Sometimes cluster replaces two unicodes points with totally new single glyph, and sometime cluster built using multiple unicode point glyphs, So deleting them is dependant on what type is this cluster ? look at D9628

class Efl.Text.Markup

  • For Setting and Getting MarkupText on Efl.Canvas.Text, user can only use this functionality ? , or we will add properties to textblock to get/set markups ?
  • Can we have more descriptive markup parsing functionality ( like get errors while parsing text) ?
  • Can we specify Restriction level, for example tags case insensitive, escape character case insensitive(for case insensitive ones)
  • Can we have Markup version? where user will specify markup version (use default), where it will simplify extending the language in future and keep legacy(old versions) to behave the same

Efl.Text.Raw_Editable extends Efl.Canvas.Text

  • Is this public class or internal class? How about Efl.Canvas.EditText?
  • Do you mean Efl.Canvas.Raw_Editablet (Efl.Canvas name space) ?
  • I see this as widget not canvas. what do you think ?
  • Why user use this class instead of Efl.Ui.Text?
  • @property editable: How about Readonly? To not conflict with its name/purpose.
  • @property selection_allowed : How about Selectable or is_selectable.
  • @property selection_cursors: How about selection_range, it is (array of) pair of cursors
  • interface selection : where user specify properties like selection_background_color, selection_foreground_color, multible selection, .. etc

Efl.Ui.Text extends Efl.Ui.Layout

  • Can user use Efl.Text.Raw_Editable functionality on efl.Ui.Text Object?
  • DND mode, is it available ?
tasn added a comment.Aug 26 2019, 6:05 AM

Thanks for taking the time to comment.

**Efl.Text.Annotation.Factory**
 
I will add my comments(If I have any) after eo file structure finished

 - How about this, Add immediate functionality(static) to Annoation.Factory
  
   Efl.Text.Annotation.Factory.annotate(TagName,TagValue,start_cursor,end_cursor);//No need for clear function no internal state reserve
 
  This will allow user to apply annotations without need to create Annoation.FactoryObject, for purpose of simple apply annoations

This can't really be done, because if you notice from the proposal, we don't have a string representation for annotations anymore, only the functions that are exposed in the interface. So you don't really have a tag name and value to set.

Even if it was possible, I don't think it ads enough value to be worth having this special case. I can elaborate on the reasons, but since it's not possible, better to not waste our time. :)

  • IMO Attributed Text is clear

Raster hates annotation. Span is a bit confusing. How about Attribute (like Pango)? Something else?

I tend to agree.


class Efl.Text.Item.Factory

I will add my comments(If I have any) after eo file structure finished
 - Will we have to define Items types, Item Objects, … etc ?

I'm not sure I understand what you meant.

  • Can user able to create complex objects For example Span in Span, or ListItem inside ListItem ?

Span is not an item, so I'm not sure what you meant by that. Regarding List-Item: yes, but the logic is completely external to the textblock. As I explained to raster (either here on IRC, I don't remember, but you were present), list items should be implemented by a higher layer and are essentially an external object (spacing + the bullet point) that's inserted in the text object. So whatever handles it would have to handle indentation. This is however external to the textblock object.


interface Efl.Text.Content

  • @property text : Is this Plain Text ? get/set content without formats/styles

Yes, as I said before, the concept of markup is external.

  • @property MarkupText : will be available too ?

I thought I put it in the comment section, but apparently it's only in my local comments. Yes though, there will be such a helper property. Though this property will not be in this interface but rather another one.

  • @property paragraph_direction : shouldn't this be in a different interface (Paragraph Style) ? If we have paragraph style, then I think alot of stuff will move there, example <ps style=”direction:right”>

Not sure what you have in mind for paragraph style, what other things are missing?
Regardless, you misunderstood what paragraph direction. The direction of the paragraph is not its alignment, it's is bidi direction. So the values are rtl, ltr, inherit and auto (iirc). Just like is there now.


interface Efl.Text.Font

  • How about naming it to FontDescription/FontStyle interface

We already discussed it, it's there in the notes.

  • @property size : May be specify what is this size unit (ptSize,pxSize, ... etc)

We've already discussed it both on the phone and this thread (or maybe IRC?), this is not how things are done in the EFL. If you want to start supporting different sizing units, raise it elsewhere, not here.

  • @property Size_Unit : it can accept enum, FontUnit.Point,FontUnit.Pixel,FontUnit.Em, .. etc) for future uses

This doesn't provide any value for future proofing. If we want to support other sizing units (which I doubt we do), we can always just add this in the future.

  • I think we can help user with functionality to retrieve all available fonts on the system

Got a usecase in mind? Because I suspect being able to set a font fallback list (which we already support) is more than enough for 99% of the usecases.


interface Efl.Text.Format
It is not very easy to differentiate between Style and format, I understand this as property of textblock object it self, not the content.

These will indeed be renamed to make sense. Naming just follows what's already there (which is bad!).

  • @property valign : I this is already founded/conflict with efl.text.style property

I already mentioned somewhere that this will probably be removed and handled externally. At the very least it would be renamed.

  • @property visiblityMode: ` instead of password property user can user visiblity mode to control such features. (It may also replace multiline property too) VisiblityMode (Enum) like Normal,Password,HideContent,.. Etc Handle visibility of textblock content, where we can view it as password or normal text. (May be extend it with more options like PlainText, PasswordNoEcho, .. etc) `

I think I already mentioned it, but password will actually be moved around a bit (correction: it's literally the line after the one you quoted!). Not sure yet and if would even be available in the Format interface, probably not, so this is not really relevant anymore. Though just to give my opinion about such changes: I don't see why you'd merge multiline and password mode together like this. Sure, I guess that for most cases people don't want multiline password entries, but still, those are unrelated properties.

With that being said, having an enum for setting the password_mode could be useful so took a note of that.


interface Efl.Text.Style
From what I read from “interface Efl.Text.Format” this interface should be applied on Efl.Text.Content rather than Efl.Canvas.text Object

  • @property underline2_color
  • @property glow2_color
  • @property halign
  • @property valign how about use more clear naming for these properties

Sure, though as I said already in this thread. Naming is not near final at the moment. I'm just talking about structure...


class Efl.Canvas.Text

  • @property legacy_newline : Do we need this in new interface ?

Yes, please read more about it and you'll see why.

  • calculate_character_count : I think this can be calculated using TextBlock.Content.Text.Length

Not sure what you're referring to because there's no interface similar to what you reference. If you are talking about getting the content and then calculating the length: this is a very expensive way of doing such a common task and exactly why this property was initially created. I already had a comment about removing this though, and the reason is because it can be easily done by moving the cursor to the end and getting the cursor's position.

  • cursor_new : Does not Cursor constructor expect to be like: Cursor(Efl.Canvas.Text tc), so why do we need this ?

Again, like many of my comments above, this is something I already have a comment for on the line following the one you quoted.

  • @property Main_cursor: User can use this property directly to interact with TextBlock, without the need to create new cursor each time he interact with it, and save that curosr.

I don't see the value in this. Most interactions with non-interactive textblocks (this object) will be just setting the text once, so not actively manipulating it. That's why there's not really any value in adding it for this case.
For the interactive textblock case: in most cases you wouldn't want to have any such interactions that require a "main cursor" either. If you're doing annotations you'll want to have and save your own annotation cursors anyway. If you just want to interact with the main cursor, interactive textblocks have a concept of one, but it's the cursor the user sees, but again, I don't think you would.


class Efl.Text.Cursor

  • Does cursor Object have Text.Style? for example If I insert text using cursor, how to apply styles ?

I already addressed this multiple times. Annotation interface.

  • @property content

    1- Does this mean cluster before or after the cursor position (this could be dependant if text is RTL or LTR)

Cursors work on logical text, so it's the same for both RTL and LTR. Again, please familiarize yourself with the concepts before making comments. Anyhow, cursors point to a specific character position, and the character there is what content will return. As you see in my comments, I'm not yet sure if this should return the unicode char, or the whole cluster.

2- I think return single entity using this property is much simpler to implement, because with RTL/LTR text if we return pointer to content, it could mean rearrange text before return them.

As I said, you need to familiarize yourself with how these things work, because RTL/LTR don't matter when the text is in logical order (which it always is).

-@property geometry: Is it same as current interface ?,  what if user want to know current cursor position ? is it Rect/Point ?

Same as current other than the comments I already made about it. I'm not sure what you mean by "current cursor position" but either way, it's the same as what's there.

Just to repeat this again: I don't care about hypotheticals. If you want to make a suggestion for something that's missing, provide a usecase, don't say "what if".

  • Sometimes cluster replaces two unicodes points with totally new single glyph, and sometime cluster built using multiple unicode point glyphs, So deleting them is dependant on what type is this cluster ? look at D9628

I know how clusters work, but I'm still not sure what you're trying to say with this comment. "replaces two unicode points with totally new single glyph" -> I assume you mean totally different new unicode code point, like can be done in e.g. Hangul compared to just e.g. ligatures (or also can be done in hangul tbh). Though I still don't know what you're trying to say.


class Efl.Text.Markup

  • For Setting and Getting MarkupText on Efl.Canvas.Text, user can only use this functionality ? , or we will add properties to textblock to get/set markups ?

As I said above (you asked the same question before): there will probably be helper functions for this for textblock style markup.

  • Can we have more descriptive markup parsing functionality ( like get errors while parsing text) ?

No, for many reasons. You can implement a new parser for yourself if you want, externally (which has already been discussed numerous times). Though again, my repeating comment: why? what's the usecase?

  • Can we specify Restriction level, for example tags case insensitive, escape character case insensitive(for case insensitive ones)

No. Why make this configurable?? Just decide what you want and stick to it! We can either make them case insensitive, or most likely just make them case sensitive and only allow lower case.

  • Can we have Markup version? where user will specify markup version (use default), where it will simplify extending the language in future and keep legacy(old versions) to behave the same

No. We don't break backwards compatibility in the EFL, so a version won't add any value, as nothing will break anyway. If you want to extend, you can just extend. No need to version it.


Efl.Text.Raw_Editable extends Efl.Canvas.Text

  • Is this public class or internal class? How about Efl.Canvas.EditText?

Public probably. It's probably too low level for most people to use but still useful to have. It's not in the canvas, so this name is not good either.

  • Do you mean Efl.Canvas.Raw_Editablet (Efl.Canvas name space) ?

No.

  • I see this as widget not canvas. what do you think ?

It's somewhere in between.

  • Why user use this class instead of Efl.Ui.Text?

Users don't use this class. This is a lower level helper object. It doesn't support themes, it doesn't have any visual indicators and etc.

  • @property editable: How about Readonly? To not conflict with its name/purpose.

Not sure I like the name.

  • @property selection_allowed : How about Selectable or is_selectable.

As I said multiple times. Names are not final, I'm just asking about structure. Sure, this just copies what's already there.

  • @property selection_cursors: How about selection_range, it is (array of) pair of cursors

It returns a pair of cursors, not as an array. I'm OK with either, as I said, I don't care about naming at this point in time.

  • interface selection : where user specify properties like selection_background_color, selection_foreground_color, multible selection, .. etc

We've already discussed this at length over the phone. This is not how things are done in the efl. We control these from themes. If you want to change this core concept of the EFL, this is not the place to do it. First change everyhing else, and then I'll follow suit here.


Efl.Ui.Text extends Efl.Ui.Layout

  • Can user use Efl.Text.Raw_Editable functionality on efl.Ui.Text Object?

I think - implements: Efl.Text.Raw_Editable (as composite object) is pretty self explanatory.

  • DND mode, is it available ?

As I said, it's incomplete. So yes it'll be available same as a lot of other missing things. No need to comment on those 1 by 1.

tasn added a comment.Aug 26 2019, 6:07 AM

A reminder for future reviewers: I'm only asking for comments about structure (or things I asked about specifically). Not specific property names or other forms of bikeshedding. Those will be welcomed at a later stage, but now is not the time.

I think user normally will search for Widget/Canvas/View component in Efl.Canvas or Efl.UI namespaces.
So how he needs to look inside Efl.Text to find the Raw_Editable ?

tasn added a comment.Aug 26 2019, 8:04 AM

I think user normally will search for Widget/Canvas/View component in Efl.Canvas or Efl.UI namespaces.
So how he needs to look inside Efl.Text to find the Raw_Editable ?

As I said, the naming is not final. More specifically, I think this one has comments that I'm not sure where it will be. So yeah, I don't know yet, and now is not the time to bikeshed about this.

Furthermore, as I said, it's a low-level class that I doubt most people will touch, which makes the discoverability issue you pointed out more of a feature than a bug. :)

tasn added a comment.Aug 28 2019, 9:52 AM

The interfaces (WIP!) are now in my branch on efl.git: devs/tasn/ifaces. Feel free to take a look. I'm constantly updating that one.

tasn updated the task description. (Show Details)Aug 29 2019, 10:11 AM
tasn updated the task description. (Show Details)Aug 30 2019, 5:26 AM
tasn added a comment.Aug 30 2019, 7:43 AM

Reminder: I'm still looking for feedback! If I don't hear anything I'm going to start building from this on Monday.

I will add my comments at task level, I think it will be more simple to communicate.

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

But for example label should be lightweight widget but it is inherited from efl.ui.text and it does not (I think) use most of its features like select or insert, so it will not be lightwight in compare with efl_ui_text

So what do you think about ?

efl.ui.text (does not have interactive features, nor selection features)
efl.ui.textedit extend efl.ui.text (and have selection and insertion features) -contain all functinality from current efl.ui.text and efl.text.raw_edit
efl.ui.label extend efl.ui.text (lightwight widget no selection nor interactive)

So for Viewing only purposes user uses efl.ui.text, and for interactive purposes user users efl.ui.edittext.

tasn added a comment.Sep 2 2019, 9:29 AM

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 don't think it's a problem, and I don't think it's "that" feature rich. In terms of functions you can call on it: yeah, definitely. Though extra memory usage: not really. The nice thing about merging them is that you also get selection and cnp for free and no code duplication.
We could potentially split raw_editable to two objects, and make raw_editable inherit from the raw_selectable. Though then we would have to implement the CNP menu + general code twice, once in label and once in entry.

You can't unfortunately do it the other way around because raw_editable is a lower level object that's composited in.

But for example label should be lightweight widget but it is inherited from efl.ui.text and it does not (I think) use most of its features like select or insert, so it will not be lightwight in compare with efl_ui_text

Again, define lightweight. Are you talking about number of functions it has, or memory footprint?

So what do you think about ?

efl.ui.text (does not have interactive features, nor selection features)

You want label to be selectable (potentially). That's actually one of the most annoying things about many UI toolkits, that they don't let you enable selections on normal text! Heck, I'm going to make it selectable by default, so only block it if you don't want it.

efl.ui.textedit extend efl.ui.text (and have selection and insertion features) -contain all functinality from current efl.ui.text and efl.text.raw_edit
efl.ui.label extend efl.ui.text (lightwight widget no selection nor interactive)

So for Viewing only purposes user uses efl.ui.text, and for interactive purposes user users efl.ui.edittext.

Again, it can't be done sanely because of selection, which we do want on label. That's why I suggested this structure in the first place.

Please, if you still stand behind your suggestion, define what you mean by lightweight so I can address your specific concerns, thanks!

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

tasn added a comment.Sep 2 2019, 10:53 AM

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

I'd say this is negligible, and because we have less classes, memory is actually shared, so I'd say my suggestion is probably even cheaper on average.

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

As I said, selection is wanted there anyway, so isSelectable is going to be there. As for "isEditable", there aren't really such checks, you just disable editing and it just removes the callbacks that are used to hook on key input, so there aren't really extra checks. At least nowhere meaningful. And anyhow, really, I don't think anyone cares about a few extra checks when processing user input on a non-editable widget...

3- Less initialization processing/time

The editable = false is set in the label's constructor so it will actually do it *before* setting up the editable part of the widget, so I doubt this would make an impact.

In summary: the only thing that could be an issue is memory usage, but I'm very much doubtful it would make a significant different. If it does end up making a difference, we can just take the editable parts of the private data, and move them to a separate data structure that's only allocated if the object is editable. We do this in eo_base too.

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.

2- Why user will expect label to be selectable ? Many toolkit uses label to show text not to interact with it, Like using it to describe field in applications like (UserName : [Edit Text Object])

3- How is label extend efl.ui.text (I mean logical meaning of extend), it is actually try to disable some of efl.ui.text functionality (Edit part), So it did not needed it in the first place, why does it exist, (efl.UI.Text is more feature extended than label).

tasn added a comment.Sep 3 2019, 12:59 AM

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.

Yeah, with a label in a very long list it could have potentially been a problem, but genlist recycles items, or at least should. So there are actually not that many objects. But you are right, the only way is to measure.

2- Why user will expect label to be selectable ? Many toolkit uses label to show text not to interact with it, Like using it to describe field in applications like (UserName : [Edit Text Object])

Sure, that shouldn't be selectable. But it's also used to show e.g. error messages. Emails. WhatsApp messages. And in general, massive walls of texts. I don't have any good examples to point to at the moment, but the amount of times I hit a non-selectable label that I wish was is much much higher than 0.

3- How is label extend efl.ui.text (I mean logical meaning of extend), it is actually try to disable some of efl.ui.text functionality (Edit part), So it did not needed it in the first place, why does it exist, (efl.UI.Text is more feature extended than label).

Yes, this is ugly in the sense that the reason it's like that is an implementation detail. As I said, I don't like this structure, but it's significantly easier to implement it this way, which is why it was suggested. I'm happy with inverting it, but implementation is going to be a pain. I don't know if being slightly cleaner is worth all the hassle.

tasn added a comment.Sep 3 2019, 8:40 AM

Important to mention: I'm already implementing a new text object, cursor and annotations based on this proposal. If you have any comments, NOW is the time. :)

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

tasn added a comment.Sep 4 2019, 1:43 AM

Here is probably best. Git is going to be rewritten and changed a lot as we go, and Phab doesn't have a nice PR interface so I can't just open a PR and have you comment there unfortunately. :(

ali.alzyod added a comment.EditedSep 4 2019, 1:46 AM

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

tasn added a comment.Sep 4 2019, 2:04 AM

Documentation: nothing to discuss there. It's missing, that's not an oversight.
Missing functionality: just add here, though better yet, it could be discussed in T8191 as you uncover usecases that you can't fulfill with the current API.

I'm sorry, but I can't handle so many subtasks. This split is already proving a lot to me, if you continue on creating subtasks I'll be completely lost.

Let's start by discussing here (other than documentation and missing functionality which I touched on above) and if it's too much we can see how we can split it.

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

I like to do something like

return efl_text_attribute_factory_ref(efl_text_attribute_factory_insert(factory,c1,c2));

tasn added a comment.EditedSep 4 2019, 5:27 AM

Ha, I had a feeling something there is wrong, and had a comment to fix ref/unref to be like Eo. That's what I was missing, thanks!
Will only add it to ref. You don't want it in the case of unref because you don't hold the reference anymore.

Edit: fixed, thanks again!

ali.alzyod added a comment.EditedSep 4 2019, 7:20 AM

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

tasn added a comment.Sep 4 2019, 7:34 AM

You just set the selection cursors to whatever you want. Wasn't it the same before too? I honestly don't remmember.

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

Cursor

  • Cursor_up/Cursor_Down
  • Cursor_is_format_get/Cursor_is_visible_format_get

Filters

  • accept_set
  • limit set
  • append/remove/prepend

File

  • Format_set
  • File_Save
  • Autosave set/get

Markup

  • Markup_insert

Events

  • MaxLength,reached
  • text,set,done
  • activiated
  • anchor_clicked

Selection

  • selection_begin/selection_end I am not sure if selection_cursors_get do same job
  • select_all
  • selection_region_set I am not sure if selection_cursors_get do same job

Context Menu

  • item_icon_get
  • item_label_get

prediction

  • hint_set
  • hint_hash_set/del

imf

  • context_get/reset

style

  • user_pop/push/peek

icon

  • icon_visible_set
  • end visible**
    • end_visible_set

Anchor

  • hover_end
  • hover_parent_set/get
  • hover_style_set/get

Others

  • textblock_get

Item Provider

  • provider_append/prepend/remove

Label

  • wrap_width_get/set
  • slide_duration_set/get
  • slide_slide_get/go/set
  • slide_mode_get/set
  • slide_speed_get/set
tasn added a comment.Sep 5 2019, 1:57 AM

Thanks for your comment! The list includes a few useful functions that have indeed been left out, though also a few functions that are either implemented differently, unified they way they are done (before had two ways of doing it, now there's one) or things that have already been addressed either here or in comments. Please next time try to provide more info rather than just giving a simple list.

Comments below:

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

Cursor

  • Cursor_up/Cursor_Down

It's line_jump_by, though I could potentially remove it though and change it to cursor_up/down. Don't think it's been ever used with values other than 1/-1. Thoughts?

  • Cursor_is_format_get/Cursor_is_visible_format_get

There's a comment about it.

Filters

  • accept_set
  • limit set
  • append/remove/prepend

I don't remember from the top of my head what these functions do, but filters are now implemented as part of callbacks, or at least this is the plan, so I think they are not needed. However, this is something we will find out when doing T8191 and is exactly why this task is there. So we can find real holes with real usecases, rather than missing bad functions.

File

  • Format_set
  • File_Save
  • Autosave set/get

Haven't touched these yet, because I'm still on the fence. Load from file is already implemented, and I don't know if save directly from ui_text is something we want. As for format: that also needs to be figured out. Should it just be part of the markup interface, as it's now implemented elsewhere.

Markup

  • Markup_insert

Not sure what this is meant to be, because there is a markup_insert in the markup interface and we talked about this at length.

Events

  • MaxLength,reached

This limitation will come from a validator, so will just be part of that mechanism.

  • text,set,done

Fair point, this one was left out. It was there for progressive loading. Please remember this one.

  • activiated

Removed on purpose.

  • anchor_clicked

Anchors are not yet handled, I think I mentioned it in the comments.

Selection

  • selection_begin/selection_end I am not sure if selection_cursors_get do same job

So please don't just put things here without at least trying to read the docs...

selection_begin/end are emulating the start and end of a selection. They are actually needed and weren't in raw_edit (one of them was in ui_text). Fixed now.

  • select_all

Didn't see it was there, but it can be easily implemented and was therefore removed.

  • selection_region_set I am not sure if selection_cursors_get do same job

I tried grepping through the code and didn't see it. Where is it? Sounds like selection_cursors_get though.

Context Menu

  • item_icon_get
  • item_label_get

There's a comment about this not being handled yet.

prediction

  • hint_set
  • hint_hash_set/del

I think it's there, but there are comments about this not being handled yet.

imf

  • context_get/reset

I think it's there, but there are comments about this not being handled yet.

style

  • user_pop/push/peek

There's a comment about this. I'm still not sure about the style mechanism.

icon

  • icon_visible_set

Not sure, will probably be an efl_part interface.

  • end visible**
    • end_visible_set

Not sure, will probably be an efl_part interface.

Anchor

  • hover_end
  • hover_parent_set/get
  • hover_style_set/get

There's a comment about this not being handled yet.

Others

  • textblock_get

This is not needed due to composite objects and the fact that it's not in edje.

Item Provider

  • provider_append/prepend/remove

This is completely revamped and handled with the new item provider (and markup) mechanism.

Label

  • wrap_width_get/set
  • slide_duration_set/get
  • slide_slide_get/go/set
  • slide_mode_get/set
  • slide_speed_get/set

Label hasn't really been implemented yet, it's just a stub.

tasn added a comment.Sep 6 2019, 5:56 AM

Btw, I already mentioned it and chased a few times on IRC, but: T8184 is holding me back. If anyone has comments for that, please make them. :)

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

ali.alzyod added a comment.EditedSep 9 2019, 6:12 AM

@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

  • If the user set the background color, why does he need to enable background too? No easy to figure out, needs more coding
  • What off mean, solid default color or fully transparent color?

2
Regard the context menu (function split in two classes Raw and UI.text):
1- Events like (context,open: void;) will be available for efl.ui.text users ?
2- I think there will be important events/functions too, like:

a- I think user will need event like (context,preopen: void;), where user can prepare the menu before showing it.
b- Can  user open context menu programmatically?
c- Can user specify context menu location?
d- If we add MagnifyGlass, how user can configure MagnifyGlass or Context Menu on longpress event ?

3
cursor,changed,manual: void; Called on manual cursor change
What does manual mean here? I mean as a user what I expect it means?

tasn added a comment.Sep 9 2019, 7:02 AM

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

I don't know if it ads complexity, I'd need to figure it out, but maybe a good idea would be to use this interface, and have the efl_part interface for setting/getting the colour of the background and etc.

So you'd do: efl_gfx_color_code_set(efl_part_get(attr_factory, "background"), "#RRGGBBAA") for example to set the background color.

tasn added a comment.Sep 9 2019, 7:13 AM

@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

  • If the user set the background color, why does he need to enable background too? No easy to figure out, needs more coding

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.

  • What off mean, solid default color or fully transparent color?

Now you're just being difficult on purpose! :)
Come one, background/strikethrough off, obviously means nothing is drawn, and not "draw a random default value".

2
Regard the context menu (function split in two classes Raw and UI.text):
1- Events like (context,open: void;) will be available for efl.ui.text users ?
2- I think there will be important events/functions too, like:

a- I think user will need event like (context,preopen: void;), where user can prepare the menu before showing it.
b- Can  user open context menu programmatically?
c- Can user specify context menu location?
d- If we add MagnifyGlass, how user can configure MagnifyGlass or Context Menu on longpress event ?

This is exactly why we want to do the examples in T8191, we want to make sure we serve all the wanted cases ad make them possible. These two points are good example for that. I was trying to trim things, so haven't taken absolutely everything back in yet (especially when it comes to events in elm), this is our opportunity to add those and exactly why I want that feedback.

3
cursor,changed,manual: void; Called on manual cursor change
What does manual mean here? I mean as a user what I expect it means?

This is a leftover prefixed with "FIXME review:". I don't remember what it was meant to do, which is exactly why I want to review it again. I forgot since my initial pass, and I don't remember what it was used for.

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

ali.alzyod added a comment.EditedSep 9 2019, 8:09 AM

@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

tasn added a comment.Sep 9 2019, 11:17 AM

I moved them to raw_editable on purpose. What's in the .eo files I created is correct (at least until we find a reason why not).

It's a combination of starting to address T1049, and the fact that really, all of this logic doesn't belong there, and it was creating a lot of annoying conditions. For example, IMF could have access to this data, so it needs to be blocked before. What about copy and paste? Etc. So it's better to just make the canvas unaware of it, and have the layers that are aware of it, take care of all the iffy parts.
It's fairly easy to implement using the same mechanism as undo/redo and filters.

@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

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

Now cursor becomes an object, what do you think we are going to do with them ?

@tasn @woohyun
D10542
Cursor Diff ready for review

D10607
Canvas_text style property