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

Yup, we have a similar idea in mind.

Sorry, wrong place. I meant: T8215 and the class described there...

Efl2.Text.Content.Markup. See T8297

In T8306#145429, @ali.alzyod wrote:

efl_text_markup_interactive_cursor_markup_insert
efl_text_markup_interactive_markup_range_get
efl_text_markup_interactive_markup_range_set

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

I think we will need to support these functions, because of copy and paste functionality.
1- For example when user select range and Hit copy, we need to store the text he selected(in Markup Format), this is why we need markup_range_get
2- For example when user paste stored text at cursor position (text is saved in Markup Format) cursor_markup_insert
3- For example when user paste stored text, where he already has a selection, then we need to replace the selected text with clipboard text(in Markup format) at cursor position (text is saved in Markup Format) markup_range_set

@ali.alzyod, while this may be good feedback, this is not exactly what we are talking about. We are talking about the item_add function signature.

I think the separation is cleaner (as not everything supports markup, e.g. the text of a button), but I'm open to whatever you think is right.

Sweet. :)

After talking about this above and with raster about this, I'm not sure the fairly minor consistency improvements are worth the breaks/compatibility changes.

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

Updated the description.

In T8306#144546, @zmike wrote:

In T8306#144533, @tasn wrote:

In T8306#144506, @zmike wrote:

Can this be set without the regular underline attribute?

The underline attribute controls this. At the moment you can only set on/off/single/double/dashed, but e.g. pango also allow you to just have the lower one. This anyhow lets you control the colour of the second underline, separately from the first one.

So the first underline's color is set through the regular text color methods, but the second one has its own color attribute? This seems confusing to me, but I'm just a layman.

Don't think you can do that, because rgba(255, 0, 0, 1) would behave differently to rgba(255, 0, 0, 1.0) which is hella confusing.

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

I just noticed this, and I have one major comment. I don't know if you were aiming to mirror html/css when doing this, but assume you were, you have a mistake. In CSS the alpha value of rgba() is a float between 0 and 1. You made it an int of values 0-255...

In T8306#144506, @zmike wrote:

In T8306#144505, @tasn wrote:

In T8306#144495, @zmike wrote:

In T8306#144493, @tasn wrote:

In T8306#144492, @zmike wrote:

Is it possible to rename the *2 properties to not have the 2 and instead use something more descriptive? I think it's frustrating to have to always remember what those mean (and I say that as someone who's been here for 10 years and still have to look it up every time).

Got a suggestion?

underline2 -> underline_double
glow2 -> I have no idea what this actually is? Is it the glow outline or the shadow? Either way it can just be glow_outline or glow_shadow or something I think...

It's not double though, it's the second underline (which could be standalone). It could be renamed to underline_lower, I guess. Though not sure it's much more descriptive.

Can this be set without the regular underline attribute?

In T8306#144495, @zmike wrote:

In T8306#144493, @tasn wrote:

In T8306#144492, @zmike wrote:

Is it possible to rename the *2 properties to not have the 2 and instead use something more descriptive? I think it's frustrating to have to always remember what those mean (and I say that as someone who's been here for 10 years and still have to look it up every time).

Got a suggestion?

underline2 -> underline_double
glow2 -> I have no idea what this actually is? Is it the glow outline or the shadow? Either way it can just be glow_outline or glow_shadow or something I think...

In T8306#144492, @zmike wrote:

Is it possible to rename the *2 properties to not have the 2 and instead use something more descriptive? I think it's frustrating to have to always remember what those mean (and I say that as someone who's been here for 10 years and still have to look it up every time).

I don't think so, but maybe? I don't think it's useful in relation to using text API, though if we want to add this generic utility function for whatever other reason, then we can.

You can still do a bunch of transformations in a single one.
<span font_size=12 font_family=Roboto>bla</span> works just fine and is encouraged. The only thing that's changing is the forced structure.

In T8306#144371, @ali.alzyod wrote:

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

I think it will solve the problem.

Another question:
What if the user wants to get one formated paragraph from one canvas, and copy it to other canvas or save it on file. (Like our legacy copy function) ?
How can he get markup text to represent this? (markup between two cursors)

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

Ahhh you mean backwards compatibility?

