Page MenuHomePhabricator

RFC: changing back style/attribute handling to format strings rather than an interface
Closed, ResolvedPublic

Description

In order to start stabilizing the text interface I've been asking for feedback and reviewing all of the interfaces again myself. As part of this work, I realised just how much more complex things are because of the interfaces for setting text style, rather than strings.

So essentially what I'm proposing is removing the attribute factory and going back to functions on the textblock to add an attribute from string.

A bit of background

Textblock has always used strings for both style and formats (and then attributes). Sometime in the last year interfaces were added to set the font_size, font_weight and etc through code. I kept these because I thought the concept was nice and it would make things easier. In retrospect, this was a mistake. It actually makes things much harder and more complex.

Comparison of Interfaces vs Strings for manipulating formats.

Here are the pros and cons of using the interfaces vs using the strings. These are all the ones I managed to come up with, please let me know if you think I missed anything.

IMPORTANT: I think the main thing is that most people will use *markup* rather than any of these functions to manipulate text style anyway, so given that this is such a niche behaviour, I don't see the point adding all of this complexity.

Pros

Discoverability

With the factory method, we will have code completion for the allowed style functions, so it would be easier for developers to discover what functions are allowed and their allowed values.

Find errors at compile time

Because the compiler will be making the validation, we will find errors sooner. In the string case we will only have runtime error checking.

Cons

Much much more complex

To support this we need to add two new interfaces (Style and Font properties) with a lot of properties on them, and will need to implement them all.

We also need to implement gradual implementation of style properties rather than all at once.
So for example, with the interfaces it would be:

efl_text_attribute_factory_clear()
efl_text_font_family_set(factory, "Sans")
efl_text_font_size_set(factory, 12)
efl_text_style_background_color_set(factory, color)
efl_text_attribute_factory_insert(cur1, cur2, factory)

And the factory will have to understand and implement internally setting them one by one (which is more costly), while the string case will only have:

efl_canvas_text_attribute_insert(cur1, cur2, "font_family=Sans font_size=12, background_color=color")

And requires no special handling for partial setting, because the string is only parsed once for each attribute.

It also necessitates implementing a much more involved way of parsing markup, because the parser would need to parse attributes on its own and translate to these calls, rather than just passing the attribute string as is.

Redundant

Because we set the style from the theme anyway, we need to have parsing of format styles from string *anyway*. So we end up having it both in the markup class, and in the theme loader in addition to the functions. Instead of just having the style string parser once in the text object.

Less extensible/flexile

Can't all of a sudden add a unit to size, or more values to a boolean.

So for example, if we want to add a way to sent the font size as a multiple of the current font size, to implement a tag such as <small> which just makes the text 80% the size of the enclosing tag, you can't. You'd need to add a new function called efl_text_font_size_factor_set because the original doesn't accept a unit, and even if it did, it accepts an int and not a double.

Another example is that HTML supports 3 special values for each property: inherit, initial and unset. We can't sanely support anything like them with the interface based API.

In summary, I'm suggesting going back to how Textblock used to be when it comes to styles. The pros massively outweigh the cons. Am I wrong? Would love to hear. Thanks!

tasn created this task.Oct 2 2019, 1:29 AM
tasn updated the task description. (Show Details)

Your argument is very convincing. Doing the parsing and checks at runtime will always be more flexible, that's for sure. I prefer this option, but I am no expert.
I just wanted to point out that the string approach requires having good docs, and keeping them up to date.

ali.alzyod added a comment.EditedOct 2 2019, 1:57 AM

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

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

(2) Setting style at the attribute level (content).

  • Here I can see your point more clear because maybe paragraph is inherited from another paragraph.
  • But most of the time user will set the all string as markup text, and internally we can figure out font/scale/inherit/initial as part of MarkupText Model.
tasn added a comment.Oct 2 2019, 2:03 AM

Your argument is very convincing. Doing the parsing and checks at runtime will always be more flexible, that's for sure. I prefer this option, but I am no expert.
I just wanted to point out that the string approach requires having good docs, and keeping them up to date.

