Page MenuHomePhabricator

tasn (Tom Hacohen)Administrator
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

User Since
Jan 23 2013, 8:14 AM (351 w, 2 d)
Roles
Administrator
Availability
Available

Recent Activity

Tue, Oct 15

tasn added a comment to T8297: Efl2.Text.Content*.

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

Tue, Oct 15, 9:02 AM · efl (efl-1.24), efl: api
tasn added a comment to T8364: Release prep: cleanups, tests and thoughts.

Yup, we have a similar idea in mind.

Tue, Oct 15, 5:58 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

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

Tue, Oct 15, 5:57 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

Efl2.Text.Content.Markup. See T8297

Tue, Oct 15, 5:41 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

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

Tue, Oct 15, 4:05 AM · efl: api

Mon, Oct 14

tasn added a comment to T8364: Release prep: cleanups, tests and thoughts.

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

Mon, Oct 14, 11:24 PM · efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

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.

Mon, Oct 14, 11:22 PM · efl (efl-1.24), efl: api

Sat, Oct 12

tasn created T8364: Release prep: cleanups, tests and thoughts.
Sat, Oct 12, 7:48 AM · efl: api
tasn updated the task description for T8362: Make sure we are happy with names and locations of files/interfaces/functions.
Sat, Oct 12, 7:40 AM · efl: api
tasn updated the task description for T8215: Implement efl2_text_serializer_markup.eo.
Sat, Oct 12, 7:39 AM · efl: api
tasn renamed T8363: Release prep: rename Efl2.* classes to Efl.* and remove unneeded stuff from Rename Efl2.* classes to Efl.* and remove unneeded stuff to Release prep: rename Efl2.* classes to Efl.* and remove unneeded stuff.
Sat, Oct 12, 7:35 AM · efl: api
tasn assigned T8298: Efl2.Input.Text to woohyun.
Sat, Oct 12, 7:34 AM · efl (efl-1.24), efl: api
tasn reassigned T8215: Implement efl2_text_serializer_markup.eo from tasn to woohyun.
Sat, Oct 12, 7:34 AM · efl: api
tasn removed a subtask for T8151: RFC: Text interfaces design proposal: T8362: Make sure we are happy with names and locations of files/interfaces/functions.
Sat, Oct 12, 7:33 AM · efl: api
tasn edited parent tasks for T8362: Make sure we are happy with names and locations of files/interfaces/functions, added: T8363: Release prep: rename Efl2.* classes to Efl.* and remove unneeded stuff; removed: T8151: RFC: Text interfaces design proposal.
Sat, Oct 12, 7:33 AM · efl: api
tasn added a subtask for T8363: Release prep: rename Efl2.* classes to Efl.* and remove unneeded stuff: T8362: Make sure we are happy with names and locations of files/interfaces/functions.
Sat, Oct 12, 7:33 AM · efl: api
tasn created T8363: Release prep: rename Efl2.* classes to Efl.* and remove unneeded stuff.
Sat, Oct 12, 7:33 AM · efl: api
tasn created T8362: Make sure we are happy with names and locations of files/interfaces/functions.
Sat, Oct 12, 7:26 AM · efl: api

Fri, Oct 11

tasn closed T8344: How to implement getting all anchors within a range (_achors_get in edje_entry) as Resolved.
Fri, Oct 11, 1:28 AM · efl: api
tasn closed T8343: Explain how to use Grapheme_Cluster/word_boundaries movements on Canvas.Text as Resolved.
Fri, Oct 11, 1:21 AM · efl: api
tasn created T8342: Make the Canvas.Text attribute parsing and style parsing more strict.
Fri, Oct 11, 1:02 AM · efl: api
tasn created T8341: Add a few default new tags to Efl.Canvas.Text.
Fri, Oct 11, 12:58 AM · efl: api
tasn created T8340: Split changed,user to changed,user and changed,user,pre.
Fri, Oct 11, 12:55 AM · efl: api
tasn created T8339: Finish implementing (moving) the Efl2.Canvas.Text unit tests.
Fri, Oct 11, 12:50 AM · efl: api
tasn created T8338: Cursor: fix going down/up with lines of multiple lengths..
Fri, Oct 11, 12:43 AM · efl: api
tasn created T8337: Split raw_editable and canvas_text to interfaces so they can be used as composite objects.
Fri, Oct 11, 12:39 AM · efl: api
tasn created T8336: Add support in Edje for the new tag alias feature.
Fri, Oct 11, 12:30 AM · efl: api
tasn created T8335: Use the new Efl2.Canvas.Text_Style in the legacy functions.
Fri, Oct 11, 12:28 AM · efl: api

