Before this commit, when using any of the wayland backends, if the user
requested an ecore_evas window of width x height, the reported size of
the window would include the frames width and height.
Now the requested size is stored on the ecore_evas and reported when
ecore_evas_geometry_get() is used, although the ecore_evas is still
created with additional space for the frame area.
This is one of the reasons causing bug #1673.
SVN revision: 83042
Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for
the .la, use the EFL_ macros to generate the contents to be used in
automake files.
There is a nasty bit that libtool will parse Makefile*.am and will not
get _DEPENDENCIES from _LIBADD and _LDADD if these are in
@REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The
contents of this is almost the same as _LIBADD or _LDADD with the
"_INTERNAL_" replacement name.
I hope the code will be result will be shorter and consistent as there
is less places to change when we add/remove dependencies.
Statistics are quite impressive (diffstat):
{{{
37 files changed, 663 insertions(+), 1599 deletions(-)
}}}
SVN revision: 82785
buffer is lightweight and dependency for many engines, merge it back
into core.
extn is a module on its own, and it's the only one linking to
ecore_ipc, no need to add that to ecore_evas.
minor cosmetic changes to configure to make output consistent.
SVN revision: 82648
no - not planning a backport of this at this stage. small thing. maybe
backport (and chlog/news) if this doesnt cause any new issues?
SVN revision: 82549
- EVAS_CALLBACK_FREE and EVAS_CALLBACK_DEL were doing the same thing
at different stages, causing a segv due double free.
- extn->file.updates and its Ipc_Data_Update were leaking.
PS: I can't backport this to 1.7, but the problem is still
there. Could someone look into those?
SVN revision: 81304
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280