That's for sure. :)

Something like (or better than): https://developer.gnome.org/pygtk/stable/pango-markup-language.html

tasn added a comment.Oct 2 2019, 2:09 AM

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

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

This comes down again to what we talked about before. In the EFL you're discouraged from changing an object's style directly, and should go through the theme. So this is not how things are done in the EFL. I'm not agreeing or disagreeing with it, just stating and following.

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

I'll also rename things to be more like CSS so people can just use what they expect.

You're suggesting adding a lot of work, code and functions (including having two ways of doing the same thing) just for the convenience of being able to set the font size with a function. An action that's discouraged in efl-land.

(2) Setting style at the attribute level (content).

  • Here I can see your point more clear because maybe paragraph is inherited from another paragraph.
  • But most of the time user will set the all string as markup text, and internally we can figure out font/scale/inherit/initial as part of MarkupText Model.

You can't.

Consider the following markup: "My name is <span font_size=150%>Tom</span>".
You, as the app developer have no control or idea about the theme used on the object, so you can't calculate the scale on your own.

woohyun added a comment.EditedOct 2 2019, 2:17 AM

I agree with @ali.alzyod based on my experiences with Tizen developers.

In Tizen, many developers had complained about "style_set" with string because of its inconvenience.

For example, it's difficult to check the default value for each property.
Developers need to do style_get - and need to do parsing the style_string by their own for this work.
(There are hundreds of codes for this parsing in Tizen applications)

Especially, in new EFL# (or other language bindings), style_property way would be much powerful than style_string because of its convenience.

Interface works have focused on the goal of "easy to use".
So, IMHO, style_property way is very necessary one to be supported.

tasn added a comment.EditedOct 2 2019, 2:20 AM

Why do they want to know the default values? I think this is what really needs addressing...

Also, just to clarify again: it's not different than HTML, CSS and Qt, are they claiming those are too hard for them?

woohyun added a comment.EditedOct 2 2019, 2:28 AM

It's up to the application scenario.

For example, there is a phone application.
As you can see in your mobile phone, the font_size needs to be decreased when the number of input meets the limit.

Then, with current EFL, application can do something like -

  1. get the current font_size from the current style_string
  2. and evaluate the next font size
  3. re-create the whole string with new font_size
  4. and set the new style_string

This can be done with -

  1. get_font_size
  2. evaluate the next font size
  3. set_font_size

I know there is a tradeoff between "style_text" and "style_property".
But, I don't want to make developers study about "style_text" anymore.
They need to know how to create that whole style_string just for changing "font_size".

This property is supported by Android -
and if my study is correct QTextEdit also supports this.

tasn added a comment.Oct 2 2019, 2:49 AM

The scenario your describing is exactly what I'm talking about with supporting size factor! You can then just decrease the font size in % rather than points.

Though specifically in this case: why are they not using the native "text fit" which automatically resizes the text to fit the space?

Got any more example scenarios by any chance?

Instead of font_size, if font_color needs to be changed, then what could be the answer ?

I don't want to get the best implementation way for each application case.

The important thing is that Tizen developers (may be the biggest number of users of EFL) had complained about it a lot.

Plus, we need to think about why other big platforms (such as Andorid and QT) are supporting those properties separately.

(And I'm not convinced well why you talked about HTML and CSS,
Can they support style_properties if they want ? If my understanding is correct, there is no API in those markup language world.)

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

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

Consider the following markup: "My name is <span font_size=150%>Tom</span>".
You, as the app developer have no control or idea about the theme used on the object, so you can't calculate the scale on your own.

I can calculate them on run time, while lay-outing

tasn added a comment.Oct 2 2019, 3:21 AM

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

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

Consider the following markup: "My name is <span font_size=150%>Tom</span>".
You, as the app developer have no control or idea about the theme used on the object, so you can't calculate the scale on your own.

