Language bindings for .eo files
Thank you very much !
I'll get info from @ali.alzyod on how to separate the implemetation.
I will try to remove it today, i have just too many things to do, its hard to get anything done tbh.
Mon, Jan 20
Ok :) Let's move this to "stabilized" !
If we don't have a plan to remove "_efl_ui_textblox_efl_layout_signal_signal_callback_add",
I hope to talk about this in another task to focus on textbox relating things :)
Move to "stabilized" !! Thanks :)
I cannot find my homescreen demo app anymore :( spotlight is used in efl_ui_editor, it also has some demos in elm_test. @Jaehyun_Cho are there any Demos you could share that are using Efl_Ui_Spotlight / Stack / Pager ?
Looks good to me!
Did you finish your homescreen demo app? That should give us a taste of how usable the API is.
Okay, this has been silent for so long, so it's time to remove the @beta, everyone fine with that ?
Signals are sadly no events.
Well, the obvious solution is that the textbox should intercept the resize obj's signals and emit its own signals, no?
The user does not know about any internal object, so the textobj must proxy everything.
And the other classes with the same problem should do the same :(
Ah, sorry :)
This happens because we simply attach the callback in the impl to the internal resize object, and do not handle the emitting by hand at all...
Yeah, I get that :)
My question was "why does this happen?". Is it an implementation bug or a design issue?
The problem is: when the func is called there, the Object passed to the function pointer is not the object you added the callback on.
I have no further comments.
Are you ok with current definition ~ then, I hope to move this to "stabilized".
If we don't have a plan to extend Eina_XXX_Range later (for other data types),
then I also agree that we need to call this as "Eina.Range" (instead of "Eina.Int.Range").
Sun, Jan 19
I think we should call this new type Efl.Range which is the default range (and I agree with what @cedric says, there should not be more ranges other than this one)
I am not convinced of the need for double, otherwise yes.
Are you ok with Eina_Int_Rage (in D11128) ?
If we have a plan to add Eina_Doulbe_Range, and so on ~ I think this idea looks good.
It feels weird tu remove functionality that was in legacy. I would keep input_hint as Beta and rename it to input_content_type, but not remove it.
Is it possible to annotate interface implemnetaiton as @beta ? (this is for file interface)
Okay then, let's move this to "stabilized" :)
Fri, Jan 17
In this case, I'm OK with moving this to Eina.Int_Range.
I am unlikely to have the time to take care of that, but I should be able to review the patch in the next 2 weeks.
Hum, it seems we are getting to a logical point where indeed range is a useful structure to add to Eina.
what do you suggest? I look at other parts of the toolkit, and they use it the same way as in efl.ui.textbox (like efl_ui_image_zoomable and efl_ui_layout_base)
I am okay with the API side, only one thing impacts the API right now:
- _efl_ui_textbox_efl_layout_signal_signal_callback_add still has a problem, the object of the function callback will be wrong