This size hint is only used by naviframe, which is not part of
our EO widgets. I also believe it might be an even more confusing
hint than the others.
I kept the typedef as is in Evas_Legacy.h in case an app is
written using EFL_GFX_ instead of EVAS_...
welm widget weak refered the logical parent slot but never unreffed
the weak ref - ever. this should fix that. in fact it does. one crash
less with:
elementary_test -to "icon standard"
@fix
Test scenario:
elementary_test -to "ExtScroller"
Try and modify a slider's value with the mouse wheel. Bad things
were happenning, as the flag ON_HOLD was not properly propagated
from the slider to the scroller. This is because the legacy
event_info structure inside the eo event info was not updated
with the new flag value.
By introducing a new EO only API, which is meant to remain
internal, we can use a single legacy info structure, fixing
this issue.
Note: In the future this API needs to be internal, not protected.
@fix
After a long search I found that fileselector was not calling
super.group_del on deletion, leading to the use of dangling pointers.
So let's verify that group_del is properly called.
See T4598
This fixes some of the occurences of the following error message
when using eo_debug:
ERR<23101>:eo /home/jpeg/e/core/efl/src/lib/eo/eo.c:1955
efl_data_scope_get() Tried getting data of class 'Elm.Widget'
from object of class 'Edje.Object', but the former is not a
direct inheritance of the latter.
If we're going to call efl_isa, then let's at least do it before
efl_data_scope_get.
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:
scrollable object.
In multiple scrollable case, the target object should be updated.
Because the first object is scrolled. So the parent of the first object should be scrolled.
Reviewers: woohyun, Hermet, jpeg, cedric, raster
Differential Revision: https://phab.enlightenment.org/D4490
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Some conditions seems redundant if assume that height and width
can never be < 0.
Change-Id: I63c297cc8cabbb69fbf7e014596f354e811b8d8e
Reviewers: cedric, kimcinoo, jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4441
After reverting 8a21384759, I figured out how to move
the main menu back to the border group. This time the menu is in the
framespace and its layout algos have been adapted to allow non-zero
root coordinates.
Summary:
Make atspi mixin inherit from Efl.Interface class and add Efl.Object
as it extensions class to gain acccess to destructor function.
This allow to better share code between implementations and avoid possible
mistakes during accessibilityt implementations.
Reviewers: cedric, jpeg, raster, kimcinoo
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4393
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The accessible name is char*, this could confuse API user.
If we provide user callback to get description, an user would return allocated string.
The usage of elm_interface_atspi_description_get/set should be same with elm_interface_atspi_name_get/set
Reviewers: lukasz.stanislawski, cedric, raster
Reviewed By: raster
Subscribers: stanluk, jpeg
Differential Revision: https://phab.enlightenment.org/D4378
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
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
Widgets should simply override efl_gfx_color_set and call
super all the way up to evas object.
Legacy compatibility with call interceptors and early call
abortion (eg. delete_me or obj->layer == NULL) are implemented
with an internal call. See the previous commit introducing the
API.
Most of the smart functions "Efl.Canvas.Group.group_xxx" should
not exist and be overrides of the base object function instead.
Cleaning this up is necessary if we want an EO API for custom
smart objects. This patch is the first attempt at removing a
method (the simplest one).
As for no_render, I wonder if propagating to the children
really is necessary. evas_render should skip them already.
In efl_ui_win, _evas_event_key_cb gives efl_event_callback_call,
though the focused object is not the window itself.
Becuase of this, _propagate_event was called twice for event single
key down.
So, now, _propagate_event returns itself whenever focused object is
not the win but it's called from efl_ui_win's event call.
The problem can be checked with following stpes.
1. elementary_test -> focus
2. Input any directions (ex: Down)
3. Focus movement happens twice for every single input.
Focus highlight can be on the air, when focused object in scroller is
moved by mouse down and move.
So, mouse up is not proper for executing focus_auto_hide.
@fix
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.
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
This event should not be exposed at all, it's not necessary
anymore, EFL_EVENT_DEL already exists and should be good enough.
This does move the callback call a little bit ealier in the del
process, but at first glance, this shouldn't have any impact.
The previous patch 1185c40e50 shows how having
two event types for the same thing (key or mouse input events)
was a bad idea. The only guaranteed order of callbacks is the
priority but even that was not enforced (since legacy or eo
style event had to come first).
Fixes T4310
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
Because of the translation between legacy and eo key
events, the on_hold flag state could sometimes be lost.
Symptom:
elementary_test -to Focus
Click on a button inside the scroller
Up/down would jump to the end of the scroller, rather than
the next button.
Thanks a lot to Woohyeon for the very good bug report.
This is a corner case bug I spontaneously found.
* Scenario.
A. Disable A widget.
B. Add a child B widget to A.
C. Now B Widget theme will be followed to A that is performed by
elm_widget_theme_apply()
D. This elm_widget_theme_apply() calls elm_widget_disabled_set() (originally.)
E. Now B widget will be logically disabled.
D. Let's enable A widget again.
E. After going through widget disabled sequence, elm_widget_disabled_eval()
will be called in the last
F. In this function, A widget tries to enable its children. But B widget won't
be enabled because its logically disabled!
Acutally, nowhere widget change children's disabled states logically,
but it propagates its state to children within volatile way so that
A widget perfectly keeps the disabled/enabled state with its children and
recover the children's enable/disable state once their relationship is cut off.
@fix
This reverts commit 57d77c9041.
We are in freeze right now and this is a new feature. Considering the access
API is still in beta I might have let this slip by but its does not even build
../../../src/tests/elementary/elm_test_popup.c:27:1: error: conflicting types for ‘elm_object_part_access_object_get’
START_TEST (elm_object_part_access_object_get)
^
In file included from ../../../src/lib/elementary/Elementary.h:240:0,
from ../../../src/tests/elementary/elm_test_popup.c:6:
../../../src/lib/elementary/elm_object.h:521:54: note: previous declaration of ‘elm_object_part_access_object_get’ was here
EAPI Evas_Object *elm_object_part_access_object_get(const Evas_Object *obj, const char *part);
^
../../../src/tests/elementary/elm_test_popup.c: In function ‘elm_object_part_access_object_get’:
../../../src/tests/elementary/elm_test_popup.c:39:47: warning: passing argument 1 of ‘elm_object_part_access_object_get’ makes integer from pointer without a cast [-Wint-conversion]
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: expected ‘int’ but argument is of type ‘Evas_Object * {aka struct _Eo_Opaque *}’
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:13: error: too many arguments to function ‘elm_object_part_access_object_get’
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: declared here
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:11: error: void value not ignored as it ought to be
access = elm_object_part_access_object_get(popup, "access.title");
^
Makefile:43996: recipe for target 'tests/elementary/tests_elementary_elm_suite-elm_test_popup.o' failed
make[5]: *** [tests/elementary/tests_elementary_elm_suite-elm_test_popup.o] Error 1
If you still want this in make sure it actually can compile the tests you added.
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
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