This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
Efl.Container instead.
The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.
Some function names have been modified to look better in C
with the efl_content prefix.
@feature
- Children are now contents
- Efl.Pack_Layout is now a separate class and
merges Pack_Engine.
- Removed dumb class Efl.Pack_Item
- Updated docs
- Added pack_ or grid_ prefixes to some methods
Untested yet. Will need to add the common 3 classes:
- standard
- homogenous
- homogenous max_size
And then implement a true custom layout function, that
respects weights in a certain manner (need to define it
clearly).
This reuses the Evas.Box code, since we are still using the
box internally. The flow layout function is far from perfect
(it works well only with items of same height).
This shows how to use specific layouts provided by EFL.
So, since we don't have function pointers, all the solutions
to reimplementing the layout function are quite convoluted:
1. use events
2. reimplement layout func
3. use an extra object
4. use a generic class (non instanciated)
Promises don't apply here (layout will run multiple times).
Problems:
1. Multiple event callbacks will be called, resulting in
potential performance impact, extra events, etc...
Also, there is no way to define standard implementations
that would be provided by the framework.
2. Reimplementation of a function requires extra EO work
(create an EO class, etc...), doesn't allow on-the-fly
change of the layout method.
3. Probably the best solution is to have an object implementing
the layout. But this means creating an extra object along
with the container.
4. To avoid the extra object, use a class, and reimplement
a @class function. This unfortunately requires extra
EO work.
Solution 4. has been selected, but it's not very nice...
This should be the only linear packing container.
This replaces: evas box and elm box.
Edje box needs to be kept around for compatibility,
but it stays an EDC object only (for apps).
Lots of things are still to be fleshed out in this
box implementation:
- Simplify smart object / elm widget code
- Maybe stop using evas object box altogether
- Implement other layout strategies
@feature
Jean-Philippe Andre