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
Summary:
If edje_text_get is called before any edje_text_set function call, it return
null, because rp->typedata.text->text is only set by edje_text_set function.
If there is no available text data, find it from rp(edc).
ref 7bbf18a950
Test Plan: make check
Reviewers: zmike, id213sin, herdsman
Reviewed By: id213sin
Subscribers: Hermet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6961
Summary:
based on the codepaths taken when setting text to a part, a recalc should
only be necessary when returning markup from a textblock, and this is only
the case because the function returns a non-allocated string
in the case where the object is textblock and (legacy || not fetching markup),
the current text is guaranteed to be set on this pointer. the reason a
recalc is necessary for the markup case is because edje TEXTBLOCK parts only
set text to the internal textblock during a recalc, meaning that attempting
to fetch text on a just-set part will fail; this does not mean that the internal
textblock object doesn't exist, only that the text has not yet been set to it
Depends on D6422
Reviewers: herdsman, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6423
Summary:
this adds perf overhead in order to work around a bug in text_get
all part objects are instantiated during edje_object_file_set, and forcing
a recalc here does nothing more than perform unnecessary operations
ref 8f95b17f39
ref D6365
Reviewers: herdsman, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6422
Summary:
There are many calls to `_edje_real_part_recursive_get`. Though, it is
not guaranteed that the Edje object had instantiated all of the real
parts.
This change makes edje to always recalc before retrieving the real part.
The D6364 patch raised a good point, but presented a local fix, where
it seems that a global fix such as this is needed, instead.
The local fix is removed in favor of this. Test suite still passes.
ref T7057
@fix
Test Plan: See T7057
Reviewers: devilhorns
Subscribers: cedric, zmike, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6365
Summary:
Some changes broke really basical function behavior of text.
I couldn't get text from an edje object which I just set to the given edje object.
In the past code, edje called recalc function before trying to get text.
So, this patch bring that code to fix this issue.
@fix
Test Plan: Included. Run "make check"
Reviewers: herdsman, raster, cedric, woohyun, devilhorns
Subscribers: #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6364
Summary:
_edje_part_fetch() function gets an Edje which has the requested Edje_Real_Part.
Basically, it gets main Edje of the given object.
But, if a requested part is in a GROUP part, it gets the Edje of GROUP part.
It shouldn't be passed to _edje_efl_text_text_get() function directly.
@fix
Test Plan: N/A
Reviewers: herdsman, raster, cedric, woohyun
Reviewed By: cedric
Subscribers: #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6149
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
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
elm_entry_prediction_hint_hash_set API sets the prediction hint data at the specified key, and
elm_entry_prediction_hint_hash_del API is for deleting the prediction hint data identified by a key.
@feature
Signed-off-by: Jihoon Kim <jihoon48.kim@samsung.com>
neither of these functions should force a recalc under any circumstance
as they are simply returning pointers
@fix
Differential Revision: https://phab.enlightenment.org/D5947
a number of these functions have implicit recalcs, which is bad because
it's a pretty significant perf bottleneck, but it can't be improved
without breaking existing behavior expectations so this is probably the
best that can be done
ref T6884
Differential Revision: https://phab.enlightenment.org/D5946
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.
This fixes some of the warnings generated by calling functions on NULL
objects. One of the main remaining points is to avoid unwanted warnings
on non-existing parts.
Ref T6326
This allows to safely verify if a part exists, without triggering any
potential call to NULL object, or even requiring the efl_part() handle
to be created.
This is perfectly equivalent to edje_object_part_exists(), but
implemented by both edje object and elm layout.
Note: Edje.Perspective is not bound to EO, and this is the only reason
why I'm moving this to legacy only. Marking as beta would mean the
legacy APIs would not be generated, so that would have almost the same
effect as moving to legacy.
It would be nice to actually support this in EO, though this seems like
a rarely used feature.
Ref T5315
This should probably be replaced by a well defined signal.
Note: If edje sends signals on swallow/unswallow and text set/unset we
could simplify some of the elementary code, eg. for button's icon
handling. The theme should be handling the padding automatically, it's
not the elementary widget's role
Ref T5315
EO file API is still in flux, especially wrt. async loading. Let's just
keep this in legacy for now.
A few more patches and Edje.Object will reach its final form.
Ref T5315
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
This reverts commit ef3d2120bf.
This breaks E. pager ono my right screen looks like:
http://devs.enlightenment.org/~raster/shot-2017-11-11_12-13-14.png
on my left screen shellf keeps swapping between 2 dizes wobbling back
and forth every frame eating cpu and making it "blurry"...
note - theme is the flat one in devs/raster/theme/flat2 branch. so
this change certainly breaks something...
As most of you know, TEXT part was, up to this point, an Evas.Text
object.
This patch merges TEXT and TEXTBLOCK both to use Efl.Canvas.Text.
Code is added to emulate what TEXT did that TEXTBLOCK did not.
I believe we can move forward with TEXT, and deperacate TEXTBLOCK from
the EDC. You can also set markup to TEXT parts.
Exactness seems to show some differences, but further examination shows
that it's due to difference in how width is calculated in
Efl.Canvas.Text. The results seem correct.
Be sure to report of any breakage via Phabricator or contact me
directly.
I am running E with this and did not stumble upon any crashes or visual
bugs.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
Summary:
It should return width and height with positive values or zero.
@fix
Test Plan: make check
Reviewers: raster, jpeg, cedric
Reviewed By: raster
Subscribers: jiin.moon
Differential Revision: https://phab.enlightenment.org/D5422
Keep the legacy code path when using edje_object_part_text_set.
Fixes e's notification that got broken after
3642b3ae67.
Also, limit new efl_text_markup set to TEXTBLOCK parts.
Users can now do either:
efl_text_set(efl_part(obj, "part"), "text");
efl_text_markup_set(efl_part(obj, "part"), "text");
Also have efl_text_get/markup_get.
Using markup_set will allow to choose whether to set a markup or a text
to the text part.
For now I made this EO-only but this definitely could be expose in
legacy API as well.
This simply gives exact information about the type of part, after doing
a recursive search. Edit Edit doesn't do a recursive search, only a
direct one, which can yield invalid results (eg. RECT or NONE instead of
TEXT in case of "elm.units.max" for a slider).
@feature
calc_size_min was just a helper passing 0,0 to the restricted form.
Let's not duplicate APIs in EO and use an optional argument instead.
Bindings should be nicer and C could use a macro if it's too cumbersome
to pass in 0,0.