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
It seems that theme_apply in sub_object_add haven't worked since commit
f6fa1ef612.
scale, theme property will be set properly when the parent is changed.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8283
It seems that theme_apply in sub_object_add haven't worked since commit
f6fa1ef612.
scale, theme property will be set properly when the parent is changed.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8283
efl_ui_widget has a property called widget_parent. The setter for this
function is called is exactly once, and this is within the constructor,
to a value which is not even set to the actaul field parent_obj. Which
shows, that in the sitation right now, the setter of the property is a
bit disconnected and lags some real aspects.
As we are heading towards eo-api stabilization we should beat some sense
into this setter, as people using our classes might overwrite the setter
and except calls to it, whenever the widget_parent is changed, and
implementation as in elm_menu show that this might makes sense sometime.
In order to achive this, the sub_object registering code of elm is
adjusted a bit.
sub_object_add/del is now used to differenciate between evas objects and
efl.ui.widget objects as subobject. In case of a widget, the
widget_parent of this object is set, most of the widget specific code is
then executed in the actaul setter. In case of an evas object, the
parent reference is added. In the end both end up in the subobject
children list. The later is also a requirement for widget_parent_set to
be successfull.
ref T7553
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8031
This means that all property that are registered in the reflection table of
any Eo class will be available for binding with a model. This will increase
the amount of useful binding quickly.
Reviewed-by: Vitor Sousa da Silva <vitorsousa@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D7941
this is a legacy header so it can't include (non-installed) eo headers
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8229
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/D8209
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/D8148
this takes the current generated output from eolian for legacy code in
evas 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/D8131
Summary:
now that the error codes have been change to be compatible with eina_error,
this can be removed and will work through eina_error naturally
fix T7718
Depends on D8067
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7718
Differential Revision: https://phab.enlightenment.org/D8068
Summary:
this can be mimicked with efl_provider_find as the top widget should
always be efl.ui.win
ref T7553
Depends on D8063
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7553
Differential Revision: https://phab.enlightenment.org/D8064
Summary:
this swaps the values of "no error" and "error" in order to maintain
consistency with the rest of efl where the zero value means "no error"
Depends on D8060
Reviewers: cedric
Reviewed By: cedric
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8063
summary_:
pd->logical.child_count is a counter where focusable children do
register themself in the parent if they can be focused or not. With this
we don't need the updating of this internal flag nor the flag itself anymore.
Depends on D8027
Reviewers: woohyun, cedric, Jaehyun_Cho, zmike, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8030
summary_:
interest_region_mode makes it possible, that interest_region_get either
returns WIDGET or ITEM coordinates. However, efl-api does not have
items. That means, this can be legacy.
ref T7553
Depends on D8026
Reviewers: woohyun, cedric, Jaehyun_Cho, zmike, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7553
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8027
summary_:
show_region is simular to focus_region. However, it builds up on setting
custom functions per setter to the widget, which are then executed. This
can be solved better by overwriting the interest_region getter, and
using a function like elm_widget_focus_region_show (This function still
needs to find its place in the eo api).
ref T7553
Depends on D8025
Reviewers: woohyun, cedric, Jaehyun_Cho, zmike, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7553
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8026
summary_:
the widget implementation just redirected calls from efl_ui_widget to
efl_ui_win. Which makes the properties unncessesary on the widget. This
commit moves them now to the window.
The legacy implementation of the window can now go away, as this is
taken care of by eolian directly.
ref T7553
Depends on D8017
Reviewers: woohyun
Reviewed By: woohyun
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7553
Reviewed-by: WooHyun Jung <woohyun0705@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8025
before the disable property was a bit weird. Setting something to
disabled=true will disable all children of the widget that is changed.
However, only the update function of the children will get the false flag,
not the flag itself. Which means, to query the real disabled state, we
need to walk up the parent relations.
With this patch, every change to disabled will go through the disabled
property, which mean, a implementor can just overwrite the disabled
property, and adjust its internal state there. Just be carefull, a set
to disabled=true still might result in disabled=false. This makes the
function on_disable_update unneccesary. Which also cleans up the
Efl.Ui.Widget class.
ref T7553
Depends on D8016
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8017
The new api is moved into either Efl.Ui.Win or Efl.Ui.Layout.
Only Efl.Ui.Layout is interested in the rotation, as this is the only
widget that can actaully apply it to the theme. The value itself however
is unique to the window, which means, the window is the only point where
the rotation is stored, and this is the point, where rotation changes
are brought to the layouts.
ref T7553
Depends on D8014
Differential Revision: https://phab.enlightenment.org/D8015
Summary:
api naming in efl uses 'del' when deleting an object and 'remove' when
removing something from an object
ref T7554
Depends on D8034
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7554
Differential Revision: https://phab.enlightenment.org/D8035
Summary:
most widgets inherit from layout to provide implementations for common
functionality such as content/text/theme get+set.
one of the things that layout also brings into its inheritance hierarchy
is efl.file and implementations for its methods. this becomes a problem
when the widget which inherits layout also wants to provide implementations
for efl.file methods (e.g., entry, which uses efl.file to load text files)
as it will result in calling all of the efl.file implementations up the
chain.
in the case of entry, this could result in the 'file' property eventually being
set to the current theme file in use by the entry's layout object, and then the
entry will attempt to autosave its content to the default theme file when it is
destroyed, corrupting the theme file and breaking everything
to solve this:
* efl.ui.layout remains an instantiable class which implements efl.file
* efl.ui.layout_base is the abstract class which provides all the methods of layout
but should be inherited by all widgets which want to implement efl.file functionality
Depends on D8018
Reviewers: bu5hm4n, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8032
Summary:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018