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.

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

In T8151#140383, @bu5hm4n wrote:

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

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.

I'm still jumping back and forth on this one. It's just so useful for text cursors.

In T8151#140720, @ali.alzyod wrote:

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

In T8151#140546, @raster wrote:

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?

In T8151#140713, @bu5hm4n wrote:

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)

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.

In T8151#140567, @ali.alzyod wrote:

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.

In T8151#140553, @ali.alzyod wrote:

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

Even though I sat on this for a few days before posting it here, I'm now not sure if we want to encourage this "out of eo" behaviour. So I'm closing it for now, but at least we have it for posterity.

One more comment actually: it's problematic when it comes to sharing interfaces. So you can no longer have shared interfaces when you use this (same problem as @static), which kinda sucks. That's what's nice about the factory pattern.

In T8151#140563, @ali.alzyod wrote:

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 ?

In T8151#140544, @ali.alzyod wrote:

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

What post ?

In T8151#140542, @ali.alzyod wrote:

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?

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.

In D9628#179153, @woohyun wrote:

In D9628#178653, @tasn wrote:

I haven't looked at the actual code, but I do plan on making textblock2 work on grapheme clusters too, so this is inline with that change.
Though maybe I'd wait with this until TB2 is in, hopefully in a few weeks?

@tasn
This one is for application bugs with legacy APIs, so - I'm wondering whether your plan with TB2 will effect legacy applications or not.
If not, I think this kinds of patch is necessary.

In T8151#140423, @ali.alzyod wrote:

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

In T8151#140422, @ali.alzyod wrote:

+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 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 T8151#140417, @ali.alzyod wrote:

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

Not sure what's the real definition of usecase, but when I say it, I mean a case of what a real user *wants* to do, not just can potentially do.

This is not a usecase, this is what you are trying to do. Why are you trying to do? Could you explain? If you got input from the user, then it was entered in a textblock, so you already have a textblock involved, so this usecase doesn't apply. Caching them: you can cache the markup with the current code, what we are talking about is modifying the markup directly, so this is also not a usecase.

In T8151#140403, @ali.alzyod wrote:

Now things are more clear.

My Idea is having Markup Object, were you can :
1- Assign cursors
2- Create and manipulate Markup text, away from TextBlock.

In T8151#140400, @ali.alzyod wrote:

I do not get the difference between Annotations and Markup Object.
Why do not we make annoations work on Markup Object, instead of working on TextBlock.

Annoation only manipulate Markup, So why do not we make it work on Markup text.

In T8151#140395, @woohyun wrote:

Some questions while checking the description of this task.

Efl.Text.Item.Factory
Almost identical to Annotation but used to insert items rather than annotations.

This one would have the same way with "Anntation Factory" to be inserted in text object. Am I right?

I said "the same interfaces (so functions)", in the markup text it would look something like:

an_factory = Efl.Text.Markup.Annotation.Factory()
an_factory->weight_set(BOLD)
an_factory->insert(eina_str_buf, 5, 10)

In T8151#140391, @woohyun wrote:

@tasn
You are so fast ! You added reply just after I deleted my comment !! HAHA. (I needed more time to arrange my idea)
Anyway thanks for the reply.

In T8151#140387, @ali.alzyod wrote:

First lets forget about Documnet and Manager, I think it will complicate things on this stage.

For cursors:
I think this is dependant on style of coding :), (this is just my thoughts)

From exposed API view, enum is much easy, you add one line only containing name of enum.
From user perspective, using one function, and read documentation from enum is much simpler.

In T8151#140388, @woohyun wrote:

I'm wondering two things -

1. whether cursor is necessary
2. how about supporting annotation_set from text object
   
   For exmaple,
   
   ` an_fatctory = Efl.Text.Annotation.Factory() an_factory->weight_set(BOLD) tb1.annotation_set(an_factory, 1, 4); tb2.annotation_set(an_factory, 3, 5); // if want to share the same annotation
   
   `
   
   Many developers have not understood well why cursor_object was needed.

