This will be used to solve issues around style_set:
if the widget is legacy or pure eo we may need to select a different
style. So in the constructor we need to know whether we are legacy or
eo. Note that calling style_set in finalize only is too late as we would
lose information such as efl_text_set() called inside efl_add().
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
This will be used to replace the part translation API in Elm.Widget. It
should work for both parts and non-parts (ie. the main text of a button,
for instance).
For now I'm taking the following approach:
- All efl_text_set/get strings are untranslatable, i.e. get() returns
the visible string, set replaces and can not be translated.
- translatable_text_set/get needs to be used to enable automatic
translation, which in turns calls efl_text_set to modify the visible
string. Thus, translatable applications will have to use
efl_ui_translatable_text_set a lot more than efl_text_set, unless
they translate strings application-side.
Note that some other frameworks take a simpler approach equivalent to
calling efl_text_set() with an already translated text. This prevents
runtime language changes of the application, unless the application
handles them specifically.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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 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
Summary:
When auto update is enabled, the label of the hoversel will be that of selected
item. This feature is usually used when changing state of something.
Highlighting item previous selected will show what is current state more
explicitly especailly hoversel has many items.
Test Plan: elementary_test -to hoversel
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4799
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The changes of previous patch (4ea7effe70)
are reverted, and item calculation is fixed correctly.
The main reason why hoversel item has wrong size in screen rotation is
that hover doesn't update geometry when the size of target object is changed.
Test Plan: elementary_test -to hoversel
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4556
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
When screen is rotated, _resizing_eval() will be called twice by hover_parent
resize and hoversel movement.
If the alignment is changed to the right in the first call because of the geometry
of edje part is not updated yet (hoversel uses edje part geometry in calculation),
hoversel keeps being right-aligned in the second call,
even though there is enough space to show with default alignment.
Test Plan: elementary_test -to hoversel
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4557
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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:
The way to find the position of hoversel expansion is based on geometry
currently, but it causes errors when theme is not made as expected.
This patch makes hoversel use string to find the right position and
calculate item width correctly when items are shorter than hoversel itself.
Test Plan:
elementary_test -to hoversel
(error case shows in tizen mobile device when screen is rotated)
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4484
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
These are some of the EO files that shouldn't be part of the public
EO API:
- elm_access (old)
- actionslider
- bubble
- diskselector
- flipselector (a fancy spinner)
- hoversel (use combobox instead)
- icon (use image instead)
- inwin
- naviframe (unreplaced for now)
- photo (use image)
- prefs
- segment control
- separator
- slideshow
- thumb (use image)
Note: This breaks the use of the elm_widget_xxx.h headers. Those
were internal headers anyway. Exposed because of a lack of
a proper inheritance API.
Summary: In all other places "clicked" is defined as a local variable.
Reviewers: tasn, jpeg
Reviewed By: jpeg
Subscribers: cedric, minkyu
Differential Revision: https://phab.enlightenment.org/D4349
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:
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
when hoversel has no item at all and use clicks on it, then it goes into
state called "expanded".
and so then, no matter how many items user would try to add, hoversel won't work
anymore.
@fix
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...
Summary:
Hoversel will be rearranged when its parent is resized.
This patch was written by @godlytalias on tizen side.
Reviewers: cedric
Subscribers: jpeg, godlytalias
Differential Revision: https://phab.enlightenment.org/D4025
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
Jean-Philippe Andre
Lukasz Stanislawski
Carsten Haitzler
Jeeyong Um
Amitesh Singh
Jee-Yong Um
WooHyun Jung
Shuhrat Dehkanov
Tom Hacohen
Vitor Sousa
Jinyong Park
Vitalii Vorobiov
Cedric BAIL
Ji-Youn Park