- User Since
- Jan 23 2013, 8:14 AM (358 w, 5 d)
Oct 15 2019
Because the Button widget uses the basic text object which doesn't support markup.
Yup, we have a similar idea in mind.
Sorry, wrong place. I meant: T8215 and the class described there...
Efl2.Text.Content.Markup. See T8297
Oct 14 2019
@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.
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.
Oct 12 2019
Oct 11 2019
Oct 10 2019
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 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).
Updated the description.
Oct 9 2019
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.
Oct 8 2019
OK, just wanted to flag it because it looks like css but it behaves quite differently.
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...
Oct 7 2019
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.
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.
Oct 3 2019
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?
Ahhh you mean backwards compatibility?
I renamed it (per @zmike's comment) to something that makes more sense. It'll sit there with other serializers under this namespace.
- 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.
- 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?
Ahh, so no quotes at all! OK, perfect, thanks.
Could you please reformat what you wrote? I'm not sure what's a quote and what you're actually saying.
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.
@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.
Moved discussion to T8298
Oct 2 2019
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.
Ah oops, already released. :(
It shouldn't be, because this restriction shouldn't (and haven't) be there. Though it is.
Let me explain what I meant:
Again, you misread what I said and this is not actually what's going on.
I understand @woohyun, and I'm sorry for the suggested changes. I wouldn't suggest it if I didn't think it was useful.
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.
(I squashed your commits btw, as they seem to just be renaming in two steps).
There's still work to be done, but the main parts are there.
Why do they want to know the default values? I think this is what really needs addressing...
It's OK even to change the naming, we don't need to change functionality. Any naming changes suggestions?
Oct 1 2019
Also going to overhaul
Will probably change, see my comment in T7855. It's also something I'm thinking of overhauling tomorrow.
Not yet, @ali.alzyod is working on it.
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).
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.
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.
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!
Thanks a lot! Weird though, I thought we disabled PRs on the e github...
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.
Great initiative, that would be great, thanks!