@cedric
Does "Efl.Ui.Layout should compose with Efl.Canvas.Layout." mean efl_composite_attach()? When I wrote patch for that, subclasses inheriting from Elm.Layout cannot override Edje.Object methods.

The signal API needs to be discussed with @singh.amitesh so we can find the right balance between a specific signal API and a more generic asynchronous message API (with payload, eg. for edje messages).

In T5315#86266, @conr2d wrote:

@cedric
Does "Efl.Ui.Layout should compose with Efl.Canvas.Layout." mean efl_composite_attach()? When I wrote patch for that, subclasses inheriting from Elm.Layout cannot override Edje.Object methods.

I'm afraid composite is a shortcut that we can not take here. Inheritance of the interface and manual implementation might be the way to go. Most functions in elm_layout will be just a simple call forward.

In T5315#86906, @jpeg wrote:

In T5315#86266, @conr2d wrote:

@cedric
Does "Efl.Ui.Layout should compose with Efl.Canvas.Layout." mean efl_composite_attach()? When I wrote patch for that, subclasses inheriting from Elm.Layout cannot override Edje.Object methods.

I'm afraid composite is a shortcut that we can not take here. Inheritance of the interface and manual implementation might be the way to go. Most functions in elm_layout will be just a simple call forward.

Ok so after thinking a bit more and talking with @cedric, composition may be the way to go. According to @conr2d there might be some API clash of some sort. Let's figure out what the exact problems are and whether this is really relevant. We have no Elm.Layout child class that overrides Edje.Object methods at the moment (Efl.Ui.Image is not a layout but overrides Edje.Object functions).
But the most important point is that we get rid of the internal object API (I have a pending patch).

In T5315#86904, @jpeg wrote:

The signal API needs to be discussed with @singh.amitesh so we can find the right balance between a specific signal API and a more generic asynchronous message API (with payload, eg. for edje messages).

The signal callback API will be manually bound. This means 2 extra APIs to bind manually: signal_cb_add and del. signal_emit does not require manual binding as it only deals with strings.
We also don't need a generic infrastructure to send async messages right now. Edje will keep its current implementation for the foreseable future. Anyway it is bound to what EDC supports.

See also D4914

Now in Edje.Object we have the following methods:

1. No problem:

Mirrored, language (may need common interface? but which one?)
Seat functions (specific to edje object - all good)

2. signal & message functions

Signal cb functions need manual binding
There is no EO API to listen to messages from EDC but it could easily be implemented as an event)

3. Specific layout & calc functions

Maybe need an interface? Maybe not? Some of those functions would not be shared with other objects - specific to edje objects.
They might need a prefix like "layout_" or "calc_" so that they don't disturb too much autocompletion.

4. Text

This needs to be done. And sync'ed with the Text EO API. @herdsman are you working on this? Should I just do the Efl.Part implementation and then let you deal with pure text stuff? You might even be able to do a lot of the work using composition inside the efl_part implementation.

5. Missing global functions

edje_file/mmap_data_get and such

6. Color/text/size classes

@conr2d I think we are still missing some of your patches

7. Preload, load_error, file_set

Once the futures work well, the proper common file API needs to be implemented. load_error then becomes irrelevant (future error cb).

8. animation vs. play

The documentation is not clear. My understanding is that "animation" stops animations from happening, in the sense that transitions are now instant state changes. But programs still run. Disabling "play" means that programs don't run. The edje is frozen in time (not sure how resizing affects its parts).

9. part drag APIs

need an interface and efl_part

10. part external APIs

need efl_part and maybe an interface (TBD as an interface means the widgets themselves should implement it).
part_external_content may not be required

In T5315#87811, @jpeg wrote:

4. Text This needs to be done. And sync'ed with the Text EO API. @herdsman are you working on this? Should I just do the Efl.Part implementation and then let you deal with pure text stuff? You might even be able to do a lot of the work using composition inside the efl_part implementation.

I have done it. Will reference my branch with the changes here for your approval.

In T5315#87812, @herdsman wrote:

In T5315#87811, @jpeg wrote:

4. Text This needs to be done. And sync'ed with the Text EO API. @herdsman are you working on this? Should I just do the Efl.Part implementation and then let you deal with pure text stuff? You might even be able to do a lot of the work using composition inside the efl_part implementation.

I have done it. Will reference my branch with the changes here for your approval.

Ah. Then I hope my recent changes are not going to impact your merge. Let me know if you need any help, I'd like to rid edje object of all the text APIs asap.

I found some massively problematic APIs:

• sizing_eval
• sizing_restricted_eval

sizing_restricted_eval is actually quite fine, as it's not implemented anywhere outside of elm_layout.c
sizing_eval is a massive problem as its definition is:

• #1. Mark an object as requiring recalc, but don't do anything now (async).

This is similar to Efl.Canvas.Group.group_need_recalculate.set.

The problem is that some widgets do:

• #2. Calculate min/max/aspect size hints synchronously.

Or even:

• #3. Calculate size hints and geometry synchronously.

Some widgets even implement Efl.Canvas.Group.group_calculate along with sizing_eval. The exact behavior from the caller point of view is completely undefined: was the object just flagged (1)? were the hints updated (2)? or was the object moved & resized (3)?

elm_layout_sizing_eval() is used a lot throughout EFL and by applications...

There is no EO binding for edje file APIs.

I would say that Efl.Ui.Layout is now done, with two exceptions:

1. It doesn't implement all the functions in its API (ie. some interfaces are partially implemented), and doesn't provide a way to get the internal Edje object
2. It inherits from Elm.Widget which is not done at all: See T5363

@herdsman in Edje.Object there are still a lot of remaining text part APIs.

@herdsman in Edje.Object there are still a lot of remaining text part APIs.

This is still true to this day.

This is now mostly done! Remaining to-do:

edje_object:

• Rename Edje.Object to Efl.Canvas.Layout (@jpeg)
• Two "text" APIs remain, including a function cb: text_change_cb, item_provider (@herdsman)
• All the Font/Size/Color class interfaces need to be finalized (@conr2d)
• Sync/Async file interface needs to be done (@cedric)

elm_layout:

• theme.set API may change if the theme structure is specifically adapted to EO

commit 54ae9cc18b6c0fdb9a10f03ad2681587ca062c6c
Author: Amitesh Singh <amitesh.sh@samsung.com>
Date: Wed Dec 6 12:15:39 2017 +0900

edje: rename Edje.Object to Efl.Canvas.Layout

commit bdc396945281290c3d4b0622d9f9a3945af01097
Author: Amitesh Singh <amitesh.sh@samsung.com>
Date: Tue Dec 5 16:00:08 2017 +0900

edje: rename intf Efl.Canvas.Layout_Group to Efl.Layout.Group

commit c7aa3b2f83bfed886cf5bcd53dea21d0c9d11a99
Author: Amitesh Singh <amitesh.sh@samsung.com>
Date: Tue Dec 5 15:29:07 2017 +0900

edje: rename intf Efl.Canvas.Layout_Calc to Efl.Layout.Calc

commit 7b3fde4d4b9047b39a1dc0c7794500364f689325
Author: Amitesh Singh <amitesh.sh@samsung.com>
Date: Tue Dec 5 14:39:20 2017 +0900

edje: rename intf Efl.Canvas.Layout.Signal to Efl.Layout.Signal

Still missing the landing of @herdsman branch remotes/origin/devs/herdsman/annotation_item which still has a few issue. I might take over and finish the last bit as their isn't much there left.

With 4a905a22a485388a5e4ba9fb25ff5ca381420ba7 we have the provider_cb out of the way.

Efl.Ui.Layout work is completed (only one API: theme).

Remaining non-interface API's in Efl.Canvas.Layout are:

• animation --> @taxi2se I think this is related to your Animation/Playable changes
• seat & seat_name -> this could be in an interface so that Efl.Ui.Layout can also implement it
• access_part_iterate [BETA] -> this could be marked as stable and put in an interface as well

Thoughts?

A #Goal ticket should not be set to a milestone.

@cedric this looks like it's done?