I can calculate them on run time, while lay-outing

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

Just to clarify, I was suggesting this markup to be supported and textblock to automatically calculate it, so the user need not know the actual size.

tasn added a comment.Oct 2 2019, 3:30 AM

Instead of font_size, if font_color needs to be changed, then what could be the answer ?

Same one: why do they actually need it? I'd say they probably want colour to know if it's dark mode or light mode. So just have a theme setting that says that. I don't think trying to guess the values is the correct course of action.

Regardless of this, what they are doing (analysing the style) is wrong. You can have multiple styles on the object and they should all be analysed if this approach is taken. This is the same for both the string and the property way of doing it.

I don't want to get the best implementation way for each application case.

Maybe I misunderstood what you're saying, so I'll try to rephrase what I understood:

You're saying you don't want applications to do things correctly but instead enable them to do whatever they want to achieve a close-enough solution? So give them as many ways as possible to do things so they can just choose their own?

The important thing is that Tizen developers (may be the biggest number of users of EFL) had complained about it a lot.

Again, this is above me. You should take it up with @raster / community. The efl was not designed for people to go willy-nilly change colours of things. You should be using themes. Maybe you disagree with it (I'm not taking a stance), but that's how it is, for better or worse. :|

Plus, we need to think about why other big platforms (such as Andorid and QT) are supporting those properties separately.

Legacy most likely. A major platform not having it (HTML) is a much stronger indication than a major platform that has both (where one could just be legacy).

(And I'm not convinced well why you talked about HTML and CSS,

Can they support style_properties if they want ? If my understanding is correct, there  is no API in those markup language world.)

Yes they can, and they haven't created it!

At the moment for example you could do in html: <span style="font-size: 12; font-weight: bold">.
They could have added support for <span font_size=12 font_weight=bold> if they wanted to have direct access.
Same thing with JavaScript, they could have added a way to directly set the font size, but instead you just set the style of the object.
So in JS it would be something like (sorry I don't remember exactly): span.style = "font-size: 12; font-weight=bold"; rather than: span.font_size = 12; span.font_weight = "bold";.

ali.alzyod added a comment.EditedOct 2 2019, 3:36 AM

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

Just to clarify, I was suggesting this markup to be supported and textblock to automatically calculate it, so the user need not know the actual size.

Adding such feature to markup is great, but for actual widget it is hard to use

Again you are talking about HTML as programming language, HTML is Markup and should be compared to our Markup text, and again for markup your suggestion is true, you need to compare us with Javascript and DOM
document.getElementById("myP").style.fontSize = "30px"

Other point:
Also suppose user what to get font_size from ui_text, it is very hard for him, he needs to parse all the style string to read this value

tasn added a comment.Oct 2 2019, 3:50 AM

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

Just to clarify, I was suggesting this markup to be supported and textblock to automatically calculate it, so the user need not know the actual size.

Adding such feature to markup is great, but for actual widget it is hard to use

Again you are talking about HTML as programming language, HTML is Markup and should be compared to our Markup text, and again for markup your suggestion is true, you need to compare us with Javascript and DOM
document.getElementById("myP").style.fontSize = "30px"

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

Other point:
Also suppose user what to get font_size from ui_text, it is very hard for him, he needs to parse all the style string to read this value

We talked about these kind of statements before. It's like saying "suppose the user wants to get the diameter, in pixels of the inside of letter o, it's very hard for them". Just saying something is hard doesn't mean anything if it's not something people *should* be doing.
I don't understand why people would want to do this unless they are doing something wrong.

To build on this, how would you achieve this in JavaScript? Qt? Android (maybe this one is fine if it doesn't have propagation of sizing), because this is the bar you're setting for us.

This wouldn't work not now and not anytime, as I said. You can have multiple styles, so they would need to analyse all of the styles and merge them correctly. It'll never be a simple matter of just getting the font size.

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

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

We talked about these kind of statements before. It's like saying "suppose the user wants to get the diameter, in pixels of the inside of letter o, it's very hard for them". Just saying something is hard doesn't mean anything if it's not something people *should* be doing.

You make it sound very complicated request from the user, and it is not, it is a very basic request, the user just wants to read the font_Size/color of the widget.
Why does he need it?
Maybe to change font_Size/font_color for other widget depend on other widget font size/font color ? or font_color of other widgets

tasn added a comment.Oct 2 2019, 4:12 AM

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

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

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

We talked about these kind of statements before. It's like saying "suppose the user wants to get the diameter, in pixels of the inside of letter o, it's very hard for them". Just saying something is hard doesn't mean anything if it's not something people *should* be doing.

You make it sound very complicated request from the user, and it is not, it is a very basic request, the user just wants to read the font_Size/color of the widget.
Why does he need it?
Maybe to change font_Size/font_color for other widget depend on other widget font size/font color ? or font_color of other widgets

Again, WHY?!
We shouldn't be just letting people do whatever they think they want to do. We shouldn't enable bad behaviour.

Example scenario. Assume there's currently no way to get the font size but there's a way to set font size to 200%.

A user wants to make the text of a widget double the size of all other widgets. Thinking how to solve it, they come up with the genius idea of getting the default font size, multiplying by 2, and then setting that.
They then see they can't get the font size, so they came to you and ask: "hey, could you please add a way to get the font size? I need it."

The correct answer here is not: "sure, let me add it for you". The correct answer is "why?". To which that user would say: "I want to make it double the size". To which you will reply: "ah, just use font_size=200%".

This example illustrates that you should always ask the why that drives use requests and not just give them what they are asking for. Because users usually ask the wrong questions. They usually come up with a solution and ask how to implement it, rather than asking what they really want to do.

I'm not saying that getting the font-size is not useful (though I'm pretty sure it isn't), I'm just saying that your reasoning is not convincing.

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

Again they have font properties and we have font properties.

Important user cases:
1- How to change font size alone for widget?
You need to get the old style to parse it and change font_size part of the string right?! this is complicated, not easy

You may suggest appending to the end of string style font_size with new value? this is very bad, you are creating useless parts of style without good reason, (int rich text editor this is hell)

tasn added a comment.Oct 2 2019, 4:35 AM

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

Again they have font properties and we have font properties.

Important user cases:
1- How to change font size alone for widget?
You need to get the old style to parse it and change font_size part of the string right?! this is complicated, not easy

You may suggest appending to the end of string style font_size with new value? this is very bad, you are creating useless parts of style without good reason, (int rich text editor this is hell)

I don't think I follow your use case. So I'm creating a rich text editor and I want to change the editor's font size? This is very easy and has been done forever and is there in ecrire.

evas_object_textblock_style_user_push(tb, "font_size=20"); // I simplified it a bit for the example, but you can look at ecrice for the full one

woohyun added a comment.EditedOct 2 2019, 5:02 AM

@tasn

Thanks for sharing your opinions, and gave much help on understanding your idea.

@ali.alzyod and I are a bit confused why you suggested the annotation_factory in Aug (T8151) and now changed the concept now.
We have expected the feature would be very helpful, and have thought as a major feature in new interface.
(That was the reason why we had added our opinions in T8151 on the discussion of annotation_factory)

Anyway, I hope to hear other developers' idea together ~
Based on our discussion ~ other developers can give better solution :)

@bu5hm4n @segfaultxavi @cedric @zmike @felipealmeida @lauromoura
Could you share your thought on this subject ? I'll appreciate any opinion from you :)

zmike added a comment.Oct 2 2019, 5:06 AM

I'm still considering this, but for the ideas that @tasn has proposed, what if EFL also provided public API for handling the parsing of those strings?

For example, there could be an API for generating a style string that can be set, and another API for parsing and retrieving values from it.

This could be a compromise which fits both cases.

tasn added a comment.Oct 2 2019, 5:07 AM

I understand @woohyun, and I'm sorry for the suggested changes. I wouldn't suggest it if I didn't think it was useful.

The annotation factory was a way to support what was already there, which I understood you liked: the setting of style/annotations using functions. I initially liked it too, and that's why it was incorporated. However, after getting to the implementation stage, and having reviewed everything again, it's hard to justify having it.

As I said, it adds a lot of complexity, for very little value. I tried having it, but upon further review, what's already there with the string, is just more robust.

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

To simplify my example:
User will change font_Size multiple times (application is like rich text editor), keep modify the main style string it will become very large and waist memory.

1- style originally : "font_color=red font_size=20 font_name=arial"
2- change font size: "font_color=red font_size=20 font_name=arial font_size=15"
3- change font size: "font_color=red font_size=20 font_name=arial font_size=15 font_size=30"
4- change font size: "font_color=red font_size=20 font_name=arial font_size=15 font_size=30 font_size=20"

as you can see there will be a lot of useless info in the style

tasn added a comment.Oct 2 2019, 5:38 AM

Again, you misread what I said and this is not actually what's going on.

I plan on bringing back style_user, or the style stack. Essentially meaning you have two styles per object. I accidentally removed it, or maybe it was removed by Efl.Canvas.Text and I just forgot to add it back.

The idea is that you have one style that's set by the theme/widget, which is the regular style that you don't ever touch.

Then you can override it using style_user.

So original style would be: "font_color=red font_size=12 font_name=arial"
style_user would be: ""

If you want to change font size, you just set style user.
You want to change it again, you just replace style user.

The way it's done in ecrire, which is the correct way of doing it IMHO, is translate a structure you have to string.
So the ecrire settings saved it in a struct, such as (psuedo code):

Settings {
    color: "red";
    size: 20;
}

And then just create the style every time the settings are changed, so:

sprintf(new_style_str, "font_color=%s font_size=%d", settings.color, settings.size)
textblock_style_style_string_set(user_style, new_style_str)

Very simple, very easy to do. Not redundant, not wasteful, not anything.

ali.alzyod added a comment.EditedOct 2 2019, 5:53 AM

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

I do not know about your plan :), I was talking what we have now

Settings {
    color: "red";
    size: 20;
}
Setting.size = 30;
sprintf(new_style_str, "font_color=%s font_size=%d", settings.color, settings.size)
textblock_style_style_string_set(user_style, new_style_str)

vs

efl_text_font_size(tb,30)

I do not see it is very simple

I can see benefit of your suggestion, where you can set multiple styles properties at once.

So how about support both, style can be serialize/deserialized
efl_text_style_string_set(tb,"font_size=20"); // this is general function to set style legacy way with markup text
efl_text_style_font_size_set(tb,20);

zmike added a comment.Oct 2 2019, 6:00 AM

It seems like my proposal would already handle that.

tasn added a comment.Oct 2 2019, 6:02 AM

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

I do not know about your plan :), I was talking what we have now

