Summary:
Now all textblock_style functionality are wrapped under api
for easy of optimization. so going forward no one should directly
acess the styles from the File . the styles should be acesses by
the internal api's provided by edje_textblock_style.
Reviewers: Hermet, ali.alzyod, woohyun, kimcinoo
Reviewed By: kimcinoo
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9774
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:
special calculation for textblock is for fit calculation.
This is obvious from code that fit is being calculated
before text is actually been set to textblock.
I am not sure whether this is intentional or mistake
but it make sense to calculate fit after text is being
set so that formatted and native calculation can be proper.
@fix
Test Plan: NA
Reviewers: cedric, zmike, herdsman, devilhorns
Subscribers: stefan_schmidt, #reviewers, #committers, shilpasingh
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6045
Summary:
"description.text.text" is not shown after applying a patch for
supporting text translation of Textblock part.
@fix T6997
Test Plan:
- Try to show a TEXTBLOCK part which has built-in text.
ex)
textblock {
scale;
desc { "default";
text {
style: "my_style";
text: "You can't see this text without this patch";
}
}
}
Reviewers: Hermet, subodh6129, herdsman
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6997
Differential Revision: https://phab.enlightenment.org/D6257
Summary:
Text translation in edc for textblock is missing.
Added to support it.
@fix
Reviewers: cedric, zmike
Reviewed By: cedric, zmike
Subscribers: shilpasingh, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6164
This removes the internal function pointer for scale_update. This makes
all relevant classes implement the scale API in EO.
This removes the duplicate function in Efl.Canvas.Object and only uses
the one from Efl.Ui.Base interface.
This *seems* to be working as expected. Fingers crossed!
PS: I don't like the name Efl.Ui.Base. It's an interface for a few
common API's between Gfx, Canvas and UI levels... Maybe scale simply
doesn't belong there.
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>