Thu, Oct 10

tasn added a parent task for T8298: Efl2.Input.Text: T8151: RFC: Text interfaces design proposal.
Thu, Oct 10, 8:10 AM · efl (efl-1.24), efl: api
tasn added a subtask for T8151: RFC: Text interfaces design proposal: T8298: Efl2.Input.Text.
Thu, Oct 10, 8:10 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

Sweet. :)

Thu, Oct 10, 6:19 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

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.

Thu, Oct 10, 6:03 AM · efl: api
tasn closed T8303: RFC: changing back style/attribute handling to format strings rather than an interface as Resolved.

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

Thu, Oct 10, 4:33 AM · efl: api
tasn closed T8303: RFC: changing back style/attribute handling to format strings rather than an interface, a subtask of T8151: RFC: Text interfaces design proposal, as Resolved.
Thu, Oct 10, 4:33 AM · efl: api
tasn added a comment to T8215: Implement efl2_text_serializer_markup.eo.

Updated the description.

Thu, Oct 10, 2:23 AM · efl: api
tasn renamed T8215: Implement efl2_text_serializer_markup.eo from Implement efl2_text_markup.eo to Implement efl2_text_serializer_markup.eo.
Thu, Oct 10, 2:23 AM · efl: api

Wed, Oct 9

tasn added a comment to T8306: RFC: new markup (and attributes).
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.

Wed, Oct 9, 5:55 AM · efl: api
tasn added a comment to D9309: evas_common: parse color in rgb()/rgba() format.

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.

Wed, Oct 9, 5:50 AM · efl

Tue, Oct 8

tasn added a comment to D9309: evas_common: parse color in rgb()/rgba() format.

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

Tue, Oct 8, 3:53 AM · efl
tasn added a comment to D9309: evas_common: parse color in rgb()/rgba() format.

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

Tue, Oct 8, 3:27 AM · efl
tasn added a comment to T8306: RFC: new markup (and attributes).
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?

Tue, Oct 8, 3:05 AM · efl: api

Mon, Oct 7

tasn added a comment to T8306: RFC: new markup (and attributes).
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...

Mon, Oct 7, 8:48 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).
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).

Mon, Oct 7, 6:48 AM · efl: api
tasn added a comment to T8215: Implement efl2_text_serializer_markup.eo.

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.

Mon, Oct 7, 5:29 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

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.

Mon, Oct 7, 12:05 AM · efl: api

Thu, Oct 3

tasn added a comment to T8306: RFC: new markup (and attributes).

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)

Thu, Oct 3, 7:42 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

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?

Thu, Oct 3, 7:21 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).

Ahhh you mean backward compatibility?

Thu, Oct 3, 7:19 AM · efl: api
tasn added a comment to T8215: Implement efl2_text_serializer_markup.eo.

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

Thu, Oct 3, 6:43 AM · efl: api
tasn updated the task description for T8306: RFC: new markup (and attributes).
Thu, Oct 3, 2:31 AM · efl: api
tasn added a comment to T8306: RFC: new markup (and attributes).
  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?
Thu, Oct 3, 2:17 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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,

Thu, Oct 3, 1:52 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Thu, Oct 3, 1:44 AM · efl: api
tasn created T8306: RFC: new markup (and attributes).
Thu, Oct 3, 1:43 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Thu, Oct 3, 1:30 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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.

Thu, Oct 3, 12:34 AM · efl: api
tasn updated the task description for T8250: Implement efl2.ui.text (based on efl2.text.raw_editable) - including new theme structure.
Thu, Oct 3, 12:31 AM · efl: api
tasn added a comment to T8298: Efl2.Input.Text.

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

Thu, Oct 3, 12:16 AM · efl (efl-1.24), efl: api
tasn closed T8226: RFC: input_panel functions on Efl.Ui.Text as Invalid.

Moved discussion to T8298

Thu, Oct 3, 12:15 AM · efl: api
tasn closed T8226: RFC: input_panel functions on Efl.Ui.Text, a subtask of T8151: RFC: Text interfaces design proposal, as Invalid.
Thu, Oct 3, 12:15 AM · efl: api

Wed, Oct 2

tasn updated the task description for T8250: Implement efl2.ui.text (based on efl2.text.raw_editable) - including new theme structure.
Wed, Oct 2, 8:42 AM · efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

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.

Wed, Oct 2, 6:13 AM · efl (efl-1.24), efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

