Summary:
Elm.Widget.event_callback_add conflicts with Efl.Object.event_callback_add.
To solve this problem, "widget_" prefix is added to methods starting with
"event".
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4521
Summary:
efl_ui_menu interface provides common functions of menu, toolbar and ctxpopup.
efl_ui_item interface provides common functions of menu_item, toolbar_item and ctxpopup_item.
Also implemented some missing functions like selected_item set/get in ctxpopup.
efl_ui_item interface should be used for other widget items as well.
Test Plan: elementary_test
Reviewers: jpeg, felipealmeida, raster, SanghyeonLee, cedric, yashu21985
Subscribers: bu5hm4n
Differential Revision: https://phab.enlightenment.org/D3897
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
Summary:
if trying to apply incorrect theme, widget apply default theme and return TRUE.
so there is no way to check it really apply correct theme.
To resolve this problem, _elm_theme_set return three type enum
* related history : 4ca3ef4514
* elm_object_style_set is public api, so I didn't change it.
* typedef name [ Theme_Apply ] is temporarily, please suggest better one.
@fix
Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4073
This allows apps to set the objects min size with hint_min,
while letting the rest of EFL define the minimum size with
rstricted_min.
I don't like the property names much...
@fix
Summary: fixx auto_hide mode to work correctly
Test Plan:
1. launch elementary_test - ctxpopup
2. click normal ctxpopup and auto_hide ctxpopup sample
3. check the auto_hide function whether it is work well or not
Reviewers: Jaehyun_Cho, raster, jpeg, cedric, singh.amitesh, DaveMDS, Hermet
Reviewed By: DaveMDS
Differential Revision: https://phab.enlightenment.org/D3967
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.
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.
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.
Set and get functions are inconsistent one with the other. When set
function is used with a certain value, one expects the get function
to return this value.
Jee-Yong Um
Jean-Philippe Andre
Amitesh Singh
Tom Hacohen
Jee-Yong Um
Vitor Sousa
Jinyong Park
Ji-Youn Park
Hermet Park
Taehyub Kim
Daniel Zaoui
Cedric BAIL