Page MenuHomePhabricator

efl2.canvas.text
Open, TODOPublic

Description

class Efl2.Canvas.Text
├ (P) is_empty
├ (P) is_ellipsized
├ (P) multiline
├ (P) style_insets
├ (P) legacy_newline
├ (P) style
├ (P) size_formatted
├ (P) size_native
├ (M) visible_range_get
├ (M) cursor_handle_new
├ (M) cursor_handle_free
├ (M) obstacle_add
├ (M) obstacle_del
├ (M) async_layout
├ (E) changed
├ (E) layout,finished
├ (E) style_insets,changed

Related Objects

zmike created this task.Oct 1 2019, 6:06 AM
zmike triaged this task as TODO priority.
zmike added a comment.Oct 1 2019, 6:27 AM

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?

zmike added a comment.EditedOct 1 2019, 6:38 AM
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.

├ (P) legacy_newline

Is this just for providing compatibility with legacy API? If so, then I think this should be an internal thing and not exposed in the eo file.

├ (P) style
├ (P) size_formatted
├ (P) size_native

These two should both be Eina.Size2D.

├ (M) visible_range_get
├ (M) cursor_handle_new
├ (M) cursor_handle_free

├ (P) multiline
├ (M) obstacle_add
├ (M) obstacle_del

Do these 3 APIs trigger an immediate, synchronous relayout? It's worth noting what happens here in the docs. This could possibly be stated as a global doc note in the class doc instead of per-property if it's uniform for all properties of this nature.

├ (M) async_layout

If the below layout event is changed, does this really need a future?
EDIT: reread the comment on this, it seems like you were already moving in this direction.

├ (E) changed

What types of change does this trigger for? Just when the text content of the object changes? Or also whenever any properties change?

├ (E) layout,finished

This could probably be layout,changed and pass Eina.Rect?

├ (E) style_insets,changed

This should pass the event info with the insets.

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.

├ (P) style
The style priority is the order of creation, styles created first                                            
are applied first with the exception of $NULL which is implicitly                                            
first.

Having the priority of a style depend on the creation timestamp of the style seems a bit complicated.
We could keep this as default behavior, but I would add API to change a style's priority.
Also, I do not know what a style string is in this context, is this explained someplace else?

zmike added a comment.EditedOct 1 2019, 8:46 AM

Ah, a further note: style cannot be used here as it will conflict with style from Efl.Ui.Widget. Perhaps text_style or some other name.

Following @zmike's suggestion:

├ (E) layout,changed

We have been using the naming convention property_name,changed for events triggered when a property changes, but there's no property named layout.
Could this event be renamed to follow this convention? Is there any particular property change that would always emit this event?

tasn added a comment.Oct 1 2019, 11:23 PM
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?

That's exactly what I was talking about in the other ticket. So essentially all of the objects in the efl that may at some point become reusable should be split this way and be empty objects and everything is in the interface?

tasn added a comment.Oct 1 2019, 11:32 PM
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.

Style_insets was the only one.

├ (P) legacy_newline

Is this just for providing compatibility with legacy API? If so, then I think this should be an internal thing and not exposed in the eo file.

No, it's not about compatibility, but thanks for pointing this out, it needs renaming.

├ (P) style
├ (P) size_formatted
├ (P) size_native

These two should both be Eina.Size2D.

Yeah, only discovered this one the other day. Done.

├ (M) visible_range_get
├ (M) cursor_handle_new
├ (M) cursor_handle_free
 
├ (P) multiline
├ (M) obstacle_add
├ (M) obstacle_del

Do these 3 APIs trigger an immediate, synchronous relayout? It's worth noting what happens here in the docs. This could possibly be stated as a global doc note in the class doc instead of per-property if it's uniform for all properties of this nature.

They shouldn't. I'm not sure what they do now, but they shouldn't. The only ones who trigger a sync layout are the ones querying the object (and not all of them).

├ (M) async_layout

If the below layout event is changed, does this really need a future?
EDIT: reread the comment on this, it seems like you were already moving in this direction.

Removed the future. Yeah, it didn't make any sense.

├ (E) changed

What types of change does this trigger for? Just when the text content of the object changes? Or also whenever any properties change?

Content. I guess content,changed would be better?

├ (E) layout,finished

This could probably be layout,changed and pass Eina.Rect?

It's not really changed, it's when it's actually done. I don't think passing an Eina.Rect is a good idea because it's most likely going to go unused and not necessarily free to calculate.

├ (E) style_insets,changed

This should pass the event info with the insets.

Again, the problem with passing this is that you may need to calculate stuff before calling it, and the calculation is not necessarily free. Doing an extra call later on is probably cheaper in the long run.

tasn added a comment.Oct 1 2019, 11:35 PM

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.

"Units" (essentially pixels), like everywhere else in the EFL.

├ (P) style
The style priority is the order of creation, styles created first                                            
are applied first with the exception of $NULL which is implicitly                                            
first.

Having the priority of a style depend on the creation timestamp of the style seems a bit complicated.
We could keep this as default behavior, but I would add API to change a style's priority.
Also, I do not know what a style string is in this context, is this explained someplace else?

The docs haven't been migrated properly yet, though it should be explained.

I'm going to change this a bit anyway.

zmike moved this task from Backlog to Evaluating on the efl: api board.Oct 14 2019, 5:56 AM