On Tue, 14 May 2019 14:13:56 +0800 (CST) Jing  <[email protected]> said:

> Hi all,
> Below is my EDC textblock decription:
> textblock { "testtext";
> desc { "default";
> rel1.to: "anotherpart";
> rel1.offset: 20 15;
> text.align: 0 0;
> text.style: "setting/item_tip_text/default";
> text.text:"this is a test string, how to get text string width not string
> length"; }
> }
> 
> 
> I want to get the text string width, but I didn't find the corresponding  api
> for this, please help, thanks.

i think you may be misunderstanding what edje is for. it's not a data file to
go create objects for you you can then do whatever you want with., it's means
to be a way of HIDING all these details and making them a "runtime data
file/theme option" so CODE deals with a high level "abstract" API. if you want
this kind of level of detail you can create evas objects via evas's api and
modify them and manipulate them.

if you use edje as an abstraction correctly, then what you can do with the
above idea is to make a group that is basically a "text label". this is
precisely what elm label does. then it sets the text and asks edje to calc the
min size of the entire edje object given its current state and content. any
padding and other elements in the group will also be taken into account when
calculating this min size so it will not be the strict size of the textblock
itself but the object overall. this is how it's intended to be used. if a theme
decides to add some padding or surrounding decoration to the text and this
needs space, then this is also part of the calculation.

so choose a method. either "do it yourself with evas objects directly" ... or
"use edje as the high level abstraction it was intended for". :)

P.S.

note: after many years i think edje's abstraction could be a lot better. it was
kind of a very new and different thing when it was created so there wasn't a
lot of precedent. if i went back in time i'd have made it even more abstracted
and have that abstraction be more formal where and edje group presents and
"api" (in the form of exposed properties like booleans, ints, floats, strings)
that you can set and get as well as transient messages (edje does have these),
with these properties and messages generally being flexible like a normal
library API but with clear formal conventions that take common ones and
standardize them. on the edje data size i'd have used lua from day 1 and made
objects basically blobs of lua rather than the parts we have today with lua
libraries making this easier.


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]



_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to