Ah oops, already released. :(

Wed, Oct 2, 6:12 AM · efl (efl-1.24), efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

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

Wed, Oct 2, 6:11 AM · efl (efl-1.24), efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

Let me explain what I meant:

Wed, Oct 2, 6:04 AM · efl (efl-1.24), efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 6:02 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 5:38 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 5:07 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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)

Wed, Oct 2, 4:35 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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.

Wed, Oct 2, 4:12 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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"

Wed, Oct 2, 3:50 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 3:30 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 3:21 AM · efl: api
tasn added a comment to T8299: Efl.Text_Cursor.
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.

Wed, Oct 2, 2:56 AM · efl (efl-1.24), efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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.

Wed, Oct 2, 2:49 AM · efl: api
tasn closed T8194: Remove efl_canvas_text.eo and keep the only the legacy API for textblock as Resolved.

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

Wed, Oct 2, 2:46 AM · efl: api
tasn closed T8194: Remove efl_canvas_text.eo and keep the only the legacy API for textblock, a subtask of T8151: RFC: Text interfaces design proposal, as Resolved.
Wed, Oct 2, 2:46 AM · efl: api
tasn closed T8193: Extract edje_entry into its own object that inherits from evas_canvas_text as Resolved.

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

Wed, Oct 2, 2:26 AM · efl: api
tasn closed T8193: Extract edje_entry into its own object that inherits from evas_canvas_text, a subtask of T8151: RFC: Text interfaces design proposal, as Resolved.
Wed, Oct 2, 2:26 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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

Wed, Oct 2, 2:20 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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.
Wed, Oct 2, 2:09 AM · efl: api
tasn added a comment to T8303: RFC: changing back style/attribute handling to format strings rather than an interface.

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.

Wed, Oct 2, 2:03 AM · efl: api
tasn added a comment to T8226: RFC: input_panel functions on Efl.Ui.Text.

Thanks

Wed, Oct 2, 1:30 AM · efl: api
tasn updated the task description for T8303: RFC: changing back style/attribute handling to format strings rather than an interface.
Wed, Oct 2, 1:30 AM · efl: api
tasn created T8303: RFC: changing back style/attribute handling to format strings rather than an interface.
Wed, Oct 2, 1:29 AM · efl: api
tasn added a comment to T8226: RFC: input_panel functions on Efl.Ui.Text.

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

Wed, Oct 2, 12:09 AM · efl: api

Tue, Oct 1

tasn added a comment to T8296: efl2.canvas.text.

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.

Tue, Oct 1, 11:35 PM · efl (efl-1.24), efl: api
tasn added a comment to T8296: efl2.canvas.text.
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.

Tue, Oct 1, 11:32 PM · efl (efl-1.24), efl: api
tasn added a comment to T8296: efl2.canvas.text.
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?

Tue, Oct 1, 11:23 PM · efl (efl-1.24), efl: api
tasn added a comment to T8301: Efl2.Text.Item.Factory.

Also going to overhaul

Tue, Oct 1, 1:25 PM · efl (efl-1.24), efl: api
tasn added a comment to T8300: Efl2.Text.Markup.

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

Tue, Oct 1, 1:25 PM · efl (efl-1.24), efl: api
tasn added a comment to T8290: replace legacy text widget usage in eo-based widgets.

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

Tue, Oct 1, 1:23 PM · efl: api
tasn added a comment to T8297: Efl2.Text.Content*.

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

Tue, Oct 1, 1:22 PM · efl (efl-1.24), efl: api
tasn added a comment to T7855: efl.text_font.

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.

Tue, Oct 1, 1:19 PM · efl (efl-1.24), efl: api, efl: language bindings
tasn added a comment to T8298: Efl2.Input.Text.

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.

Tue, Oct 1, 1:18 PM · efl (efl-1.24), efl: api
tasn added a comment to T8299: Efl.Text_Cursor.

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!

Tue, Oct 1, 1:16 PM · efl (efl-1.24), efl: api
tasn added a comment to D9570: efl_ui_text_editable: remove Efl.Ui.TextEditable class.

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.

Tue, Oct 1, 1:27 AM · efl
tasn added a comment to T8193: Extract edje_entry into its own object that inherits from evas_canvas_text.

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

Tue, Oct 1, 1:25 AM · efl: api
tasn added a comment to T8289: efl text widgets.

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.

Tue, Oct 1, 1:19 AM · efl (efl-1.24), efl: api
tasn added a comment to T8290: replace legacy text widget usage in eo-based widgets.

Great initiative, that would be great, thanks!

Tue, Oct 1, 12:49 AM · efl: api