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...
This is only a partial implementation, work in progress.
The grid object should be a replacement for evas and elementary's
table and grid. Only the layout of items inside the container
is different, otherwise the API should be the same.
For now, this widget is based on an evas table but the full
layout logic will need to be reimplemented, eventually.
@feature
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
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
This adds a separate backend to the "shm" engine that allows allocation
of buffers via libdrm that can be turned into dmabuf handles and used
with the wayland dmabuf extension.
Currently only the intel buffer manager is supported.
The benefit of dmabuf buffers is that they don't require a texture upload
like shm buffers do, and when we have plane support they can be dropped
directly into a plane without a memcpy.
wayland_shm's dmabuf implementation needs acess to libdrm headers for
doing GPU specific memory allocations. We search for these libraries
at runtime with dlopen, so we don't need to find them at build time,
however certain struct definitions and defines are still required.
Split this into two parts, one that makes the base surface, one that
calls the potential back ends.
Once the dmabuf backend is added this will allow a fallback path to
re-initialize the surface as wl_shm if dmabuf fails.
This doesn't really care what the buffers were allocated with, so
let's make this chunk of code useful to both the shm method and the
upcoming dmabuf one
Refactor evas_outbuf_setup a bit so there's only one call to
_evas_shm_surface_create.
Also makes the NULL return on unhandled rotation a lot more obvious.
This reverts commit 6f7608befd.
Item in table and box do not need names as they have an index. This
is breaking ABI for edje application that rely on getting the index
properly when a signal is emitted. To be precise, this did break
elemines.
In this branch I turned on strict eolian type checking and silenced all
of the errors that came to be because of it (fixed some).
I did it so new code will not introduce new errors. We've had more
errors introduced recently, and I believe it's because of ignorance. No
more excuses, compilation will now fail if you fail to handle types
correctly.
We need to fix my workarounds. Many of the .eo files that I worked
around on need to be removed anyway, and a lot of the rest need a lot of
changes, so there was no point wasting my time into fixing it properly.
Jean-Philippe Andre
Derek Foreman
Cedric BAIL
Tom Hacohen