Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[Daniel Hirt]

Hello,
Gave it some thought. Sorry for the late reply.
Please see below.

On Tue, May 30, 2017 at 10:29 PM, Davide Andreoli 
wrote:

> 2017-05-29 7:07 GMT+02:00 Daniel Hirt :
> > Hello,
> >
> > On Mon, May 29, 2017 at 7:16 AM, Jean-Philippe André 
> > wrote:
> >
> >> On 29 May 2017 at 05:18, Davide Andreoli 
> wrote:
> >>
> >> > 2017-05-28 15:00 GMT+02:00 Daniel Hirt :
> >> > > herdsman pushed a commit to branch master.
> >> > >
> >> > > http://git.enlightenment.org/core/efl.git/commit/?id=
> >> > da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> >> > >
> >> > > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> >> > > Author: Daniel Hirt 
> >> > > Date:   Mon May 22 17:36:41 2017 +0300
> >> > >
> >> > > Efl text: add Font, Format and Style interfaces
> >> > >
> >> > > The following text interfaces are added:
> >> > >   - Efl.Text.Font: font settings that decide which font to
> display
> >> in
> >> > > the text
> >> > >   - Efl.Text.Format: formatting that affects the looks and
> layout
> >> of
> >> > > the text
> >> > >   - Efl.Text.Style: decorations and overlays that shouldn't
> affect
> >> > the
> >> > > font choice or the layout
> >> > >
> >> > > @feature
> >> >
> >> > I think we have another namespacing issue here:
> >> > Efl.Text.Style do not use any namespace, while Efl.Text.Font and
> Format
> >> do,
> >> >
> >> > We discussed this already in chat today and we did not find a
> successfull
> >> > deal,
> >> > what I think at this point is that we really should find a rule to
> >> > apply to every Iface,
> >> > ...the problem is that we did not find any always-correct rule :(
> >> >
> >>
> >> In short, as I didn't follow that conversation, what were the arguments
> >> against namespacing "style"?
> >>
> >>
> > As I understand, it's not only about preventing clashes. Widgets are
> complex
> > objects, and having your widget doing:
> > widget.style_normal_color_set(...)
> >  isn't really better for the user. A better choice might be:
> > widget.text_style_normal_color_set(...)
>
> In real a more better name is "widget.text_normal_color_set(...)"
> the "style" prefix seems to me unneeded.
>
> This let me rise another question: do we really need this 3 interfaces
> to be splitted as they are? Isn't better to just provide a single
> "Efl.Text" iface ??
> Or I miss a use case where an object would need just 1 or 2 of them?
> If they can be merged we will simplify the problem and shortening
> function names.
>
>
Agree regarding the "style_" prefix. I will omit that.

The split is required so that if you want to add your own "Efl.Text" object,
you could just implement the basic functionality (text_set, get).
If you want a more enhanced object (like "Efl.Canvas.Text"), then you can go
ahead and use your own interfaces, or utilize the existing interfaces.
Note that interfaces are requires for documentation as well, and I wouldn't
want that, for example, "Elm.Layout" parts suggest they implement anything
other than "text_set/get".
This is why the split is a requirement, as I see it.

For bindings, there shouldn't be an issue:
foo.text_normal_color_set(r, g, b, a);
foo.text_set("hello");
(the interface's namespace isn't reflected in the usage for bindings)

As for EO, I will reduce the notation using eolian's "eo_prefix", so we do:
efl_text_normal_color_set(foo_obj, r, g, b, a);
(note that, again, this resides in the "Efl.Text.Style" interface)

This seems like a proper solution to make the text interface future-proof.

[snip]
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[The Rasterman]

On Mon, 29 May 2017 13:16:31 +0900 Jean-Philippe André  said:

> On 29 May 2017 at 05:18, Davide Andreoli  wrote:
> 
> > 2017-05-28 15:00 GMT+02:00 Daniel Hirt :
> > > herdsman pushed a commit to branch master.
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> > >
> > > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> > > Author: Daniel Hirt 
> > > Date:   Mon May 22 17:36:41 2017 +0300
> > >
> > > Efl text: add Font, Format and Style interfaces
> > >
> > > The following text interfaces are added:
> > >   - Efl.Text.Font: font settings that decide which font to display in
> > > the text
> > >   - Efl.Text.Format: formatting that affects the looks and layout of
> > > the text
> > >   - Efl.Text.Style: decorations and overlays that shouldn't affect
> > the
> > > font choice or the layout
> > >
> > > @feature
> >
> > I think we have another namespacing issue here:
> > Efl.Text.Style do not use any namespace, while Efl.Text.Font and Format do,
> >
> > We discussed this already in chat today and we did not find a successfull
> > deal,
> > what I think at this point is that we really should find a rule to
> > apply to every Iface,
> > ...the problem is that we did not find any always-correct rule :(
> >
> 
> In short, as I didn't follow that conversation, what were the arguments
> against namespacing "style"?
> 
> I also wonder if having 9 color functions is really better than a single
> color function and an enum: color1, color2, color3, shadow, underline,
> etc...?

just like with parts... we debated if we should be passing those part name
strings to everything... and came up with efl_part to solve the problem more
nicely... in future at least we could use efl_part for this kind of thing...
but there is talk of doing a specific style concept in eo like
https://phab.enlightenment.org/T5307 so i guess it's a question of where it
would belong or if there would be part name conflicts etc.

> Also, what objects will implement the below interfaces? I expect
> Efl.Canvas.Text for the default style, and some kind of text item object?
> 
> ideas?
> >
> >
> > PS: I stripped down the commit below to only show the new eo interfaces,
> > so that
> > the issue is more evident
> >
> >
> >
> > > +interface Efl.Text.Font {
> > > +   [[Font settings of the text
> > > +
> > > + @since 1.20
> > > +   ]]
> > > +   methods {
> > > +  @property font {
> > > + [[The font name and size that is used for the displayed text]]
> > > + values {
> > > +font: string;
> > > +size: int;
> > > + }
> > > +  }
> > > +  @property font_source {
> > > + [[The source that will be used to lookup the font of the text
> > > +
> > > +   The source can be either a path to a font file e.g.
> > > +   "/path/to/font.ttf", or an eet file e.g. "/path/to/font.eet".
> > > + ]]
> > > + values {
> > > +font_source: string;
> > > + }
> > > +  }
> > > +
> > > +  @property font_fallbacks {
> > > + [[Comma-separated list of font fallbacks
> > > +
> > > +   Will be used in case the primary font isn't available.
> > > + ]]
> > > + values {
> > > +font_fallbacks: string;
> > > + }
> > > +  }
> > > +
> > > +  @property font_weight {
> > > + [[Type of weight of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Weight.normal\.
> > > + ]]
> > > + values {
> > > +font_weight: Efl.Text.Font.Weight;
> > > + }
> > > +  }
> > > +
> > > +  @property font_slant {
> > > + [[Type of slant of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Slant.normal\.
> > > + ]]
> > > + values {
> > > +style: Efl.Text.Font.Slant;
> > > + }
> > > +  }
> > > +
> > > +  @property font_width {
> > > + [[Type of width of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Width.normal\.
> > > + ]]
> > > + values {
> > > +width: Efl.Text.Font.Width;
> > > + }
> > > +  }
> > > +
> > > +  @property font_lang {
> > > + [[Specific language of the displayed font
> > > +
> > > +   This is used to lookup fonts suitable to the specified
> > language, as
> > > +   well as helping the font shaper backend.
> > > +   The language $lang can be either a code e.g "en_US",
> > > +   "auto" to use the system locale, or "none".
> > > + ]]
> > > + values {
> > > +lang: string;
> > > + }
> > > +  }
> > > +   }
> > > +}
> >
> >
> > > +interface Efl.Text.Format {
> > > +   [[The look and layout of the text
> > > +
> > > + The text format can affect the 

Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[Davide Andreoli]

2017-05-29 7:07 GMT+02:00 Daniel Hirt :
> Hello,
>
> On Mon, May 29, 2017 at 7:16 AM, Jean-Philippe André 
> wrote:
>
>> On 29 May 2017 at 05:18, Davide Andreoli  wrote:
>>
>> > 2017-05-28 15:00 GMT+02:00 Daniel Hirt :
>> > > herdsman pushed a commit to branch master.
>> > >
>> > > http://git.enlightenment.org/core/efl.git/commit/?id=
>> > da2ef30f2b4d53aa3c1658b83c8c8381743469a0
>> > >
>> > > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
>> > > Author: Daniel Hirt 
>> > > Date:   Mon May 22 17:36:41 2017 +0300
>> > >
>> > > Efl text: add Font, Format and Style interfaces
>> > >
>> > > The following text interfaces are added:
>> > >   - Efl.Text.Font: font settings that decide which font to display
>> in
>> > > the text
>> > >   - Efl.Text.Format: formatting that affects the looks and layout
>> of
>> > > the text
>> > >   - Efl.Text.Style: decorations and overlays that shouldn't affect
>> > the
>> > > font choice or the layout
>> > >
>> > > @feature
>> >
>> > I think we have another namespacing issue here:
>> > Efl.Text.Style do not use any namespace, while Efl.Text.Font and Format
>> do,
>> >
>> > We discussed this already in chat today and we did not find a successfull
>> > deal,
>> > what I think at this point is that we really should find a rule to
>> > apply to every Iface,
>> > ...the problem is that we did not find any always-correct rule :(
>> >
>>
>> In short, as I didn't follow that conversation, what were the arguments
>> against namespacing "style"?
>>
>>
> As I understand, it's not only about preventing clashes. Widgets are complex
> objects, and having your widget doing:
> widget.style_normal_color_set(...)
>  isn't really better for the user. A better choice might be:
> widget.text_style_normal_color_set(...)

In real a more better name is "widget.text_normal_color_set(...)"
the "style" prefix seems to me unneeded.

This let me rise another question: do we really need this 3 interfaces
to be splitted as they are? Isn't better to just provide a single
"Efl.Text" iface ??
Or I miss a use case where an object would need just 1 or 2 of them?
If they can be merged we will simplify the problem and shortening
function names.


>
> A pretty good example from Davide was a combobox with the text widget
> in it. There's no guarantee how your object is going to be used in the
> future
> and how fine the naming of your methods should be, due to unique styles
> of inheritance like "composition", which is gaining popularity it seems.
>
> For common inheritance this is less likely to be a problem.
>
>
>> I also wonder if having 9 color functions is really better than a single
>> color function and an enum: color1, color2, color3, shadow, underline,
>> etc...?
>>
>>
> I wanted to avoid the enum mess. There's not  a single pro I could think of
> other than saving ME writing a few extra functions.
>
>
>> Also, what objects will implement the below interfaces? I expect
>> Efl.Canvas.Text for the default style, and some kind of text item object?
>>
>>
> Efl.Ui.Text is a composite object, with Efl.Canvas.Text. We still needed the
> text API to be exposed this in the documentation of Efl.Ui.Text, so users
> know that they can manipulate the text object in this widget.
>
>
>> ideas?
>> >
>> >
>> > PS: I stripped down the commit below to only show the new eo interfaces,
>> > so that
>> > the issue is more evident
>> >
>> >
>> >
>> > > +interface Efl.Text.Font {
>> > > +   [[Font settings of the text
>> > > +
>> > > + @since 1.20
>> > > +   ]]
>> > > +   methods {
>> > > +  @property font {
>> > > + [[The font name and size that is used for the displayed
>> text]]
>> > > + values {
>> > > +font: string;
>> > > +size: int;
>> > > + }
>> > > +  }
>> > > +  @property font_source {
>> > > + [[The source that will be used to lookup the font of the text
>> > > +
>> > > +   The source can be either a path to a font file e.g.
>> > > +   "/path/to/font.ttf", or an eet file e.g.
>> "/path/to/font.eet".
>> > > + ]]
>> > > + values {
>> > > +font_source: string;
>> > > + }
>> > > +  }
>> > > +
>> > > +  @property font_fallbacks {
>> > > + [[Comma-separated list of font fallbacks
>> > > +
>> > > +   Will be used in case the primary font isn't available.
>> > > + ]]
>> > > + values {
>> > > +font_fallbacks: string;
>> > > + }
>> > > +  }
>> > > +
>> > > +  @property font_weight {
>> > > + [[Type of weight of the displayed font
>> > > +
>> > > +   Default is $Efl.Text.Font.Weight.normal\.
>> > > + ]]
>> > > + values {
>> > > +font_weight: Efl.Text.Font.Weight;
>> > > + }
>> > > +  }
>> > > +
>> > > +  @property font_slant {
>> > > 

Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[Daniel Hirt]

Hello,

On Mon, May 29, 2017 at 7:16 AM, Jean-Philippe André 
wrote:

> On 29 May 2017 at 05:18, Davide Andreoli  wrote:
>
> > 2017-05-28 15:00 GMT+02:00 Daniel Hirt :
> > > herdsman pushed a commit to branch master.
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> > >
> > > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> > > Author: Daniel Hirt 
> > > Date:   Mon May 22 17:36:41 2017 +0300
> > >
> > > Efl text: add Font, Format and Style interfaces
> > >
> > > The following text interfaces are added:
> > >   - Efl.Text.Font: font settings that decide which font to display
> in
> > > the text
> > >   - Efl.Text.Format: formatting that affects the looks and layout
> of
> > > the text
> > >   - Efl.Text.Style: decorations and overlays that shouldn't affect
> > the
> > > font choice or the layout
> > >
> > > @feature
> >
> > I think we have another namespacing issue here:
> > Efl.Text.Style do not use any namespace, while Efl.Text.Font and Format
> do,
> >
> > We discussed this already in chat today and we did not find a successfull
> > deal,
> > what I think at this point is that we really should find a rule to
> > apply to every Iface,
> > ...the problem is that we did not find any always-correct rule :(
> >
>
> In short, as I didn't follow that conversation, what were the arguments
> against namespacing "style"?
>
>
As I understand, it's not only about preventing clashes. Widgets are complex
objects, and having your widget doing:
widget.style_normal_color_set(...)
 isn't really better for the user. A better choice might be:
widget.text_style_normal_color_set(...)

A pretty good example from Davide was a combobox with the text widget
in it. There's no guarantee how your object is going to be used in the
future
and how fine the naming of your methods should be, due to unique styles
of inheritance like "composition", which is gaining popularity it seems.

For common inheritance this is less likely to be a problem.


> I also wonder if having 9 color functions is really better than a single
> color function and an enum: color1, color2, color3, shadow, underline,
> etc...?
>
>
I wanted to avoid the enum mess. There's not  a single pro I could think of
other than saving ME writing a few extra functions.


> Also, what objects will implement the below interfaces? I expect
> Efl.Canvas.Text for the default style, and some kind of text item object?
>
>
Efl.Ui.Text is a composite object, with Efl.Canvas.Text. We still needed the
text API to be exposed this in the documentation of Efl.Ui.Text, so users
know that they can manipulate the text object in this widget.


> ideas?
> >
> >
> > PS: I stripped down the commit below to only show the new eo interfaces,
> > so that
> > the issue is more evident
> >
> >
> >
> > > +interface Efl.Text.Font {
> > > +   [[Font settings of the text
> > > +
> > > + @since 1.20
> > > +   ]]
> > > +   methods {
> > > +  @property font {
> > > + [[The font name and size that is used for the displayed
> text]]
> > > + values {
> > > +font: string;
> > > +size: int;
> > > + }
> > > +  }
> > > +  @property font_source {
> > > + [[The source that will be used to lookup the font of the text
> > > +
> > > +   The source can be either a path to a font file e.g.
> > > +   "/path/to/font.ttf", or an eet file e.g.
> "/path/to/font.eet".
> > > + ]]
> > > + values {
> > > +font_source: string;
> > > + }
> > > +  }
> > > +
> > > +  @property font_fallbacks {
> > > + [[Comma-separated list of font fallbacks
> > > +
> > > +   Will be used in case the primary font isn't available.
> > > + ]]
> > > + values {
> > > +font_fallbacks: string;
> > > + }
> > > +  }
> > > +
> > > +  @property font_weight {
> > > + [[Type of weight of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Weight.normal\.
> > > + ]]
> > > + values {
> > > +font_weight: Efl.Text.Font.Weight;
> > > + }
> > > +  }
> > > +
> > > +  @property font_slant {
> > > + [[Type of slant of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Slant.normal\.
> > > + ]]
> > > + values {
> > > +style: Efl.Text.Font.Slant;
> > > + }
> > > +  }
> > > +
> > > +  @property font_width {
> > > + [[Type of width of the displayed font
> > > +
> > > +   Default is $Efl.Text.Font.Width.normal\.
> > > + ]]
> > > + values {
> > > +width: Efl.Text.Font.Width;
> > > + }
> > > +  }
> > > +
> > > +  @property font_lang {
> > > + [[Specific language of the displayed font
> > > +

Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[Jean-Philippe André]

On 29 May 2017 at 05:18, Davide Andreoli  wrote:

> 2017-05-28 15:00 GMT+02:00 Daniel Hirt :
> > herdsman pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> >
> > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> > Author: Daniel Hirt 
> > Date:   Mon May 22 17:36:41 2017 +0300
> >
> > Efl text: add Font, Format and Style interfaces
> >
> > The following text interfaces are added:
> >   - Efl.Text.Font: font settings that decide which font to display in
> > the text
> >   - Efl.Text.Format: formatting that affects the looks and layout of
> > the text
> >   - Efl.Text.Style: decorations and overlays that shouldn't affect
> the
> > font choice or the layout
> >
> > @feature
>
> I think we have another namespacing issue here:
> Efl.Text.Style do not use any namespace, while Efl.Text.Font and Format do,
>
> We discussed this already in chat today and we did not find a successfull
> deal,
> what I think at this point is that we really should find a rule to
> apply to every Iface,
> ...the problem is that we did not find any always-correct rule :(
>

In short, as I didn't follow that conversation, what were the arguments
against namespacing "style"?

I also wonder if having 9 color functions is really better than a single
color function and an enum: color1, color2, color3, shadow, underline,
etc...?

Also, what objects will implement the below interfaces? I expect
Efl.Canvas.Text for the default style, and some kind of text item object?

ideas?
>
>
> PS: I stripped down the commit below to only show the new eo interfaces,
> so that
> the issue is more evident
>
>
>
> > +interface Efl.Text.Font {
> > +   [[Font settings of the text
> > +
> > + @since 1.20
> > +   ]]
> > +   methods {
> > +  @property font {
> > + [[The font name and size that is used for the displayed text]]
> > + values {
> > +font: string;
> > +size: int;
> > + }
> > +  }
> > +  @property font_source {
> > + [[The source that will be used to lookup the font of the text
> > +
> > +   The source can be either a path to a font file e.g.
> > +   "/path/to/font.ttf", or an eet file e.g. "/path/to/font.eet".
> > + ]]
> > + values {
> > +font_source: string;
> > + }
> > +  }
> > +
> > +  @property font_fallbacks {
> > + [[Comma-separated list of font fallbacks
> > +
> > +   Will be used in case the primary font isn't available.
> > + ]]
> > + values {
> > +font_fallbacks: string;
> > + }
> > +  }
> > +
> > +  @property font_weight {
> > + [[Type of weight of the displayed font
> > +
> > +   Default is $Efl.Text.Font.Weight.normal\.
> > + ]]
> > + values {
> > +font_weight: Efl.Text.Font.Weight;
> > + }
> > +  }
> > +
> > +  @property font_slant {
> > + [[Type of slant of the displayed font
> > +
> > +   Default is $Efl.Text.Font.Slant.normal\.
> > + ]]
> > + values {
> > +style: Efl.Text.Font.Slant;
> > + }
> > +  }
> > +
> > +  @property font_width {
> > + [[Type of width of the displayed font
> > +
> > +   Default is $Efl.Text.Font.Width.normal\.
> > + ]]
> > + values {
> > +width: Efl.Text.Font.Width;
> > + }
> > +  }
> > +
> > +  @property font_lang {
> > + [[Specific language of the displayed font
> > +
> > +   This is used to lookup fonts suitable to the specified
> language, as
> > +   well as helping the font shaper backend.
> > +   The language $lang can be either a code e.g "en_US",
> > +   "auto" to use the system locale, or "none".
> > + ]]
> > + values {
> > +lang: string;
> > + }
> > +  }
> > +   }
> > +}
>
>
> > +interface Efl.Text.Format {
> > +   [[The look and layout of the text
> > +
> > + The text format can affect the geometry of the text object, as
> well as
> > + how characters are presented.
> > +
> > + @since 1.20
> > +   ]]
> > +   methods {
> > +  @property format_ellipsis {
> > + [[Ellipsis value (number from -1.0 to 1.0)]]
> > + values
> > + {
> > +value: double;
> > + }
> > +  }
> > +
> > +  @property format_wrap {
> > + [[Wrap mode for use in the text]]
> > + values {
> > +wrap: Efl.Text.Format.Wrap;
> > + }
> > +  }
> > +
> > +  @property format_multiline {
> > + [[Multiline is enabled or not]]
> > + values {
> > +enabled: bool;
> > + }
> > +  }
> > +
> > +  @property format_halign {
> > + [[Horizontal alignment of text 

Re: [E-devel] [EGIT] [core/efl] master 01/04: Efl text: add Font, Format and Style interfaces

[Davide Andreoli]

2017-05-28 15:00 GMT+02:00 Daniel Hirt :
> herdsman pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=da2ef30f2b4d53aa3c1658b83c8c8381743469a0
>
> commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0
> Author: Daniel Hirt 
> Date:   Mon May 22 17:36:41 2017 +0300
>
> Efl text: add Font, Format and Style interfaces
>
> The following text interfaces are added:
>   - Efl.Text.Font: font settings that decide which font to display in
> the text
>   - Efl.Text.Format: formatting that affects the looks and layout of
> the text
>   - Efl.Text.Style: decorations and overlays that shouldn't affect the
> font choice or the layout
>
> @feature

I think we have another namespacing issue here:
Efl.Text.Style do not use any namespace, while Efl.Text.Font and Format do,

We discussed this already in chat today and we did not find a successfull deal,
what I think at this point is that we really should find a rule to
apply to every Iface,
...the problem is that we did not find any always-correct rule :(

ideas?


PS: I stripped down the commit below to only show the new eo interfaces, so that
the issue is more evident



> +interface Efl.Text.Font {
> +   [[Font settings of the text
> +
> + @since 1.20
> +   ]]
> +   methods {
> +  @property font {
> + [[The font name and size that is used for the displayed text]]
> + values {
> +font: string;
> +size: int;
> + }
> +  }
> +  @property font_source {
> + [[The source that will be used to lookup the font of the text
> +
> +   The source can be either a path to a font file e.g.
> +   "/path/to/font.ttf", or an eet file e.g. "/path/to/font.eet".
> + ]]
> + values {
> +font_source: string;
> + }
> +  }
> +
> +  @property font_fallbacks {
> + [[Comma-separated list of font fallbacks
> +
> +   Will be used in case the primary font isn't available.
> + ]]
> + values {
> +font_fallbacks: string;
> + }
> +  }
> +
> +  @property font_weight {
> + [[Type of weight of the displayed font
> +
> +   Default is $Efl.Text.Font.Weight.normal\.
> + ]]
> + values {
> +font_weight: Efl.Text.Font.Weight;
> + }
> +  }
> +
> +  @property font_slant {
> + [[Type of slant of the displayed font
> +
> +   Default is $Efl.Text.Font.Slant.normal\.
> + ]]
> + values {
> +style: Efl.Text.Font.Slant;
> + }
> +  }
> +
> +  @property font_width {
> + [[Type of width of the displayed font
> +
> +   Default is $Efl.Text.Font.Width.normal\.
> + ]]
> + values {
> +width: Efl.Text.Font.Width;
> + }
> +  }
> +
> +  @property font_lang {
> + [[Specific language of the displayed font
> +
> +   This is used to lookup fonts suitable to the specified language, 
> as
> +   well as helping the font shaper backend.
> +   The language $lang can be either a code e.g "en_US",
> +   "auto" to use the system locale, or "none".
> + ]]
> + values {
> +lang: string;
> + }
> +  }
> +   }
> +}


> +interface Efl.Text.Format {
> +   [[The look and layout of the text
> +
> + The text format can affect the geometry of the text object, as well as
> + how characters are presented.
> +
> + @since 1.20
> +   ]]
> +   methods {
> +  @property format_ellipsis {
> + [[Ellipsis value (number from -1.0 to 1.0)]]
> + values
> + {
> +value: double;
> + }
> +  }
> +
> +  @property format_wrap {
> + [[Wrap mode for use in the text]]
> + values {
> +wrap: Efl.Text.Format.Wrap;
> + }
> +  }
> +
> +  @property format_multiline {
> + [[Multiline is enabled or not]]
> + values {
> +enabled: bool;
> + }
> +  }
> +
> +  @property format_halign {
> + [[Horizontal alignment of text (number from 0.0 to 1.0)]]
> + values
> + {
> +value: double;
> + }
> +  }
> +
> +  @property format_valign {
> + [[Vertical alignment of text (number from -1.0 to 1.0)]]
> + values
> + {
> +value: double;
> + }
> +  }
> +
> +  @property format_linegap {
> + [[Minimal line gap (top and bottom) for each line in the text
> +
> +   $value is absolute size.
> + ]]
> + values
> + {
> +value: double;
> + }
> +  }
> +
> +  @property format_linerelgap {
> + [[Relative line gap (top and bottom) for each line in the text
> +
> +   The original line gap value is multiplied by $value.
> +