Settings {
    color: "red";
    size: 20;
}
Setting.size = 30;
sprintf(new_style_str, "font_color=%s font_size=%d", settings.color, settings.size)
textblock_style_style_string_set(user_style, new_style_str)

vs

efl_text_font_size(tb,30)

I do not see it is very simple

That's because this is not a fair comparison. You need the Settings struct *regardless* because you need to save the settings to file.
You also need to update it regardless, because again, it needs to be saved.

You *anyway* are not going to set the font directly on the text object, you'd need to go through a style. This was never different in either proposal, so the comparative would be something like:

Settings {
    color: "red";
    size: 20;
}
Setting.size = 30;
efl_text_style_font_size_set(attr_factory, 20);
attribute_factory_style_set(tb, attr_factory);

I can see benefit of your suggestion, where you can set multiple styles properties at once.

So how about support both, style can be serialize/deserialized
efl_text_style_string_set(tb,"font_size=20"); // this is general function to set style legacy way with markup text
efl_text_style_font_size_set(tb,20);

Support both is exactly the pain I was trying to avoid and why this ticket was opened in the first place. I realised I'd have to support both anyway, so I removed the one that I thought didn't add much value.

tasn added a comment.Oct 3 2019, 12:34 AM

One more thing: as I said before, even if we do allow calling functions to manipulate this (e.g. have a separate string builder that builds a string to use here from these functions), this will not really achieve what you are trying to do with reading the values that are currently set. There's really no sane way of doing it at the moment, nor has there ever been, and I'm not sure there should be.

