User Details
- User Since
- Jul 24 2013, 3:26 AM (277 w, 3 d)
- Availability
- Available
Yesterday
updated as @segfaultxavi commented
Thank you :)
Thu, Nov 15
I was thinking about app can catch events like android activity catches events.
https://developer.android.com/reference/android/app/Activity#dispatchTouchEvent(android.view.MotionEvent)
Wed, Nov 14
I updated the examples not to use legacy APIs and the examples are generated and executed correctly :)
I think that we need to separate this topic into 2 major topics clearly.
Tue, Nov 13
Added example executable files to elementary.mk
Mon, Nov 12
I got the point about namespace separation.
Sorry for the mixed APIs
Updated the examples
I added examples for efl_ui_theme.
Added example source and theme files to elementary.mk file
Added examples
Sun, Nov 11
Rebased
Fri, Nov 9
fixed the documentation typo and rebased
Wed, Nov 7
Could you check the usage of legacy class and APIs as we talked?
Two patches are mixed up in this patch.
Thu, Nov 1
@cedric
I didn't know about @class eo option which makes static function.
Thanks for your help.
Thank you for feedback. I want to discuss about supporting singleton class with you.
I think that this patch requires something more like marshaling. (Especially for elm_object_theme_get() and elm_theme_ref_get().)
I am not sure if marshaling similar to Eo marshaling should be applied to this case as well.
Wed, Oct 31
BTW, what do you think about changing class name Efl.Config_Global to Efl.Ui.Config?
What do you think about introducing Efl.Ui.Theme for elm_theme APIs?
Tue, Oct 30
As you know, at least we provide Efl.ConfigGlobal.SetConfig(System.String name, Eina.Value value) now. So app developers can use this function although it is not that easy to use this function.
@segfaultxavi
I totally agree with you. For now, we have only one case (i.e. @ctor_param style) so we don't need to consider @optional or @essential.
@q66 ping?
Wed, Oct 24
For now, I cannot think of any case not related to Widget.. (I think it would be rare that app developers modify non Widget class by using inheritance)
I agree with you! Please push modifications which are not related to dealing with mixin :)
Mon, Oct 22
@segfaultxavi
Yes, it is essential to extend EFL from C#. This is not only for C# application developers but also for C# framework developers like us.
@segfaultxavi
Of course we need to support inheritance from efl# classes to user-defined class without defining EO and C file.
@bu5hm4n
I am not sure if user-defined C# class works for Efl.Ui.Focus.Layer's focus_state_apply. (at least it is not crystal clear that it works based on C# class hierarchy..)
Let's think about C# application developer wants to create a class inheriting Efl.Ui.Focus.Layer to apply Efl.Ui.Focus.Layer's focus_state_apply.
From widget's behavior POV, it is fine. But I think we need to resolve multiple class inheritance issue in C# beforehand.
In the latest devs/lauromoura/csharp-new-classes branch, all the duplicated re-implemented methods are removed. (parent's methods are used instead)
e.g. Efl.Ui.Widget.FocusStateApply() is not re-implemented in Efl.Ui.Layout.Object because efl_ui_layout_object.eo does not implement focus_state_apply.
Fri, Oct 19
@bu5hm4n
Thank you for information :)
Oct 10 2018
Oct 7 2018
Oct 4 2018
@segfaultxavi @bu5hm4n
Thank you for your explanation. It helps my understanding about Eolian clearly.
Oct 2 2018
I think this patch should be applied to upstream to resolve doxygen ingroup name issue.
D7126 is more general patch.
Oct 1 2018
Sep 27 2018
Sep 26 2018
I think we don't need to consider the case that user inherits from mixin.
Because we are considering that EFL C# bindings generator removes mixin. (user cannot inherit from mixin because it does not exist.)
e.g. mixin Efl.Access.Object is removed in C# but its @property state_set { get; } is added to abstract class Efl.Ui.Widget in C#.
Let me clear with an actual example. Otherwise, I think we will miscommunicate.
I am discussing how to resolve multi class inheritance with mixin in C# bindings.
Because now C# bindings work is blocked by how to treat mixin in C# bindings..
So I am suggesting what form would be good for mixin in C# bindings.
Yes I understood same way about @felipealmeida comment.
Sep 25 2018
Yes, that is one of options.
Sep 24 2018
You idea (converting "mixin" in eo to "interface" in C# binding) is a solution.
But as you said, it requires we need to remove inheritance from abstract class, regular class to mixin in eo. And I think this is quite difficult.
Sep 21 2018
Sep 20 2018
This is internal API so do not need to do null check.
As you know, while we discussed in Korea together, we haven't discussed how to resolve abstract inheriting from regular class because we did not know that this case exists.
Sep 19 2018
Sep 17 2018
I guess there is no objection about your proposal :)
Sep 12 2018
- You can already set the style of any widget now
After discussing about this topic with @woohyun, we realized that we need to support "style" parameter for all widget constructors.
Sep 11 2018
I am wondering if you expect that the new form supports IntelliSense.
Sep 10 2018
efl_ui_widget.eo
class Efl.Ui.Widget {
@property style { ... } constructors { style }}
efl_ui_widget.eo.cs
class Efl.Ui.Widget {
public Widget(efl.IObject parent = null, string style = null, ConstructingMethod init_cb=null)}
This is more general than adding a special case for styles, so I like it more.
@Jaehyun_Cho would you like this solution? a lot of details have to be worked out yet.
I am afraid that the named parameters are not more convenient than basic API usage. (e.g. button.SetSize();)
Now the multiple class inheritance from abstract and class reported by @lauromoura has been removed. (Class Elm.Combobox is legacy so it is not related to C# bindings)