This is a protected function. It doesn't need to return anything, as all
implementation just returned true, always. Also, the legacy API was just
a wrapper doing nothing special (except verify that we have a widget,
which the recursive code already does).
Tested with fr_FR :)
Ref T5363
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
Ref T5363
Also prefix with widget.
I want to rename this as child rather than sub. It's inconsistent with
the other parent/child hierarchies. Anyway the various hierarchies are
confusing, so let's keep this name :)
Ref T5363
This factorizes the code and makes most widgets handle key down events
in the same way:
- check that the object is not disabled, event is not on hold
- figure out the key binding based on the class name
- mark event as on hold
The class name is usually MY_CLASS_NAME but in some cases it was
MY_CLASS_NAME_LEGACY which may be different from the EO class name (eg.
elm_win vs. Efl.Ui.Win). In that case the key bindings are broken.
This breaks key bindings for the following widgets:
- Win (focus)
- Image ("clicked")
- Video (move, play)
This fixes key bindings for the following widgets:
- Nstate
Some widgets remain broken:
- Photocam / Efl.Ui.Image.Zoomable
A patch will be applied to restore the key bindings for the above
breaks.
This is an internal function that should probably become an overridable
protected method, as it's required for proper event handling in widgets.
Next step: use eo_event_info in the widgets implementations. Then remove
legacy event struct.
Ref T5363
This removes an argument that was false only for a single widget:
naviframe. Hopefully this logic is now simpler, even though it involves
a small hack within naviframe itself.
Ref T5363
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
This fixes compilation for terminology for example.
Thanks to @Etrunko for the report.
Note: My builds originally worked fine because my installed
include folder contained the old files :(
This is an override of efl_gfx_size_set. Same as before, the
order of operations matter so it is possible that a corner
case will break. In particular, legacy code was:
- intercept
- smart resize (do stuff), super, super, super
- evas object resize
The new code is more like:
- intercept
- super, super, super, evas object resize
- do stuff
But unfortunately this broke elm_widget (read: all widgets) as
the internal resize was done before the object resize. So,
inside the resize event cb, the resize_obj size would not match
the smart object size. >_<
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
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...
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.
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.
Jean-Philippe Andre
Jee-Yong Um
Vitor Sousa
Tom Hacohen
Jinyong Park
Cedric BAIL