Summary:
Efl.Ui.Theme class is required to support language bindings.
Efl.Ui.Theme works based on current elm_theme features.
This patch fixes T7357.
Reviewers: segfaultxavi, cedric, lauromoura, woohyun, zmike, SanghyeonLee
Reviewed By: segfaultxavi, SanghyeonLee
Subscribers: SanghyeonLee, herdsman, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7357
Differential Revision: https://phab.enlightenment.org/D7244
according to the docs, this mode means that no content size hints should
be taken into account when calculating size hints for the overall object
fix T7313
Differential Revision: https://phab.enlightenment.org/D6860
Summary:
using EINA_LIST_FREE here double deletes 2 list items on every iteration
due to recursive list removals, which prevents some items from being
deleted as expected
fix T7266
Reviewers: netstar
Reviewed By: netstar
Subscribers: netstar, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T7266
Differential Revision: https://phab.enlightenment.org/D6829
Summary:
this was added in a giant block commit in 2009 without direct explanation;
it doesn't seem to make functional sense in the original patch and it
definitely doesn't make sense now
this greatly improves list performance by causing fewer edje recalcs on
list items resulting from list fighting with item content objects over
max size hint
fix T7176
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #committers
Tags: #efl_widgets
Maniphest Tasks: T7176
Differential Revision: https://phab.enlightenment.org/D6669
Summary:
this size hints callback is triggered by both list objects and list
item objects, meaning that setting size hints on the item objects during
recalc will trigger a recursive recalc, potentially infinitely
this blocks recursive recalcs unless triggered by size hint changes
from a main list object, since those will eventually resolve themselves
fix T7121
Reviewers: devilhorns, Hermet
Reviewed By: Hermet
Subscribers: netstar, DaveMDS, cedric, #committers
Tags: #efl_widgets
Maniphest Tasks: T7121
Differential Revision: https://phab.enlightenment.org/D6572
Summary:
this is both invalid and useless, so return immediately before spending cpu
time and generating error messages
fix T7035
Depends on D6324
Reviewers: bu5hm4n, Hermet, woohyun, devilhorns
Reviewed By: bu5hm4n
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7035
Differential Revision: https://phab.enlightenment.org/D6325
Elm.List.Item lifecycle where an exception in Efl. They were trying to prevent the death of
there parent, to avoid dealing with safely walking on items list. This has been on the todo
list for years and is now fixed by this patch.
It is my understanding that some items view are created with efl_add directly
and manipulate VIEW directly with Eo new API. This clash with the inconsistent
behavior that evas_object_del expect. To work around this, we track object life
by explictely relying on efl_wref_add while holding the pointer to the object.
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary:
list have got focus. but there isn't logic to check whether focused_item exist.
we need that logic for list focus
this fixes T6807, T6799
Test Plan: elementary_test -to 'list focus'
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric
Maniphest Tasks: T6807, T6799
Differential Revision: https://phab.enlightenment.org/D5935
Following @taxi2se's recommendation. This is indeed a focus method, and
Widget already inherits from Focus.Object.
Ping @bu5hm4n who probably wants to adapt this further.
Ref T5363
elm_object_item_focus_set ensures that the list also gets focus, thus calling
that in _elm_list_elm_widget_on_focus_update would result in a infinite
call recursion, if setting the focus fails (for example when the object
is not visible yet, [see enlightenment for that]).
This fixes a freeze if you open lunchers config.
This thing is used by only 2 EO APIs that are marked as @beta. I wonder
if the @beta tag or the ptr() expression made it work for eolian,
because it simply wasn't defined in EO.
I'm renaming it just so that it's more consistent with the new names
used by atspi (and EO API in general).
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.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
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