Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
they are now handled. The list of parents is walked until a possible
candidate is found or the parent chain is the same then in the next
focused element.
fix T7389
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7404
you can use this now to let the focus move to the widget container of
the passed item.
I know this patch contains a whitespace change, but i have to get out
this whitespace each & every time i am editing the file - which is
annoying. So remove it once, which makes further work easier.
fixes T6183.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7408
with using the new api of efl.ui.focus.object we can resolve a bug that
was pointed out in P243.
Differential Revision: https://phab.enlightenment.org/D7267
Summary:
if not, things are going to fall apart, as manager_top then can be NULL
or invalid. Top has to be a window element, if this is not the case,
then the widget tree of the given widget is dangling somewhere in the
void. Calculating the next object in there or even the active manager
will result in errors, since the active manager is not really the active
manager, but rather just a manager object somewhere in a danging widget
subtree.
Moving the focus into such a dangling widgettree might result in a stuck
focus rect on this object, since the DFS of the focus manager
implementation cannot backtrack anymore into the widgets that are still
part of the widget graph.
Depends on D6531
Reviewers: devilhorns, segfaultxavi, zmike
Reviewed By: segfaultxavi
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6532
Summary:
elm_object_focus_next was not working correctly for objects where obj is
not the focused object.
fix T5940
Reviewers: devilhorns, segfaultxavi, zmike, stefan_schmidt
Reviewed By: segfaultxavi
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T5940
Differential Revision: https://phab.enlightenment.org/D6531