This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
This improves a rare error message when a function is called on an
efl_part() that does not implement it. Example: calling a swallow
function on a non-swallow part.
This isn't entirely fool-proof but should already help quite a bit.
This also changes how the efl_part proxies are stored: the variable
is not reset to NULL every time we use it, instead we check it in
the del intercept.
Note: _part_reuse_error() can not be enabled inside
_internal_proxy_get because there are valid use cases such as:
func1(efl_part(obj, part), func2(efl_part(obj, part), ...), ...)
Here we use two efl_part() at the same time, on the same object,
but we haven't entered "func1" yet when we are reaching the second
call to efl_part(). This is completely valid and there is pretty
much no way to detect this.
I think I will improve this later with a core function on
Efl.Object like "debug_string".
Ref T5584
As Dave pointed out, those are meant for internal use by Edje and
the plugins implementation, rather than for apps. This removes
ugly and complex code. Makes me happy :)
Note that I've kept the composition for now. We can remove it
as efl_content_get() must work on the part handle anyway. But it
can be used as a quick solution.
This implements edje_object_part_external_object_get() using
efl_content_get() on the part object. Note that there are now
two ways to call APIs on the external part:
- direct call to the efl_part() as if it was the object itself
(implemented by composition),
- get a handle with efl_content_get(efl_part()) and manipulate
it directly (it is the real object).
Do we need this? Do we need the composition trick? Should we have
only one of those solutions implemented?
This effectively replaces edje_object_part_external_object_get
and allows all function calls except those from Efl.Object.
Is this good enough? Or do we need access to the real object?
This adds a new class: Efl.Canvas.Layout.External.
I hate this long name...
This class represents an external part, and for now only
supports param_set/get as well as param_type_get. For now
param_type_get() still returns an Edje_External_Param_Type and
not another more generic type.
TODO: enumerate choices, return object, return content
Daniel Kolesa
Jean-Philippe Andre