|Age||Commit message (Collapse)||Author|
historically there have been two methods of calculating sizes in elm:
* evas_object_smart_calculate (now efl_canvas_group_calculate)
the former was used to set size hints on widgets, while the latter was
used to perform internal size calcs for the widget. for things to
work correctly, these functions had to be triggered in just the right
order at just the right time. many hard-to-fix bugs related to widget
sizing over the years have been the result of this split
this patch removes elm_layout_sizing_eval implementations so that all
widgets perform both internal size calcs and size hint setting all
in the same function, ensuring that these are always in sync
the result is that in the vast majority of cases, far fewer recalcs
happen for widgets, and they are quicker to achieve their final size
Depends on D9438
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9439
this doesn't seem to serve a purpose anymore and there's no point in
keeping it in tree
Reviewers: woohyun, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #reviewers, #committers
Maniphest Tasks: T7866
Differential Revision: https://phab.enlightenment.org/D9176
This is a bit of a giant commit. However, the problem here is that
cleaning up the API went hand in hand with rewriting most of the usages.
In the process of renewing and removing old API the following was done:
- Legacy API testcases have been ported back to smart callbacks
- EO-API testcases have been ported to efl_add syntax
- weird event #defines have been removed
- Wrong constructor usage has been removed
- Ported to the new box object introduced before
- removed legacy API from efl_ui_radio
-> no more ptr(int) q66 will do jumps of happiness
-> no more ununderstandable group_add methods
-> Seperated code in blocks only for legacy, and blocks only for
To verify this commit, you can check all the tests that have been
touched here. Additionally, the cxx example has been adjusted
Reviewed-by: Mike Blumenkrantz <email@example.com>
Differential Revision: https://phab.enlightenment.org/D9060
since commit a1addad60e, To add myself as a sub object of parent object will be
done in Efl.Ui.Widget constructor.
Reviewed-by: Marcel Hollerbach <firstname.lastname@example.org>
Differential Revision: https://phab.enlightenment.org/D8280
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
Reviewed-by: Cedric BAIL <email@example.com>
Differential Revision: https://phab.enlightenment.org/D8164
now that the error codes have been change to be compatible with eina_error,
this can be removed and will work through eina_error naturally
Depends on D8067
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Maniphest Tasks: T7718
Differential Revision: https://phab.enlightenment.org/D8068
this swaps the values of "no error" and "error" in order to maintain
consistency with the rest of efl where the zero value means "no error"
Depends on D8060
Reviewed By: cedric
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Differential Revision: https://phab.enlightenment.org/D8063
If we are to choose Efl.Ui.I18n for the internationalization support, the localization API
should be named accordingly L10n.
Reviewed-by: Xavi Artigas <firstname.lastname@example.org>
Differential Revision: https://phab.enlightenment.org/D7507
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
Maniphest Tasks: T7357
Differential Revision: https://phab.enlightenment.org/D7244
API parts require namespacing, these parts have been namespaced with
compatibility code added to handle legacy naming
Depends on D6210
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D6211
object, we need to track their lifecycle more explicitely.
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.
during destructor make no sense.
Differential Revision: https://phab.enlightenment.org/D6106
The interface efl_part_get should not be directly called from C, but the efl_part
wrapper should. It rely on efl_noref to properly destroy the object. Binding can
control the lifecycle of the reference the way they want by either calling the
wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set
doesn't need to be exposed outside of EFL anymore.
Differential Revision: https://phab.enlightenment.org/D6098
Reviewed-by: Cedric Bail <email@example.com>
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.
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 only changes the eo_prefix for APIs.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5341
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.
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 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.
This means that ALL part handles inherit from the base part class
Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is
This is a first step towards generic part APIs, including background in
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
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 :)
This makes efl_ui_layout_theme_set() return a Theme_Apply error
code. The type is now public as Efl.Ui.Theme.Apply.
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
elm_layout_sizing_eval() marks an object as requiring recalc.
Unfortunately, it's been massively abused by various widgets into
actually doing the calc, or the min calc. So we end up with one API
that has 3 different definitions depending on the widget type:
1. Mark as requiring recalc (correct, respects doc, elm_layout)
2. Calculate min size and other size hints
3. Actually do some geometry modification
I believe we need to clarify these 3 requirements into 3 very clear
and specific APIs in elementary. Right now we have similar functions
in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate).
But their exact definition also isn't necessarily what we want for
Another clear problem is that layout_eval does not do any calculation
(in theory), so the "eval" word is a bit of a stretch here.
Once we're sure about the exact API we want, we can add this back to
EO and make it work across our EO widgets. For now let's just keep
the legacy API, and its EO overrides, as is.
this looks like a leftover from legacy to eo porting. it was harmless
but analysis hates it
found by PVS studio
This hides those two legacy functions from the EO API.
An invalid strcmp() led to always reject the swallowed
widgets, which were Elm.Check instead of Elm_Check.
Use efl_isa() instead.
This is the last step of the Eo renaming efforts.
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
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 renames all the rest of the API to the EFL namespace except for
Eo_Event that will follow soon.
Obviously breaks both API and ABI.
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 : 4ca3ef45146e05908a13d1010909abeba9693ad6
* elm_object_style_set is public api, so I didn't change it.
* typedef name [ Theme_Apply ] is temporarily, please suggest better one.
Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4073
One step closer to make the EO inheritance tree look like
it's all Efl.
This was changed in the previous commit.
This is a first step at separating legacy smart
object features away from standard efl interfaces.
This reverts commit ac5a0b7e79d6b32285bd7b794f050826f38cc7c2.
I added assert(pd == sd) in the modified code and couldn't find
anything suspicious. The proper class is used in eo_data_scope_get().
I also can't find a crash or a bug currently in hover. I know there
was a problem earlier, but that was fixed in 3092e08a83f754ba8d49c.
Now, if there is still a problem, we should check it carefully.
It seems that this content_get function are not getting the data pointer
they expect at all.
This reverts commit 546ff7bbba788ec834c5608361c0834853f2d5d7.
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_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.
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.
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
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.