Language bindings for .eo files
Separating them looks like a very good idea, we can still later in refactor common out out of them, and stuff this code into a common place like a shared header file, no need to make it in a class.
The Interval thing also might not fit into the range_interactive API, so this sounds very good to me.
@zmike your opinion ?
@herb thanks for the updates on this. I already have nearly everything done at this point, so it should be simple to complete the work by the end of the week at the latest.
As @bu5hm4n talked before - there are lots of bad things in both efl_ui_slider and efl_ui_slider_interval.
I talked with woohyun about this refactoring for popup,
we have to finish this task until early september since we will start the release for EflSharp after the middle of september.
please take care of this schedule.
Ok. I'm moving to Action Item #3.
If anyone has another idea on the slider class (and it needs big change), please let me know asap :)
i think so :)
The application developers in tizen need two types of popup such as context style and alert style
In case of the context style like elm_ctxpopup of efl needs priority align feature because the context popup should be shown depending on mouse position and in the screen boundary.
when the context popup is created near the screen boundary, the priority is used to find the optimal position of the context popup which the user wants.
In case of the alert style like elm_popup of efl needs align feature because some developer want the popup to be aligned whenever the screen is resized.
However If there are some ways to set the priority using algin hints or find optimal position, I think we can remove the priority set API :)
Mon, Aug 19
This example in c also do the app to freeze when using a table, with a tangling pointer for a button while other elements, like a box with a tangling button don't behave that way.
@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.
Sun, Aug 18
Fri, Aug 16
Cool, thank you!
I will try the work item #2, and try to estimate the things you are worrying about.
The problem is, those works give a really big change on how the interface interacts, as right now event emission is pretty messed up, and a lot more events are emitted than we actually need ... I am not sure if we get arround resolving that before declaring it stable.