this code is mostly copied from weston:
78d4bf9a3ec990dceee23fd53962a69891352a0e
9c93179023fe894e417ccd20533d72d672d976fc
credit to Carlos Garnacho <carlosg@gnome.org> as original author
fix T3455
@feature
Correct support all types of program actions for constructing
list of targets.
There are 3 group of actions, that related to targets:
- Does not support targets at all.
- Support only parts as targets.
- ACTION_STOP, that supported parts and other programs as targtes.
@fix
Warning: This disables CXX examples because they use
now-internal APIs that have no EO API binding.
Those examples should be updated to use Efl.Ui widgets... once
we have them.
base class objects will ask their parent object to get the loop. this
means it recurses all objects regardless of type until it finds an
object that returns a proper loop object - eg a loop object returns
itself, a window, gfx/ui object returns the mainloop object etc. etc.
@feature
I can't figure out what is wrong with using BUILT_SOURCES. It should
work, but doesn't. Moving to use _SOURCES is impossible again (variable
again). Using the _DATA is the only technically working solution. Which
they will be installed on your system even if you don't need them. If
you find a way around it and still get them to build, please patch.
This reverts commit 13b4a56ddc.
sorry cedric. this totally broke efl build. eo/eolian etc. is not
built before evas for example and so build totally falls apart.
yes - it makes no sense that this one change would cause that. it
doesnt make sense. but it did. :(
The idea is that when you are processing those events from within
they won't call twice any of the event until all of them are processed
at least once (Or one of them did return EINA_FALSE).
these files were created containing code which was very obviously copied from
weston. when copying code, copyright headers must also be copied in order to
comply with licenses.
Summary:
To ensure initialize all fields of Ecore_Event_Mouse_XXX,
use calloc() instead of malloc().
Test Plan: N/A
Reviewers: gwanglim, cedric, raster, devilhorns, ManMower, zmike
Subscribers: jpeg, input.hacker, JHyun
Differential Revision: https://phab.enlightenment.org/D3906
Box, Table and Grid now belong to legacy land.
Their Evas counterparts are already not installed anymore,
and Efl.Ui.Box and Efl.Ui.Grid are here to replace those
widgets (note: code was initially copy & pasted).
This should fix installed EO files consistency.
this finds child objects by walking the child tree searching children
by using the search string which can be name, class:name and both
class and name can also be a glob.
@feature
The Pack interface is meant to unify all containers APIs.
Box and Grid a two new widgets implementing this new API. Box
has a new layout function that seems to correspond more to developers
expectations.
The Pack interface also provides a way to implement custom layout
functions, by the way of layout engine classes.
Still TODO:
- Named/Slot containers API with parts (eg. Elm.Layout, Edje.Object)
- Unify those with Pack (naming to be argued over: pack, content, ...)
- Deprecate (remove out of EO land) old containers
- Implement proper layout functions for Grid and fix Box.Flow
@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 fixes the linear API usage with a table.
TODO:
- remove internal table (as it doesn't support layout funcs)
- implement multiple layout functions (regular, homogenous, ...)
This shows how to implement a layout function, with the
required Eo class boilerplate (note: could probably be
simpler with the appropriate macros, or a better solution
to create classes on the fly in C).
The layout function itself is awful, but shows that "it works".
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...
Mike Blumenkrantz
Chris Michael
Derek Foreman
Stefan Schmidt
Carsten Haitzler
Mykyta Biliavskyi
Jean-Philippe Andre
Cedric Bail
Duna Oh
Tom Hacohen