Would be very helpful if you could plainly lay out requirements with some example *real* usecases (like what @woohyun) gave with the dialer app.

ali.alzyod added a comment.EditedOct 3 2019, 1:00 AM

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

Also the font_size_factor example is not right, the widget should not inherit this font-size
from other widgets, and EFL was work fine for so long without this feature and we can add it at markup level

If Markup can not be implemented externally it is ok, this will give us dynamic why to make a lot of additional features along the way,

Second:
For the example you request, I do not think the argument is about what user can/can't do, it is how easy he is able to do it, As I mention rich text editor, this is not easy, if user needs this setting structure to change any property of UI component, then it is logical to provided it as part of our framework.
Complain is The way of manipulate strings to change/read/write style is not easy for user, I like @zmike Idea where it is easy for user to figure out how to work with EFL-Text components.

tasn added a comment.Oct 3 2019, 1:30 AM

Could you please reformat what you wrote? I'm not sure what's a quote and what you're actually saying.

is it ok now ?

tasn added a comment.Oct 3 2019, 1:44 AM

Ahh, so no quotes at all! OK, perfect, thanks.

tasn added a comment.Oct 3 2019, 1:52 AM

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

So your argument is "we don't have a good argument so just leave it the way it is"? I don't think I agree with that. The whole point here is fixing things... Also, this was changed quite recently, so it's not "already there". This API wasn't even released...

