Summary:
Since we're now going to be shipping some eo classes as stable,
there is no point in keeping the eo api behind a macro, and it
should be enabled by default. Another case is beta classes, but
those are behind the EFL_BETA_API_SUPPORT guard.
This also changes includes around the place where things are
clearly broken (such as an included header needing something
from another header but that other header being guarded, notably
efl_ui_widget.h needing focus manager but focus manager being
behind beta in Elementary.h)
Reviewers: zmike, cedric, bu5hm4n, stefan_schmidt, segfaultxavi
Reviewed By: cedric, segfaultxavi
Subscribers: segfaultxavi, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8322
it looks like people have been relying on Elementary.h to include
eo apis even though this obviously makes no sense
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8223
Summary:
most of the eo methods here will be marked beta, preventing them from
generating legacy code
ref T7511
Depends on D8082
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7511
Differential Revision: https://phab.enlightenment.org/D8083
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
This adds many Efl.Text.* that are useful for manipulating the
underlying TEXTBLOCK object's propeties using efl_part.
This has been implemented as part of the "user-defined" properties of
the layout part, so that the changes on the part persist across load of
different groups.
Note that text styles have precedence over the TEXTBLOCK (Canvas.Text)
object's properties. if an edc provides a style, the properties it
manipulates as part of the "base:" string would not be affected by this
API.
In general, this helps reducing the amount of styles for objects (or
modes of the same objects) that share the same setup, but are different
in some properties (e.g. ellipsis, wrap etc).
@feature
Canvas layout: add text part "expand" property
This adds "expansion modes", which are essentially the same as min/max
hints in the edje part's 'description.text' fields.
The user can then customize his widget to different modes without being
forced to create a new edje group in the theme.
Note that there is an added check in case one of the min/max text flags
are provided from the theme. In such case, all flags from this new API
will be ignored.
This fortifies misuse where the flags are set both in theme and the API.
@feature