Page MenuHomePhabricator

RFC: new markup (and attributes)
Open, Incoming QueuePublic

Description

Here's a suggestion for how the new markup should be.

I tried to make it as similar to HTML/CSS as possible, but avoid naming things that would be confusing (because we do something similar but allowed values are very different).

First of all, the new markup will always require having a tag, so <font_size=12>hi</> is no longer allowed, you now need <span font_size=12>hi</span>. This will make it more familiar/HTML like and makes parsing and validation much easier.

You have a few basic tags:

  • span: any sort of a span of text - used for applying styles
  • a: essentially a span, but also supports "href" for a link indicator
  • item: an embedded item in the text (replaced with an object)
  • ps / br: paragraph separator and line separator respectively.

We will have some default aliases (with styling applied), such as b, u, i, em and s. They are all essentially spans with some styling.

People, both in theme and code will be able to add aliases so one could add: danger -> span with color=red. This will inherit the styling of the span and let you override it.
You can also do: visited_link -> a color=grey which will inherit the styling of a and change only the color.

Attributes

Tags can have attributes assigned to them. My suggestion is mostly based on what's already there so assume the allowed values are the same (documented in efl_canvas_text.c and will be documented in the wiki too).

The names are that are just the same remained this way. The arrow (->) indicates a rename. FIXME means something I extra want comments on.

font -> font_family
font_fallbacks
font_size
font_source
font_weight
font_style
font_width -> font_stretch
lang
color
background    FIXME: it was previously split to on/off and color. I guess it should be the same property.

underline
underline_height
underline_color
underline2_color
underline_dash_color
underline_dash_width
underline_dash_gap

strikethrough
strikethrough_color

style -> effect FIXME yeah?
outline_color
shadow_color
glow_color
glow2_color

left_margin -> margin_left  FIXME: remove/only allow on items?
right_margin -> margin_right   FIXME: remove/only allow on items?

align
valign -> vertical_align

tabstops -> tab_width

linesize -> line_height
linerelsize -> line_height with %

linegap -> line_gap FIXME: how does this one and line_height actually interact?
linerelgap -> line_gap with %

linefill -> Not sure what this even means

Ones to remove (because are implemented elsewhere: text_valign, wrap, repch and password.

Looking forward to hearing your thoughts.

tasn created this task.Oct 3 2019, 1:43 AM

I have two comments:

1- I can not imagine markup text could be implemented externally to efl_canvas_text, right ?

2- Are we still compatible with legacy Markup text ?

tasn added a comment.Oct 3 2019, 2:17 AM
  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?
tasn updated the task description. (Show Details)Oct 3 2019, 2:31 AM

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

tasn added a comment.EditedOct 3 2019, 7:19 AM

Ahhh you mean backwards compatibility?

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

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?

markup_set/get though will work with the current markup type.

ali.alzyod added a comment.EditedOct 3 2019, 7:33 AM

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)

something like:
efl_text_markup_interactive_cursor_markup_insert
efl_text_markup_interactive_markup_range_get
efl_text_markup_interactive_markup_range_set

also direct convert between utf8 and markup with
efl_text_markup_util_markup_to_text
efl_text_markup_util_text_to_markup

tasn added a comment.Oct 3 2019, 7:42 AM

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)

There's a range_markup_get in the markup class.

something like:
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.

also direct convert between utf8 and markup with
efl_text_markup_util_markup_to_text
efl_text_markup_util_text_to_markup

No longer needed because now you can just take the text directly from textblock object without the markup. These were workarounds for this issue. Same with setting.

If you think it's still needed (I don't see why), we can easily add them to the efl2.text.serializer.markup class.

raster added a comment.Oct 6 2019, 5:30 AM

so <font_size=12>hi</> is no longer allowed

Dislike this... this was simple and convenient. It saved having to remember what the tag was and allowed collecting a bunch of format changes/transforms into a single pus then a pop when no longer needed.

