Eolian @properties should be documented at the property level, and
documentation at the setter or getter level should be left to setter-
or getter-specific comments. There is usually no need at all to have
setter- or getter- specific comments.
Also, a property is not a method so descriptions should match that.
This patch removes lots of duplicated text, and will allow enabling
by default the eolian check that ensures that properties have proper
property-level docs.
No functional changes.
unload is a crucial method for classes that implement load, as this is
the method which is called during e.g., efl_file_simple_load() when
a new file is specified in order to destroy the previous object data
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9786
Summary:
historically there have been two methods of calculating sizes in elm:
* elm_layout_sizing_eval
* 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
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9439
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
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8147
Summary:
most widgets inherit from layout to provide implementations for common
functionality such as content/text/theme get+set.
one of the things that layout also brings into its inheritance hierarchy
is efl.file and implementations for its methods. this becomes a problem
when the widget which inherits layout also wants to provide implementations
for efl.file methods (e.g., entry, which uses efl.file to load text files)
as it will result in calling all of the efl.file implementations up the
chain.
in the case of entry, this could result in the 'file' property eventually being
set to the current theme file in use by the entry's layout object, and then the
entry will attempt to autosave its content to the default theme file when it is
destroyed, corrupting the theme file and breaking everything
to solve this:
* efl.ui.layout remains an instantiable class which implements efl.file
* efl.ui.layout_base is the abstract class which provides all the methods of layout
but should be inherited by all widgets which want to implement efl.file functionality
Depends on D8018
Reviewers: bu5hm4n, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8032
Summary:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018
Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
Summary:
Efl.Ui.Layout namespace is removed to keep consistency with other
widgets.
Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and
"Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_".
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, SanghyeonLee, woohyun
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7291
Summary:
For now, how to check whether a widget is legacy or not
is to check flags in private data or static flag, which is set
during elm_legacy_add.
If Efl.Ui.Legacy interface is added, it can be easilly checked
by efl_isa(obj, EFL_UI_LEGACY_INTERFACE)
Reviewers: woohyun, jpeg, cedric, Jaehyun_Cho
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5748
Summary:
Efl.Player interface simply provides play functions,
but another interface which indicates Efl.Player will play is also
needed.
Test Plan: Run elementary_test->Efl.Animation tests
Reviewers: woohyun, conr2d, Jaehyun_Cho, jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5662
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
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
elementary.
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.
Ref T5315
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
Daniel Kolesa
Xavi Artigas
Mike Blumenkrantz
Marcel Hollerbach
Jaehyun Cho
Woochanlee
Sungtaek Hong
Amitesh Singh
Lukasz Stanislawski
Marcel Hollerbach
Jean-Philippe Andre
Jee-Yong Um
Daniel Kolesa
Stefan Schmidt
Tom Hacohen
Yeshwanth Reddivari