Also the font_size_factor example is not right, the widget should not inherit this font-size

from other widgets, and EFL was work fine for so long without this feature and we can add it at markup level

I never said it should inherit from other widgets. I said *WITHIN THE SAME WIDGET*. So the theme would set the font size, and you'll be able to set a relative size inside.

If Markup can not be implemented externally it is ok, this will give us dynamic why to make a lot of additional features along the way,

Not sure I understand what you mean. Though with this proposal a lot of the understanding of the markup will actually move back into textblock.

Second:
For the example you request, I do not think the argument is about what user can/can't do, it is how easy he is able to do it, As I mention rich text editor, this is not easy, if user needs this setting structure to change any property of UI component, then it is logical to provided it as part of our framework.

You don't need the structure, or you need it for both cases. The structure was an example on how it's done in ecrire because the structure needs to be saved in the ecrire configuration anyway, because it needs to load it again the next time the application is loaded.

Complain is The way of manipulate strings to change/read/write style is not easy for user, I like @zmike Idea where it is easy for user to figure out how to work with EFL-Text components.

This is essentially a style string generator. I'm OK with doing that, but it's not really going to let you read the value of existing widgets unless we exposed the default style. We can, but again, it's not the right way of achieving what you want.

So to summarise: you're OK with textblock only working with strings as long as there's a string manipulation class? Because look at my suggestion in T8306, I plan on adding "%" for relative types and more complex stuff like this. This means essentially all the values will be string anyway, so the class won't have efl_text_font_size_set(int) but rather, but rather font_size_set(string), or even more likely attribute_set(attribute_name: string, string) so you'd just do attribute_set("font_size", "100%").

I hope this clarifies my view.

tasn closed this task as Resolved.Oct 10 2019, 4:33 AM

I talked with @ali.alzyod about it separately. I'm going with what's described here for now, but I created it in a way that adding the specific functions later on should be very easy. It's just a matter of adding the wanted interfaces (already exist in the history in my branch) to Efl.Canvas.Text_Style and Efl.Text.Attribute.Factory (now they are sitting under Efl2, but this will change soon).