In T8151#140383, @bu5hm4n wrote:

(Bare with me, i was never in touch with text)

1. There is T1049 (and in entrance the password mode is implemented without elm_entry) What do you think of not having the password at the canvas layer, and only have it in the efl.ui. object ? and only have it there in one field, so its never passed to the theme etc.

I think I understand our misalignment here. It's just about terminology (and therefore location of things). I'm not against Efl.Document and Layout manager, but I think having them in textblock is out of scope. Your examples also seem to imply the same, look below:

OK, let's try the quoting context thing. :)

Another note: I can already see how it's going to be very difficult to keep track of comments and discussion if we do it here in phab. The discussion has already diverged (@cedric and @ali.alzyod asked about different things), should me move it to edevelop? Or do you fellas prefer keeping it here?

Thanks @zmike! Rest of you: I'll answer tomorrow. :)

I haven't looked at the actual code, but I do plan on making textblock2 work on grapheme clusters too, so this is inline with that change.
Though maybe I'd wait with this until TB2 is in, hopefully in a few weeks?

Thanks for your comments, my reply is inline:

As it says, this is my current proposal. I'll update it in the next few days with more interfaces, but this is the base textblock part.
I included my own personal notes so you can comment on them too. Please let me know your thoughts about the general design, specific functions or anything else you have in mind.

@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.

Mostly done in rEFL8a8a833837f7217aea0a33f4f7afbb6edfb103c4 (thanks @q66!), still missing the stuff from the previous comment though.

Thanks @q66, fixed in rEFL8a8a833837f7217aea0a33f4f7afbb6edfb103c4

It looks like it was agreed in T7675 to call this @static. @q66 is doing the rename, but just a few things that are missing and should be implemented (copied from the other ticket):

If it's indeed unused and was never released, it seems fine to me to remove it. It looks like it was just a copy-paste from the old object that wasn't removed.

That's one of the suggestions I made above. I'm fine with that too, though that's a different discussion.

It's adding back @class and then adding @static that is just like what @class is now. OK, thanks for the feedback!

Gotcha, good to know. Then @static is maybe the best option for T8118. @q66, anything to contribute regarding the syntax suggestions?

The idea of replacing one by the other won't solve what I described because like all global functions of such sort, you can have only one. Again, what happens when you have libefl-markdown.so that wants to offer markdown and libefll-html.so that wants to offer html? They can't both replace the textblock object globally.

Do you mean the Text_Factory classes? I'm wondering what would be the case for them to have actual @class dynamicity.

I updated the example to use an interface instead of a class to make it more clear.
I'll also elaborate on my markdown example so it's even more clear (though I thought I was).

@lauromoura: I think I already addressed your comment too in my reply to @felipealmeida , please let me know if that's not the case.

By size I mean typing more. I'm not against it per se, but for static use it doesn't look like a good tradeoff to me. This is going to uglify bindings and I don't really see much of a difference in change the name of the method or pass a different type. It actually creates one more point for error, where people can pass wrong classes, they can't when the class is embed in the function name.

Do we have a use case? Features are nice, but I think they must be justifiable.

The problem is with singletons/factories + inheritance, as implied from the context of this discussion.

Marcel, I keep in repeating myself. I already addressed what you just wrote numerous times like at the last paragraph of: https://phab.enlightenment.org/T7675#139789
Even with non-class functions, C functions can't access overridden functions in C# (or if they can there, not in all bindings), and if there's a way to make it work, then there will also be a way to make it work with overrides not just overwrites.

Yeah, I understand that new means override (now that we have discussed it further), but as I said, in my last comment and previous ones, it doesn't matter, because this logic is handled by C anyway. The same scenario you just described would break even with non-class functions because the C code will not call your C# code. So I don't see why the obsession with this specific case of class functions when the same functionality is overall broken.

Thanks for adding the clarifications, though this is something I already addressed at the bottom of: https://phab.enlightenment.org/T7675#139789

