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
This affects the legacy content_set/get/unset part APIs. This
should avoid some unwanted ERR messages in case an elm_object_
API is used on an elm widget that doesn't implement said API.
What this does is request the widget for the name of the default
part if NULL was passed in. Since some widgets are not elm_layout,
they have to override the API themselves, which is why I made it
an internal EO API (rather than a series of efl_isa()).
In theory, part should never be NULL when reaching the internal
implementation code in the widgets, at least for content.
In EO, efl_part(obj, NULL) should be invalid.
Ref T5629
Summary:
When popup is timeout, notify call hide func, and send time out event to popup.
After popup receiving time out event, popup hide object again,
so hide animation doesn't show.
And notify hide function doesn't send hide signal to block events part,
(but dismiss function send it)
So add that signal.
Test Plan:
1. elementary_test -to popup
2. click first item, "popup+center+text"
3. compare time out event before this patch and after.
@fix
Reviewers: herb, singh.amitesh, Hermet, cedric, raster, jpeg
Differential Revision: https://phab.enlightenment.org/D4780
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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).
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
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:
notify's theme_apply function return value with eo_do_super(... elm_object_widget_theme_apply)
but notify's super class is widget, widget_theme_apply return always ELM_THEME_APPLY_SUCCESS.
so, notify's theme_apply function always return ELM_THEME_APPLY_SUCCESS, if it couldn't apply style correctly.
notify apply style via _notify_theme_apply function, so that function must decide theme_apply function's return value.
Reviewers: herb, singh.amitesh, Hermet, cedric, raster, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D4130
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
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.
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.