Most of these functions actually shouldn't be used by
standard applications. Some are hidden behind @protected.
flush_all() and reload() have not been implemented, on
purpose (save() should flush, and reload is automatic).
This is to port elm_config to EO APIs.
The current implementation relies on the legacy API, by
simply forwarding calls.
The new API is simply efl_config_set("config_name", value)
where value is an Eina_Value (aka. generic_value).
The C interface proposes a few helpers like config_int_set,
config_double_set, etc...
Unfortunately at the moment, not all config options are
supported, as some rely on more complex types:
- lists
- color class and multiple arguments
- unset functions
- enums
Profiles are also not handled at this point.
@feature
We can not assume that the elementary parent will be also somewhere in the eo parent
hierarchy. We need to explore both when doing an eo_provider_find in elementary for it
to be really useful.
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
Summary:
When the widget is unset from any container, a parent of the widget
doesn't exist. So we should set its parent to the top object.
But if we just set sd->parent, the parent can not find the widget as a
child. So the container widgets set the parent-child relation when
sub object is unset.
This commit is related to 0822ad2195.
@fix
Test Plan:
Check this issue.
https://phab.enlightenment.org/D3855
The unset widget don't added any widget as child.
So when it set scale, the widget can not reload the thmeme.
Reviewers: raster, cedric, Hermet, reutskiy.v.v
Reviewed By: Hermet, reutskiy.v.v
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3957
Conflicts:
src/lib/elementary/elm_mapbuf.c
This touches Edje and also Elementary where part names are used.
This commit blew up in size since now all content part APIs
(get, set, unset) require to use Efl.Part instead.
This is a big refactoring commit, but no logic should
have been changed. Fingers crossed.
Previously events used to use class name as a prefix and ignored eo_prefix
when specified. This is no longer the case. Events follow eo_prefix by default
now. In order to get around this for classes where this is undesirable, a new
field event_prefix was added which takes priority over eo_prefix. If neither
is specified, class name is used like previously.
@feature
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
Efl.Container instead.
The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.
Some function names have been modified to look better in C
with the efl_content prefix.
@feature
This removes the conflicts between the different parents and also
indicates that this is to be used internally by widgets and should
not be confused with the normal user visible parent.
It is an internal attribute that should not be used by people
not implementing widgets. Marking it as protected signifies it
as such.
Since focus_clear removed all the focused traces, focus was not reverted well
whenever win lost and got focus repeatedly.
For instance,
1. set focus to button1
2. set focus to button2
3. win focus out and in
4. remove button2
5. focus is on win not on button1
So, focus logic changes to not clear focused states when win loses focus.
@fix
Setting the no-render flag on an elm widget had no effect,
as it was not properly propagated to its children. This should
fix that, but I'm not a fan of the solution.
Fixes T3371
Jean-Philippe Andre
Tom Hacohen
Ji-Youn Park
Cedric BAIL
Jaehwan Kim
Daniel Kolesa
WooHyun Jung