Page MenuHomePhabricator

Efl2.Text.Content*
Open, TODOPublic

Description

|interface Efl2.Text.Content.Markup
|├ (P) markup

| |interface Efl2.Text.Content.Plain
| |├ (P) text
| |├ (P) bidi_delimiters
zmike created this task.Oct 1 2019, 9:10 AM
zmike triaged this task as TODO priority.
zmike added a comment.Oct 1 2019, 9:12 AM

Efl2.Text.Content.Markup is T7858
Efl2.Text.Content.Plain is T7854

I'm not sure I see the point of renames here; also Efl.Text is stable, so this cannot be changed. The bidi_delimiters property could easily be added, however, so I'm not entirely certain why these exist?

tasn added a comment.EditedOct 1 2019, 1:22 PM

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

As for this, have we released it, is it too late to change it as a last minute fix?

Edit: as we are only talking about .eo file stability here, not even API/ABI as the c_prefix remains the same.

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

I'm not sure I understand your argument here. Just because an interface has been stabilized doesn't mean that it can't have methods/properties/events added to it. My comment about Efl.Text being stable was with regard to the name of the interface and its existing property, not its ability to receive new features.

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

Let me explain what I meant:

I was talking about Efl.Text existing means we can't have Efl.Text.Some_Other_Class/Enum/Interface. It's hogging the name space.
Eo/Eolian was actually fine with it in the past, it's a recent regression though because of the bindings (an unnecessary one, which is why I was complaining).

So I'm saying having an interface with such as name essentially blocks a very useful namespace.

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

Aha, I see.

That is indeed quite an issue.

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

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

Is there a way to fix this before the release?

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

Ah oops, already released. :(

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

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.

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

Do we really need two interfaces? we can combine them into one interface, since no one really uses interface Efl2.Text.Content.Plain but instead will use interface Efl2.Text.Content.Markup
So I think combining them into one make sense.

interface Efl2.Text.Content
|├ (P) markup
|├ (P) text
|├ (P) bidi_delimiters
tasn added a comment.Oct 14 2019, 11:22 PM

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.

zmike added a comment.Oct 15 2019, 5:37 AM

I think it's fine to continue having them be separate; the point of interfaces is to break them into manageable chunks of API which can be incrementally applied as needed rather than force nonfunctional API across all possible objects.

Are there any reason for button or other widgets to not implement Efl.Text.Content.Markup instead of Efl.Text.Content.Plain
I think it is great feature and already implemented, so why not to use it

tasn added a comment.Oct 15 2019, 9:02 AM

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

In T8297#145463, @tasn wrote:

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

Now things are clear, It is hard to read Button class and knowing how it is constructed
Thank you