|interface Efl2.Text.Content.Markup |├ (P) markup | |interface Efl2.Text.Content.Plain | |├ (P) text | |├ (P) bidi_delimiters
|Open||None||T7510 evaluate stabilization potential of efl.ui classes and dependencies|
|Open||None||T8289 efl text widgets|
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.
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.
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.
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.
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
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