7321911468 moved the constructor to to
top, which leads to the fact that a few widgets cannot fetch the shared
data of the window. Which made the test suite fail.
With this commit we are just moving the sub_object_add after the
constructor, which fixes the flip crash.
This fixes the test suite
the object is not properly set up yet for child classes -0 parent like
the main evas object or smart obj havent been constructed yet so call
this really early, not in the middle of construction of an efl ui
widget...
this fixes a segv in elementary_test -to filp where it segv's on
object construction where evas object ->cur/prev are NULL (not set up
yet).
Efl.Color and Efl.File cannot be done due to composition. Efl.Gfx.Image
can, so we can solve this via composition, this also resolves all the
other cases for Efl.Gfx.Image.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9991
Summary:
first of all, in efl-ui we should probebly ensure that a widget is
always created in a window object. Otherwise we are looking for trouble.
Additionally, calling efl_ui_win_shared_data_get on anything else than a
window object will result in a returned NULL value.
If we are not having a widget parent, there is also not much point in
calling a API that is only defined on the widget base class, so we also
move that away
Reviewers: kimcinoo, raster
Reviewed By: kimcinoo
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9762
Summary:
`Efl_Ui_Scrollable_On_Show_Region` is only used for legacy EAPI. it moved to
elm_widget.h from eo file. also, it renamed `Elm_Widget_On_Show_Region_Cb`.
Reviewers: Jaehyun_Cho, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9896
unload is a crucial method for classes that implement load, as this is
the method which is called during e.g., efl_file_simple_load() when
a new file is specified in order to destroy the previous object data
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9786
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
if we are walking this method twice (spoiler we do!) then we subscribe
twice to the event, which leads (depending on the order of executed
deletion) to the accessing of obj after its deleted.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9684
as an example: elm_test uses roughly 500 widgets, this pointer takes 8
bytes, this is wasting quite some time, which can be perfectly safed by
just structuring the code a little bit more. In some callbacks we need
to call one more time efl_data_scope_get but that is not a that big
issue, as most calls after that are also doing a eo call on that object,
so the eo_id is already cached.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9683
since 2dd596084b, tree_unfocusable is changed from
Eina_Bool to int.
Double negation ensure binary return value of `elm_widget_tree_unfocusable_get`
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9673
this has to use tree_unfocusable not disabled.
ref D9644
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9671
Dereference null return value issues is reported by Coverity.
If `sd` is NULL, it will return zero values.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9668
this is used for storing the position and size of the widget. However,
just in elm_test this eats 2KB of ram, just for saving them. The cases
where they have been used do not seem like a great performance hotspot,
additionally, in the panel cases the privat data of the widget is
achived anyways, so eo is involved and we are spending some time there
anyways.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9646
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
Before this patch tree unfocusable set just set a simple flag, getting
this state however forced you to traverse the whole parent chain to get
the real result.
With this patch the setting of the unfocusable flag is heavier as it
walks all the children of the widget, however, the getting of the flag
is way easier now. The next revision will refactor the focus related
APIs for that.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9644
asking for a parent provider only makes sense if we are having a custom
focus parent provider, otherwise this will just result in the normal
parent relation. Not doing this safes us a lot of time that we spent for
nothing in the focus evalulation code.
The gengrid change is needed as the parent provider should be applied
after the constructor is called, otherwise there is no garantee that
shared_win_data is not NULL.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9643
this introduces a shared place to all widgets. The shared pointer is
allocated in the window, as the window outlifes every widget that is
part of it.
This struct will be later used for further optimizations like:
1. There are really heavy focus operations which are only needed for
gengrid/genlst, there is no point in executing them if there is no
gen**** added to the window object. So we can skip the custom
parent_provider logic that is only introduced for gengrid / genlist.
2. Legacy focus APIs must do list walks, which means, on every focus
operation we always have to walk the full list up to the parent, which
is annoying and slow, as we *most of the time* do not use legacy focus
API.
This list can be continued, the above two cases are fixed in the next
revisions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9642
calling geometry set here is again calling the API in canvas object that
splits this call to size_set and position_set which means we spent quite
a bit of time in eo, just to call the same APIs we could call directly.
With this commit here, the calls are directly going to the right
objects, with the right API.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9619
Summary:
historically there have been two methods of calculating sizes in elm:
* elm_layout_sizing_eval
* evas_object_smart_calculate (now efl_canvas_group_calculate)
the former was used to set size hints on widgets, while the latter was
used to perform internal size calcs for the widget. for things to
work correctly, these functions had to be triggered in just the right
order at just the right time. many hard-to-fix bugs related to widget
sizing over the years have been the result of this split
this patch removes elm_layout_sizing_eval implementations so that all
widgets perform both internal size calcs and size hint setting all
in the same function, ensuring that these are always in sync
the result is that in the vast majority of cases, far fewer recalcs
happen for widgets, and they are quicker to achieve their final size
Depends on D9438
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9439
somehow it was never checked to see if a parent was being added as a subobject
of a parent's own child object (recursive hierarchy)
@fix
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9333
This is done to simplify code as you only need to set the model on the
provider and all the widget that are using it as a provider will automatically be
updated. The child will find a provider during at the time the first property binding
is set on the widget by checking if the parent have an Efl.Model_Provider set. It is
not necessary to set a model to have a valid lookup on a Efl.Model_Provider. To disable
a widget lookup, you can just force set a model on it (even NULL) and it will disable
the lookup.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9290
there is a very basic problem in eo events. We are having one central
array of event subscription, if for example a widget is now listening to
changes in its parent, then we are 100% asking for trouble.
As an example:
- A scroller with 100 buttons in it.
- Every button will have a subscription to the FOCUS_MANAGER_CHANGED
event
If you now scroll, the position is updated in the scroller, therefore
the position in scroller is updated. This has the result that the whole
list of 100 event subscriptions is walked, which is obviously bad,
however, this solution here is way easier than fixing eo (i am not even
sure there is a nice solution to it).
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9324
when a logic parent does not have any widgets left, the parent needs to
be reevaluated. However, this only has to happen when there is a change
in state (eg. from 0 -> N or from N -> 0). Every other call can be
safed. This commit introduces this checking, and safes up performance.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9323
checking part type and part geometry is pretty common, so these base
implementations can fill in gaps in existing functionality
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9317
this commit ensures 2 things:
1. This ensures that the parent is not evaluated when there was no state
changed, this cuts down roughly 30% of the calls to full_eval
2. This ensures that we only listen to parent manager changes when we
are actaully registered. This reduces the amount spend in event emission
a lot.
Summary:
no need to update access info for dead objects
@fix
Depends on D8983
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8984
when a widget is marked internal, widgets can use that to behave in
certain ways. Box for example uses this to not alter the widget_parent
property anymore. Which is usefull for when boxes are used internally.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8736
since commit a1addad60e, To add myself as a sub object of parent object will be
done in Efl.Ui.Widget constructor.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8280
we are calling visible_set on them later on, this will drop errors,
additionally this safes us from checking this in the widget-container
code.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8520
Summary:
The efl_ui_widget_disabled_set calling even the state is not change when widget create and destroy.
It broken backward compatibility.
T7799
@fix
Reviewers: bu5hm4n, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8600
this resolves a lot of cases where focus_highlight API was called on a
object, which is not a efl_ui_win object. With this patch we ensure that
the object is always a window.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8476
the problem with the previous implementation (just redirect the calls to
the widget_parent then to the efl_parent is that after invalidate its
impossible to find the window where the widget is in. However, there are
cases where we want to have access to the window of the widget, for
example, to invalidate focus highlight etc..
The window of a widget is always constant, and cannot be changed (as the
evas object cannot hop accross different evas)
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8475
before the refactoring of the disabled property, there was no way to
enable a widget which has a disabled tree. This here however enables
this to work again like this. The user will be told with an error
message. The integraty of the property is maintained accross reparents.
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8459
Summary:
the difference here is, that the macro before did not print ERR's the
one now does. Hence this commit remove two error messages.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8415
Summary:
the difference here is, that the macro before did not print ERR's the
one now does. Hence this commit remove two error messages.
Depends on D8394
Reviewers: zmike, segfaultxavi, cedric, devilhorns
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8395
Marcel Hollerbach
Carsten Haitzler
Xavi Artigas
Yeongjong Lee
Mike Blumenkrantz
Shinwoo Kim
Cedric BAIL
Woochanlee