And also you haven't addressed the other point, which is even if you were right about this point, these shouldn't live in the class but rather in a related namespace.

Read what I said at the bottom of the last post. It doesn't matter because everything is done in C anyway. You don't get the behaviour you're describing in normal non-class functions either. It always behaves like overloading because it calls C directly under the hood, doesn't actually use the language's object system.

Actually, now I'm really pissed off you are wasting my times and spreading false information, here's a fucking C# example:

using System;
					
public class Program
{
	public class A {
		public static void foo() {
			Console.WriteLine("A");
		}
	}
	
	public class B : A {
		public new static void foo() {
			Console.WriteLine("B");
		}
	}

Stop trying to twist my words and start reading them. I never fucking said ask Tom for changes in eo. I said, when you fundamentally change existing code, ask the people who wrote it why it was the way it was. Not just me, not just Eo. I talked to raster a lot when I redid the text system way back when, I talked to everyone a lot when I did the object system, I talked to cedric when I touched the relevant edje parts. It's just common sense to ask people who actually know the code why things that you find weird are done the way they were. I don't understand why you keep on trying to ridicule this statement. It's obvious and should be the basis to everything you do.

I didn't say you have social problems, I was complaining exactly like the above. I said the big issue with this change is the broken process (which is a social aspect, not technical) that lead to you changing a massive piece of code without asking *anyone* that's been involved in it's creation and design when I'm on IRC, mail and read the ML. The only one of the "reviewers" that actually maybe was involved is q66, but he said he wasn't asked to review any proposals (as evident by this ticket and lack of participation) but rather to review the code. It's not about me, I just don't understand why you'd make such a big change without first gathering information.

I just finished a big damn rant on IRC about this. Honestly, did it not occur to you to ASK why things were done this way? I'm on IRC every day. I still have my email address. No one asked. This was talked about so many times. Argued back and forth. It was set the way it was set for a reason.
No, C# not supporting class function overrides is not an excuse. It's something we discussed, anticipated and had solutions for already in 2014.
As I said on IRC: C doesn't have classes, should we just drop classes then? Python doesn't have types, why not drop types?
This is absolutely mental that you went on with this without at least asking! I'm not saying you made the wrong decision here (though I believe you are), I just find it crazy that you'd change something so fundamental without asking the people who worked on it for literally years. I didn't get a single email or a single text. Never mind the lack of respect for other's people work. It's just stupid and wasteful to keep on rewriting other people's work without first asking.

Sorry for not replying earlier, I completely missed this one, as I'm not very active on phab.

Just a couple of thoughts:
We already did Edinburgh and Paris recently.
Edinburgh and London are fairly expensive (even with the recent currency devaluation).

Nice catch. :)

There have been a few fixes, we are now at:
00007f661ecea000 116K r---- libelementary.so.1.18.99
00007f661ed07000 32K rw--- libelementary.so.1.18.99

This should be OK now. Is it?

Yes, I think we should go with the second option. Option 1 feels wrong. It's not the poor app's fault that the system is broken. We need to help it.

Thanks, your second (redacted) log and analysis is very helpful. I'll only be able to take a look next week (hopefully), but this would really help, and more so, it's probably very simple to fix.

On the phone/desktop you don't see terminal output when you run an application, you will never see this error as a user of an application. Furthermore, in some cases it can't be done at all (font embedded in the theme, or a specific file). There is no nice graceful way of printing an error from our side. Applications could potentially check and report the lack of fonts, but that's out of scope for us as the GUI toolkit. If you want absolute correct results as an app, deal with it an error, otherwise, we owe it to applications to do the right thing. There is no spec anywhere saying that fonts should come with bold variants, so "runtime embolden" should be considered as a reasonable alternative. More so, it actually is. I doubt fonts will be too screwed.

Yes, using a good font that was designed this way is best. However, such a font is not always available so we try to do our best in accommodating the programmer's request, so we make fonts bold on runtime. It's a fallback to a missing font.