:(

tasn added a comment.Oct 7 2019, 12:05 AM

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.

zmike added a comment.Oct 7 2019, 6:35 AM

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

left_margin -> margin_left  FIXME: remove/only allow on items?
right_margin -> margin_right   FIXME: remove/only allow on items?

Why do we not want this on regular text? I've never used this so I don't have much perspective here other than it seeming odd to lose a "feature".

align
valign -> vertical_align

We may want to have these be horizontal_align and vertical_align to be explicit if we're renaming one. Or align_horiz and align_vert or somesuch if we're doing EFL-style naming.

tabstops -> tab_width

Good

linesize -> line_height

Good

linerelsize -> line_height with %

Not sure what with % means here?

linegap -> line_gap FIXME: how does this one and line_height actually interact?

I think this is supposed to be the space between the lines and line_height is the height of the line? Not sure what this question means beyond that.

linerelgap -> line_gap with %

Same as above.

linefill -> Not sure what this even means

Based on a skim of the current textblock implementation it seems like this doing some kind of scaling for the height, but I've never seen it used.

Seeing this again, I really think we should have some object which lets you create a context for managing this and has an actual API for setting the attributes we implement. This also would force us to document all the attributes, and it would give us the capability to provide bindings with a unified method for it besides setting raw text strings (which we can still allow for experts, obviously). We can have it do serialization (e.g., create object, set attributes, generate text string that can be set and/or just directly pass the context to the textblock to let it handle that) and also deserialization (e.g., textblock creates a context from its internal style, taking into account cursor positions, and returns this to the user for explicit API "get" functionality").

tasn added a comment.Oct 7 2019, 6:48 AM
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?

left_margin -> margin_left  FIXME: remove/only allow on items?
right_margin -> margin_right   FIXME: remove/only allow on items?

Why do we not want this on regular text? I've never used this so I don't have much perspective here other than it seeming odd to lose a "feature".

I've never used or seen it used either, which is why the FIXME. I have no problem with keeping it though.

align
valign -> vertical_align

We may want to have these be horizontal_align and vertical_align to be explicit if we're renaming one. Or align_horiz and align_vert or somesuch if we're doing EFL-style naming.

I was trying to mirror css so it's more approachable to people. Still think it's better to rename?

As for vertical_align, you're correct, it should be align_vertical.

tabstops -> tab_width

Good

linesize -> line_height

Good

linerelsize -> line_height with %

Not sure what with % means here?

Instead of linerelsize=2 you'd do line_height=200%

linegap -> line_gap FIXME: how does this one and line_height actually interact?

I think this is supposed to be the space between the lines and line_height is the height of the line? Not sure what this question means beyond that.

Obviously... I think I was asking more about how excatly line height and this behave. As in, this adds spacing below the line, and line height above? Or does line height actually increase the line height and center everything? I wasn't sure about what we're actually doing.

linerelgap -> line_gap with %

Same as above.

Same as above.

linefill -> Not sure what this even means

Based on a skim of the current textblock implementation it seems like this doing some kind of scaling for the height, but I've never seen it used.

Yeah, but based on the object's height not the line height. I really have no idea what this is meant to do. @raster?

Seeing this again, I really think we should have some object which lets you create a context for managing this and has an actual API for setting the attributes we implement. This also would force us to document all the attributes, and it would give us the capability to provide bindings with a unified method for it besides setting raw text strings (which we can still allow for experts, obviously). We can have it do serialization (e.g., create object, set attributes, generate text string that can be set and/or just directly pass the context to the textblock to let it handle that) and also deserialization (e.g., textblock creates a context from its internal style, taking into account cursor positions, and returns this to the user for explicit API "get" functionality").

The initial proposal I made had methods and etc for everything, though I've since changed my mind. You can see T8303 for more information on why.

There are many reasons, but the one that's mostly relevant to what you wrote: users will actually end up using the textual/string representation almost always. The reason for that, is that for most cases, they would be doing something like: efl_text_content_markup_set(tb, "Hello <b>Tom</b>!"), as in, set the markup directly rather than in code. The setting in code is actually the rare "advanced" usage.

As I said though, more info and a lot of more reasons in T8303.

zmike added a comment.Oct 7 2019, 7:26 AM
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...

left_margin -> margin_left  FIXME: remove/only allow on items?
right_margin -> margin_right   FIXME: remove/only allow on items?

Why do we not want this on regular text? I've never used this so I don't have much perspective here other than it seeming odd to lose a "feature".

I've never used or seen it used either, which is why the FIXME. I have no problem with keeping it though.

Maybe we can have @woohyun provide some feedback here on whether it should be kept.

align
valign -> vertical_align

We may want to have these be horizontal_align and vertical_align to be explicit if we're renaming one. Or align_horiz and align_vert or somesuch if we're doing EFL-style naming.

I was trying to mirror css so it's more approachable to people. Still think it's better to rename?

As for vertical_align, you're correct, it should be align_vertical.

If we're trying to more strictly resemble CSS then I think using those names is fine.

tabstops -> tab_width

Good

linesize -> line_height

Good

linerelsize -> line_height with %

Not sure what with % means here?

Instead of linerelsize=2 you'd do line_height=200%

Ah, I see.

linegap -> line_gap FIXME: how does this one and line_height actually interact?

I think this is supposed to be the space between the lines and line_height is the height of the line? Not sure what this question means beyond that.

Obviously... I think I was asking more about how excatly line height and this behave. As in, this adds spacing below the line, and line height above? Or does line height actually increase the line height and center everything? I wasn't sure about what we're actually doing.

linerelgap -> line_gap with %

Same as above.

Same as above.

linefill -> Not sure what this even means

Based on a skim of the current textblock implementation it seems like this doing some kind of scaling for the height, but I've never seen it used.

Yeah, but based on the object's height not the line height. I really have no idea what this is meant to do. @raster?

Seeing this again, I really think we should have some object which lets you create a context for managing this and has an actual API for setting the attributes we implement. This also would force us to document all the attributes, and it would give us the capability to provide bindings with a unified method for it besides setting raw text strings (which we can still allow for experts, obviously). We can have it do serialization (e.g., create object, set attributes, generate text string that can be set and/or just directly pass the context to the textblock to let it handle that) and also deserialization (e.g., textblock creates a context from its internal style, taking into account cursor positions, and returns this to the user for explicit API "get" functionality").

The initial proposal I made had methods and etc for everything, though I've since changed my mind. You can see T8303 for more information on why.

There are many reasons, but the one that's mostly relevant to what you wrote: users will actually end up using the textual/string representation almost always. The reason for that, is that for most cases, they would be doing something like: efl_text_content_markup_set(tb, "Hello <b>Tom</b>!"), as in, set the markup directly rather than in code. The setting in code is actually the rare "advanced" usage.

As I said though, more info and a lot of more reasons in T8303.

I've seen (all of) your comments in T8303, but from my reading of it I was unable to see anything directly referencing my proposal with any significant level of detail.

While it's true that in many cases the user will be setting simple markup as in your example, for the cases of pushing user styles with more complex tags, I think this could still be useful. @woohyun has already said that they've implemented their own parsers for this in various apps, so it seems clear to me that there's a case to be made for providing this at least in a "training wheels" sort of way for programmatically managing those complex tags.

I don't personally think it's a requirement to have this sort of thing, I just think it would be a nice benefit for some use cases.

tasn added a comment.EditedOct 7 2019, 8:48 AM
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.

I don't remember about glow2 from the top of my head.

align
valign -> vertical_align

We may want to have these be horizontal_align and vertical_align to be explicit if we're renaming one. Or align_horiz and align_vert or somesuch if we're doing EFL-style naming.

I was trying to mirror css so it's more approachable to people. Still think it's better to rename?

As for vertical_align, you're correct, it should be align_vertical.

If we're trying to more strictly resemble CSS then I think using those names is fine.

Trying to resemble more, yeah.

Seeing this again, I really think we should have some object which lets you create a context for managing this and has an actual API for setting the attributes we implement. This also would force us to document all the attributes, and it would give us the capability to provide bindings with a unified method for it besides setting raw text strings (which we can still allow for experts, obviously). We can have it do serialization (e.g., create object, set attributes, generate text string that can be set and/or just directly pass the context to the textblock to let it handle that) and also deserialization (e.g., textblock creates a context from its internal style, taking into account cursor positions, and returns this to the user for explicit API "get" functionality").

The initial proposal I made had methods and etc for everything, though I've since changed my mind. You can see T8303 for more information on why.

There are many reasons, but the one that's mostly relevant to what you wrote: users will actually end up using the textual/string representation almost always. The reason for that, is that for most cases, they would be doing something like: efl_text_content_markup_set(tb, "Hello <b>Tom</b>!"), as in, set the markup directly rather than in code. The setting in code is actually the rare "advanced" usage.

As I said though, more info and a lot of more reasons in T8303.

I've seen (all of) your comments in T8303, but from my reading of it I was unable to see anything directly referencing my proposal with any significant level of detail.

While it's true that in many cases the user will be setting simple markup as in your example, for the cases of pushing user styles with more complex tags, I think this could still be useful. @woohyun has already said that they've implemented their own parsers for this in various apps, so it seems clear to me that there's a case to be made for providing this at least in a "training wheels" sort of way for programmatically managing those complex tags.

I don't personally think it's a requirement to have this sort of thing, I just think it would be a nice benefit for some use cases.

Maybe I'm misremembering and I didn't say it in T8303, but somewhere else, though as I said: almost always people will use simple markup. So even for the cases where they don't, they would have already acquired that knowledge.

As for what @woohyun described, you misunderstood him and what they are trying to do.
Essentially: they don't want to go through themes and want a way to go around them. They've managed to achieve that in Tizen (only for textblock, not other widgets) by taking the style of the textblock and parsing it manually in order to extract the values set by the theme. This goes against the "efl way" which is why there's no better way of doing it. You shouldn't be hardcoding style from code, and I've yet to be presented a valid usecase where a user of the API should have access to the values used in the theme (again, within the context of the EFL).
So as you can see, they don't really need it, it's just one method they used as a hack to go around how things are done in the efl.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

zmike added a comment.Oct 7 2019, 9:09 AM
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?

I don't remember about glow2 from the top of my head.

Seems like we have a good case for clarifying this name then.

align
valign -> vertical_align

We may want to have these be horizontal_align and vertical_align to be explicit if we're renaming one. Or align_horiz and align_vert or somesuch if we're doing EFL-style naming.

I was trying to mirror css so it's more approachable to people. Still think it's better to rename?

As for vertical_align, you're correct, it should be align_vertical.

If we're trying to more strictly resemble CSS then I think using those names is fine.

Trying to resemble more, yeah.

Seeing this again, I really think we should have some object which lets you create a context for managing this and has an actual API for setting the attributes we implement. This also would force us to document all the attributes, and it would give us the capability to provide bindings with a unified method for it besides setting raw text strings (which we can still allow for experts, obviously). We can have it do serialization (e.g., create object, set attributes, generate text string that can be set and/or just directly pass the context to the textblock to let it handle that) and also deserialization (e.g., textblock creates a context from its internal style, taking into account cursor positions, and returns this to the user for explicit API "get" functionality").

The initial proposal I made had methods and etc for everything, though I've since changed my mind. You can see T8303 for more information on why.

There are many reasons, but the one that's mostly relevant to what you wrote: users will actually end up using the textual/string representation almost always. The reason for that, is that for most cases, they would be doing something like: efl_text_content_markup_set(tb, "Hello <b>Tom</b>!"), as in, set the markup directly rather than in code. The setting in code is actually the rare "advanced" usage.

As I said though, more info and a lot of more reasons in T8303.

I've seen (all of) your comments in T8303, but from my reading of it I was unable to see anything directly referencing my proposal with any significant level of detail.

While it's true that in many cases the user will be setting simple markup as in your example, for the cases of pushing user styles with more complex tags, I think this could still be useful. @woohyun has already said that they've implemented their own parsers for this in various apps, so it seems clear to me that there's a case to be made for providing this at least in a "training wheels" sort of way for programmatically managing those complex tags.

I don't personally think it's a requirement to have this sort of thing, I just think it would be a nice benefit for some use cases.

Maybe I'm misremembering and I didn't say it in T8303, but somewhere else, though as I said: almost always people will use simple markup. So even for the cases where they don't, they would have already acquired that knowledge.

As for what @woohyun described, you misunderstood him and what they are trying to do.
Essentially: they don't want to go through themes and want a way to go around them. They've managed to achieve that in Tizen (only for textblock, not other widgets) by taking the style of the textblock and parsing it manually in order to extract the values set by the theme. This goes against the "efl way" which is why there's no better way of doing it. You shouldn't be hardcoding style from code, and I've yet to be presented a valid usecase where a user of the API should have access to the values used in the theme (again, within the context of the EFL).
So as you can see, they don't really need it, it's just one method they used as a hack to go around how things are done in the efl.

As I said in my previous comment, I don't think it's a requirement to have this (anymore). I think it would be useful for some cases, and we can keep this in mind in case we determine there's a need for it.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

I'm not sure how setting size for widgets would work in this sense considering we already have geometry setting functions and size hints? I'm not sure we want the color API to be hooked by text, however, as that would mean you'd do color_set at a higher level and then the text object would have to somehow serialize that into style tags on top of the existing tags. Seems like this would be better handled with a clip/mask/filter on the high-level widget.

tasn added a comment.Oct 8 2019, 3:05 AM
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?

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.

I don't remember about glow2 from the top of my head.

Seems like we have a good case for clarifying this name then.

Not necessarily, it can be hard to encompass a full meaning in a name. Need to examine this.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

I'm not sure how setting size for widgets would work in this sense considering we already have geometry setting functions and size hints? I'm not sure we want the color API to be hooked by text, however, as that would mean you'd do color_set at a higher level and then the text object would have to somehow serialize that into style tags on top of the existing tags. Seems like this would be better handled with a clip/mask/filter on the high-level widget.

Size: I misspoke, I meant font-size.
I think we are talking about completely different things because I don't understand what you are trying to say.

Think of a button: they want a way to get the font/size/colour of the text, the background, the border and etc and be able to manipulate it from code rather than having to change the theme. We don't allow it anywhere in the EFL, and I'd rather not do something different in the text object.

zmike added a comment.Oct 8 2019, 6:58 AM
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.

I don't remember about glow2 from the top of my head.

Seems like we have a good case for clarifying this name then.

Not necessarily, it can be hard to encompass a full meaning in a name. Need to examine this.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

I'm not sure how setting size for widgets would work in this sense considering we already have geometry setting functions and size hints? I'm not sure we want the color API to be hooked by text, however, as that would mean you'd do color_set at a higher level and then the text object would have to somehow serialize that into style tags on top of the existing tags. Seems like this would be better handled with a clip/mask/filter on the high-level widget.

Size: I misspoke, I meant font-size.
I think we are talking about completely different things because I don't understand what you are trying to say.

This makes more sense, I'm not sure how I didn't think of that immediately...

Think of a button: they want a way to get the font/size/colour of the text, the background, the border and etc and be able to manipulate it from code rather than having to change the theme. We don't allow it anywhere in the EFL, and I'd rather not do something different in the text object.

My interpretation was that you'd want efl_gfx_entity_color_set to work directly on textblock objects and be parsed internally into style tags, and that there was a desire to be able to modify various style attributes (e.g., size) directly from the code just like we've always been able to do. If you're against having interface-like properties for getting/setting text attributes on every object, I agree that we should not do this. These should be specific to actual text objects like they always have been.

tasn added a comment.Oct 9 2019, 5:55 AM
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.

I don't think I follow. The first underline's colour is set using underline_color, and the second's using underline2_color.

I don't remember about glow2 from the top of my head.

Seems like we have a good case for clarifying this name then.

Not necessarily, it can be hard to encompass a full meaning in a name. Need to examine this.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

I'm not sure how setting size for widgets would work in this sense considering we already have geometry setting functions and size hints? I'm not sure we want the color API to be hooked by text, however, as that would mean you'd do color_set at a higher level and then the text object would have to somehow serialize that into style tags on top of the existing tags. Seems like this would be better handled with a clip/mask/filter on the high-level widget.

Size: I misspoke, I meant font-size.
I think we are talking about completely different things because I don't understand what you are trying to say.

This makes more sense, I'm not sure how I didn't think of that immediately...

Think of a button: they want a way to get the font/size/colour of the text, the background, the border and etc and be able to manipulate it from code rather than having to change the theme. We don't allow it anywhere in the EFL, and I'd rather not do something different in the text object.

My interpretation was that you'd want efl_gfx_entity_color_set to work directly on textblock objects and be parsed internally into style tags, and that there was a desire to be able to modify various style attributes (e.g., size) directly from the code just like we've always been able to do. If you're against having interface-like properties for getting/setting text attributes on every object, I agree that we should not do this. These should be specific to actual text objects like they always have been.

Clarification: that's not what I want, I was describing what they were trying to achieve with these functions.

I'm not against having this interface-like properties on every object (and it's not just for text, they want it for everything), but this is not how things are done in the efl and @raster is very much against it.
It seems you and I are in agreement, text should be consistent with the rest of the efl, we can add it for text if we add/plan on adding it everywhere else, and not otherwise.

zmike added a comment.Oct 9 2019, 6:54 AM
In T8306#144619, @tasn wrote:
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.

I don't think I follow. The first underline's colour is set using underline_color, and the second's using underline2_color.

You're not the only one. Maybe I need to stop posting on these threads so early in the morning...

I think it's fine to keep underline2_color if it's the only case of "2" in the names and/or we ensure that "2" always means "the second" instead of how it is in e.g., edc where it means...I want to say outline, but it might be glow...

I don't remember about glow2 from the top of my head.

Seems like we have a good case for clarifying this name then.

Not necessarily, it can be hard to encompass a full meaning in a name. Need to examine this.

Edit: just one clarification. I'm actually in favour of having a way to get/set the colour/size/whatever of widgets directly in code rather than having to go through the theme as I think it could be very useful for beginners who are just starting (themes can be unfamiliar and scary). Though I don't want textblock to be different to the rest of the EFL. If we decide it's something that's needed, we should do it all around, or at least declare it, and then start with doing it in textblock.

I'm not sure how setting size for widgets would work in this sense considering we already have geometry setting functions and size hints? I'm not sure we want the color API to be hooked by text, however, as that would mean you'd do color_set at a higher level and then the text object would have to somehow serialize that into style tags on top of the existing tags. Seems like this would be better handled with a clip/mask/filter on the high-level widget.

Size: I misspoke, I meant font-size.
I think we are talking about completely different things because I don't understand what you are trying to say.

This makes more sense, I'm not sure how I didn't think of that immediately...

Think of a button: they want a way to get the font/size/colour of the text, the background, the border and etc and be able to manipulate it from code rather than having to change the theme. We don't allow it anywhere in the EFL, and I'd rather not do something different in the text object.

My interpretation was that you'd want efl_gfx_entity_color_set to work directly on textblock objects and be parsed internally into style tags, and that there was a desire to be able to modify various style attributes (e.g., size) directly from the code just like we've always been able to do. If you're against having interface-like properties for getting/setting text attributes on every object, I agree that we should not do this. These should be specific to actual text objects like they always have been.

Clarification: that's not what I want, I was describing what they were trying to achieve with these functions.

I'm not against having this interface-like properties on every object (and it's not just for text, they want it for everything), but this is not how things are done in the efl and @raster is very much against it.
It seems you and I are in agreement, text should be consistent with the rest of the efl, we can add it for text if we add/plan on adding it everywhere else, and not otherwise.

Yes, we're in agreement on this point. Having text property manipulation on every object would be a nightmare, especially since it'd end up having to override layout styles and such.

tasn added a comment.Oct 10 2019, 6:03 AM

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'm thinking of maybe just making it more strict and add some aliases, but make it almost entirely backwards compatible. Or even completely backwards compatible with warnings instead of errors when parsing markup that doesn't fit our stricter policies.

zmike added a comment.Oct 10 2019, 6:19 AM

We currently already have warnings in place for edje_cc text calculations, so I don't think it'd be an issue to throw more warnings recommending that people switch to the newer syntax.

tasn added a comment.Oct 10 2019, 6:19 AM

Sweet. :)

zmike moved this task from Backlog to Evaluating on the efl: api board.Oct 14 2019, 5:56 AM
ali.alzyod added a comment.EditedOct 15 2019, 3:47 AM

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

We can add these functionality into cursor interactive class

tasn added a comment.Oct 15 2019, 4:05 AM

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

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

As for markup_range_set, it's essentially range_delete + cursor_markup_insert. So I'm not sure why you think we need a special function for this. We don't need it, the same way we don't have range_plain_insert.

ali.alzyod added a comment.EditedOct 15 2019, 5:33 AM

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

What interface ?

These methods founded previously in Efl.Text_Markup_Interface which extend Efl.Text_Cursor interface that we removed and use Cursor Class instead

tasn added a comment.Oct 15 2019, 5:41 AM

Efl2.Text.Content.Markup. See T8297

ali.alzyod added a comment.EditedOct 15 2019, 5:44 AM
In T8306#145434, @tasn wrote:

Efl2.Text.Content.Markup. See T8297

There are no markup_range_get,cursor_markup_insert, So you suggest we added them into Efl2.Text.Content.Markup interface

Note: these functions work on Cursors

tasn added a comment.Oct 15 2019, 5:57 AM

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

ali.alzyod moved this task from Evaluating to Backlog on the efl: api board.Feb 5 2020, 12:20 AM