This should now fix the part API usage once and for all.
EFL should have no part name in any of its APIs beyond
the Efl.Part interface.
Part proxy objects (may be real objects) have a lifetime
of only one function call, in a fashion similar to eo_super.
@feature
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
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...
I chose the name "pack" instead of containers because it
is shorter, and allows out-of-the-box short C names like
efl_pack_end() instead of efl_container_pack_end().
All Pack interfaces will use the same efl_pack eo prefix.
This is still work in progress.
@feature
Efl.Flip is now the enum, the interface is Flipable.
We could even use names like Efl.IFlip a la Java.
eo_prefix is used to have pretty names in C. legacy: null
is removed from the enums. orient_x0 is removed and only
defined in C with #define
Summary:
Implement common interface efl_ui_progress and inherit slider and progressbar from common interface.
Currently legacy APIs will also call interface functions and later it can be deprecated.
This interface will be moved to EFL in src/lib/efl/interfaces when elementary is merged into efl.
Test Plan:
elementary_test -to 'slider'
elementary_test -to 'progressbar'
Reviewers: singh.amitesh, raster, tasn, felipealmeida, woohyun, cedric, jpeg
Subscribers: saurabhbunty, alok25
Differential Revision: https://phab.enlightenment.org/D3759
This fixes a crash in ecore_init, calling a weak function from
libefl that was resolved to NULL.
So, here's a fun thing happening with GCC < 5.3. Since a1a506e13e
all EOAPI and EO class_get() functions are weak symbols. This means
that all APIs inside libefl.so are weak.
As a result, gcc linker with --as-needed skipped linking to libefl
since not a single strong symbol from libefl was required by
libecore. This is actually a bug in gcc linker since we do in fact
use symbols from libefl, just weak ones.
GCC 5.3 seems to be fixed, so people with GCC 5.3+ will not
experience any build/runtime issue. The current patch is
a workaround that bug, by artifically creating a strong symbol
required by ecore.
Other libraries than ecore might also need to call
__efl_internal_init, if they end up not being linked to libefl.
Summary:
Added flip and orientation interface and used them in evas_image.
Removed efl_image_orientation_set API and used efl_orientation_set and efl_flip_set API.
In implementation part, converted enums back and forth in order to keep current implementation as it is.
Test Plan: src/examples/evas/evas-images5.c
Reviewers: singh.amitesh, raster, tasn, herdsman, woohyun, cedric, felipealmeida, jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3844
this adds a core vpath subsystem to efl that allows paths like:
~/file.jpg
~user/file.jpg
(:tmp/file.jpg
(:config/file.jpg
(:videos/file.mp4
(:pictures/file.jpg
(:app.config/mycfg.cfg
etc. to be translated/looked up. it is desitgned to be async and call
event callbacks when ready. the reason for this complexity is fo in
future also handle:
file:///whatever/file.jpg
http://blah.com/file.jpghttps://blah.com/file.jpg
ssh://blah.com:~/file.jpg
etc.
@feature
This interface groups all low-level animated image functions.
FIXME:
- Rename to Efl.Image.Animated once eolian is fixed
- Fix mess with emile enum (loop_hint)
It has been decided that we would not use any namespace for interface
and they will sit in efl main namespace.
This patch doesn't correct the naming of the event has we don't have a
prefix for event. We do still have EFL_ANIMATOR_EVENT_ANIMATOR_TICK,
instead of a nicer EFL_EVENT_ANIMATOR_TICK.
this define means that any 1.18 feature can now be detected by testing for
the presence of this define, even before the release has gone out
for future (non-bugfix) releases, further defines should be created in addition
to this one in order to provide detection for features in each version
Summary:
Fix Efl.h include problem of the installed header "efl_types.eot.h".
Move efl_types.eot to src/lib/efl/interfaces to compile and install at
the same place of other Eolian-generated headers.
Test Plan: compile and test expedit
Reviewers: felipealmeida, stefan_schmidt, tasn, cedric, q66, JackDanielZ
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3670
Moved the Ecore.Time @extern struct to Efl lib and defined it as
specified in C specification for struct tm. Thus, bindings can be
automatically generated for where struct tm is used.
This create some possible naming clash and is why I come up with
efl_gfx_color*_type_set functions. We will have to think about this more
carefully as it makes sense to now pass this colors directly to our color
API. Ideally the default 8 bits interface would become just a convenience
wrapper around the more complex possibility.
Rename a few things:
- draw helper -> efl_draw
- Ector_Rop -> Efl.Gfx.Render_Op
- ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops)
- ector_memfill -> draw_memset32 (and invert arg order to match memset)
The main rasterizer file is now draw.h in static_libs/draw
This is a non functional change, simple code refactor.
This creates the new interface
Efl.Gfx.Filter
And the implementation is a mixin (evas_filter_mixin.c):
Evas.Filter
All the filter rendering code has now been moved to this
new file. TODO: Merge image filtering.
So SVG support all kind of primitive, but really they are just sugar
on top of the simpler cubic bezier curve. Let's simplify our backend
by just supporting them and the simple line. We still provide all
the sugar, but via helper function that do convert to the right
number of Bezier curve.
Jean-Philippe ANDRE
Tom Hacohen
Yeshwanth Reddivari
Jean-Philippe Andre
Carsten Haitzler
Cedric BAIL
Mike Blumenkrantz
Vitor Sousa
Felipe Magno de Almeida
Guilherme Lepsch
Subhransu Mohanty
Savio Sena
