It was possilbe to add an image with improper parent object before aa2d94f and
56752e0. This patch makes it possible. Sure there are error messages when user
adds an image object using non widget object as below but you can see image.
ERR<28822>:elementary ../src/lib/elementary/efl_ui_widget.c:4801 _efl_ui_widget_efl_object_constructor() You passed a wrong parent parameter (0x400000007ced (null)). Elementary widget's parent should be an elementary widget.
ERR<28822>:elementary ../src/lib/elementary/efl_ui_widget.c:4803 _efl_ui_widget_efl_object_constructor() No widget data for object 0x400000007ced ((null))
ERR<28822>:eina_safety ../src/lib/elementary/efl_ui_win.c:9450 efl_ui_win_shared_data_get() safety check failed: pd == NULL
ERR<28822>:eo ../src/lib/eo/eo.c:579 _efl_object_call_resolve() in src/lib/elementary/efl_ui_widget.eo.c:256: func 'efl_ui_widget_sub_object_add' (698) could not be resolved for class 'Evas.Canvas'.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9747
walking here the parent chain can be very costly, esp. if you make a lot
of widgets visible or hide them. With this commit we ensure that we only
walk the parent chain when there is a custom chain, which is only the
case in legacy. This gets us about 2-3 FPS on the rpi with the
item_container benchmark.
With earlier commits, tree_unfocusable and disabled is honoring the
whole parent chain, so checking that alone, without the parent chain, is
fine.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9645
Summary:
Coverity reports 2 resource leaks here because old_chain & new_chain
are never freed if we fail to return widget data. Use just
ELM_WIDGET_DATA_GET, manually check for valid 'ppd' and if false we
can just break out of the for loop here.
Fixes Coverity CID1399096, CID1399095
@fix
Depends on D8352
Reviewers: raster, cedric, zmike, bu5hm4n, stefan_schmidt
Reviewed By: cedric, bu5hm4n
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8353
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8171
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8169
the event now math the pattern of <property-name>,changed.
ref T7571
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7989
focus,changed is already used in efl_ui_focus_object, which makes sense
there. However, here we listen for the property focus_manager, thus its
renamed to focus_manager,changed.
ref T7571
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7990
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
Shinwoo Kim
Marcel Hollerbach
Christopher Michael
Mike Blumenkrantz
Jérémy Zurcher
Marcel Hollerbach