2016-04-11 22:08:35 -07:00
|
|
|
import eina_types;
|
|
|
|
|
|
|
|
interface Efl.Pack (Efl.Pack_Item)
|
|
|
|
{
|
|
|
|
[[API common to all UI container objects.]]
|
|
|
|
legacy_prefix: null;
|
|
|
|
methods
|
|
|
|
{
|
|
|
|
/* should this actually just be the eo children list? */
|
|
|
|
contents_iterate {
|
|
|
|
[[Begin iterating over this object's children.]]
|
|
|
|
return: free(own(iterator<Efl.Pack_Item *> *), eina_iterator_free) @warn_unused;
|
|
|
|
}
|
|
|
|
contents_count {
|
|
|
|
[[returns the number of UI elements packed in this container.]]
|
|
|
|
return: int;
|
|
|
|
}
|
|
|
|
clear {
|
|
|
|
[[removes all packed children, and unrefs them]]
|
|
|
|
}
|
|
|
|
unpack_all {
|
|
|
|
[[removes all packed children, without changing their refcount]]
|
|
|
|
}
|
|
|
|
unpack {
|
|
|
|
[[removes an existing item from the container, without unref.
|
|
|
|
|
|
|
|
delete the item directly if you actually wanted to pop and unref
|
|
|
|
]]
|
|
|
|
return: bool; [[$false if $subobj wasn't a child or can't be removed]]
|
|
|
|
params {
|
|
|
|
subobj: Efl.Pack_Item*;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* FIXME: confusing? two meanings: named slot vs. append */
|
|
|
|
pack {
|
|
|
|
[[Adds an item to this container.
|
|
|
|
|
|
|
|
Depending on the container this will either fill in the default
|
|
|
|
spot, replacing any already existing element or append to the end
|
|
|
|
of the container if there is no default part.
|
|
|
|
|
|
|
|
The container takes ownership of this object. This means if packing
|
|
|
|
failed, the object will be unrefed.
|
|
|
|
]]
|
|
|
|
params {
|
|
|
|
subobj: Efl.Pack_Item*;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
@property padding {
|
|
|
|
[[Padding between items contained in this object.]]
|
|
|
|
set {}
|
|
|
|
get {}
|
|
|
|
values {
|
|
|
|
pad_horiz: double;
|
|
|
|
pad_vert: double;
|
|
|
|
scalable: bool;
|
|
|
|
}
|
|
|
|
}
|
Efl.Ui.Box: Implement way to override layout function
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...
2016-04-12 00:20:54 -07:00
|
|
|
@property layout_engine {
|
|
|
|
[[Implementation of this container's layout algorithm.
|
|
|
|
|
|
|
|
The default value is the same as the widget class (eg. Efl.Ui.Box).
|
|
|
|
]]
|
|
|
|
set { return: bool; }
|
|
|
|
get {}
|
|
|
|
values {
|
2016-04-12 02:16:20 -07:00
|
|
|
engine: const(Eo.Class)*; [[A class implementing a class function layout_do.]]
|
|
|
|
data: const(void)*; [[Any data to pass along to layout_do.
|
|
|
|
Owned by the caller. Depends on the layout engine.]]
|
Efl.Ui.Box: Implement way to override layout function
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...
2016-04-12 00:20:54 -07:00
|
|
|
}
|
|
|
|
}
|
2016-04-11 22:08:35 -07:00
|
|
|
layout_update @protected {
|
|
|
|
[[Implementation of this container's layout algorithm.
|
|
|
|
|
|
|
|
EFL will call this function whenever the contents of this
|
|
|
|
container need to be re-layed out on the canvas.
|
|
|
|
|
|
|
|
This can be overriden to implement highly specific layout
|
|
|
|
behaviours.
|
|
|
|
]]
|
|
|
|
}
|
|
|
|
layout_request {
|
|
|
|
[[Requests EFL to call the @.layout_update method on this object.]]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
events {
|
2016-04-14 00:41:57 -07:00
|
|
|
child,added: Efl.Pack_Item*; [[sent after a new item was added]]
|
|
|
|
child,removed: Efl.Pack_Item*; [[sent after an item was removed, may happen after unref]]
|
|
|
|
layout,updated; [[sent after the layout was updated]]
|
2016-04-11 22:08:35 -07:00
|
|
|
}
|
|
|
|
}
|