I renamed it (per @zmike's comment) to something that makes more sense. It'll sit there with other serializers under this namespace.

1. It could, but as part of my realisation in T8303. Markup handling, as in parsing the SGML like format will be done outside. However the processing of the attributes will be done inside. I was wrong in thinking we can also move that part outside of textblock.
2. Nope, unfortunately. We can write transformers though quite easily. It's just that the old markup was too lax and we need to make it much more strict. :| Would this be an issue for existing users you think? Were you thinking of doing a drop-in relpacement of replacing the objects?

In T8303#144341, @ali.alzyod wrote:

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,

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

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

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.

@woohyun, do you fellas have any input on this? A lot of these functions need like they need some changes and you all have the expertise. I was hoping to get feedback in the other ticket, but let's just merge the discussion to here.

Moved discussion to T8298

This affects a lot of the naming then. I didn't realise you were planning on stabilising Efl.Text, I thought it was within my mandate to change, and to be honest, I thought I'd have the energy to fight the restriction/regression.

Ah oops, already released. :(

It shouldn't be, because this restriction shouldn't (and haven't) be there. Though it is.

Let me explain what I meant:

In T8303#144281, @ali.alzyod wrote:

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

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

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

In T8303#144270, @ali.alzyod wrote:

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)

In T8303#144268, @ali.alzyod wrote:

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.

In T8303#144266, @ali.alzyod wrote:

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"

In T8303#144262, @woohyun wrote:

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

In T8303#144263, @ali.alzyod wrote:

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

In T8299#144189, @zmike wrote:

I do like this rework a lot better, and it seems sensible to have a (temporary) object for this kind of thing just for actual usage.

class Efl2.Text.Cursor
├ (P) position

This should probably be something more like text_position just to be explicit about what kind of position it is.

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.

(I squashed your commits btw, as they seem to just be renaming in two steps).

There's still work to be done, but the main parts are there.

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

In T8303#144247, @ali.alzyod wrote:

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.

In T8303#144246, @segfaultxavi wrote:

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.

Thanks

It's OK even to change the naming, we don't need to change functionality. Any naming changes suggestions?

In T8296#144143, @segfaultxavi wrote:

Some quick comments:

├ (P) size_formatted
├ (P) size_native

What are the units of these sizes? From the example, it looks like it's characters.

In T8296#144139, @zmike wrote:

class Efl2.Canvas.Text
├ (P) is_empty
├ (P) is_ellipsized
├ (P) style_insets

For these 3 (and the size_* properties) it would be nice to have a doc note about whether they perform additional operations (i.e., recalc) or just return internal values. This could likely be stated as a global doc note in the class doc instead of per-property.

In T8296#144135, @zmike wrote:

To start, I think this entire API could be moved to something like Efl.Gfx.Textblock (in src/efl/interfaces) and then implemented by this object, which seems like it would be best-named Efl.Canvas.Textblock in order to reflect the purpose. Is Efl.Ui.Text intended to be a reimplementation of these methods/properties or will it just forward to this object? If it's reimplementing then the interface should probably be a mixin?

Also going to overhaul

Will probably change, see my comment in T7855. It's also something I'm thinking of overhauling tomorrow.

Not yet, @ali.alzyod is working on it.

Efl.Text being stable means we can't use this namespace at all... :| This shouldn't be a problem, and it's stupid we are jumping backwards and shittifying our API instead of fixing bindings generators, but it's another argument I gave up on (and was already decided in the past but was changed without a discussion on the ML so I didn't catch it).

I suspect this might change a bit tomorrow. This, as you said, is essentially a copy of what was there, though I'm having second thoughts about it. I'm in the process of reviewing everything now that we've had some time to absorb the new interfaces and I don't think I like this.

Sorry this is still just a copy paste from what was there before. I'm still waiting for feedback on these functions in T8226. They will only be changed after that.

Thanks a lot for your feedback! I only learned today about Eina.Position2D et al. This is exactly the kind of feedback I was looking for. Will act upon it soon!

In D9570#190310, @segfaultxavi wrote:

I think it is useful to have two separate classes, because these two behaviors (editable and non-editable) are different enough.
I do not know why the default for Efl.Ui.Text is now editable but instead of removing one class, I would make their behaviors different again:
Either we make Efl.Ui.Text non-editable by default, or we rename Efl.Ui.Text_Editable to something like Efl.Ui.Label.

Thanks a lot! Weird though, I thought we disabled PRs on the e github...

Thanks for your comments. The branch generates just fine here (other than the C++ bindings that don't compile, but that will be fixed once I rename things). Are you using latest Eolian or the one from my branch? Because q66 recently made some breaking changes.

Great initiative, that would be great, thanks!