The challenge here is that the native window representation is stored
in Ecore_Evas's prop.window. But currently there is no checking of
what driver the Ecore_Evas is for when calls are made to e.g.
ecore_evas_software_x11_window_get.
The attached change to Ecore makes the appropriate functions return 0
or NULL if the driver for the Ecore doesn't match as expected. This
can then be used to identify if an Ecore_Evas is e.g. from X11 or from
Wayland.
SVN revision: 71453
Subject: [E-devel] ecore_evas typedef patch src/lib
the attached patch adds
typedef void (*Ecore_Evas_Event_Cb) (Ecore_Evas *ee);
in Ecore_Evas.h and ecore_evas_private.h
Ecore_Evas_Event_Cb is then used within :
ecore_evas.c
ecore_evas_psl1ght.c
ecore_evas_win32.c
ecore_evas_wince.c
ecore_evas_x.c
SVN revision: 68140
mouse is in on init (as events wont always give this) and focus
is set on show if appropriate if no focus in/out events come
from the back-end later
Fix setting override state to only hide if it should be
visible at that point in x back end support
SVN revision: 65508
EWS is a new Ecor_Evas engine that builds on top of other engines. It
will create a backing store Ecore_Evas and ecore_evas_ews_new()
windows are created in it as images, but transparent to the outside
users (similar to buffer's ecore_evas_object_image_new()).
It provides a basic windowing system, with a known background object
that can be changed to your pleasure, and issue Ecore_Events to notify
of new windows and changes like movement, etc. Then you can write a
simple window manager based on it. (See example, Elementary will
contain one as well).
Backing store is determined by your best engine (as in
ecore_evas_new()) or specified with ecore_evas_ews_engine_set() or
environment variable $ECORE_EVAS_EWS (format:
engine-name❌y:w:h:options). The size can be set with
ecore_evas_ews_setup().
SVN revision: 63848
allocate memory for list variables & rectangles unless we need to (ie:
If there are no evas_render_updates to do, then there is no need to
allocate extra list variables & rectangles).
SVN revision: 63528
Hi all,
I've fixed a minor bug in the ecore_evas_gl_x11_pre_post_swap_callback_set API.
It wasn't setting a post_swap callback properly.
Please review it.
BR,
SVN revision: 62785
and opengl_x11 engines and replace with ecore_x calls.
NB: I did not touch software_16 or software_8 so we cannot yet remove
the XLib linking wrt ecore_evas. I leave that exercise to 'the old
man' as per our convo this morning...but this does put us one step
closer ;)
SVN revision: 61743
Some fixes for OpenGL wrt xcb (minor stuffs).
NB: We already use ecore_x for some things in here, so let's keep
duplicated code down to a minimum and resuse what we already have ;)
SVN revision: 61676
Subject: [E-devel] XRender engine causes ecore build failure
while building ecore. The problem is that this engine was removed from evas
but not yet completely from ecore. I was on IRC with Vincent Torri (vtorri)
and Daniel Juyung Seo (SeoZ) and the consensus was to remove the code for the
XRender engines, both the Xlib and XCB versions.
There is a switch over the different engine types, where there are still a few
places left where XRender is handled, grep for "xrender" or "XRENDER" and you
will find them. The question is whether to just return NULL in order to signal
that this engine is not supported or to remove the whole thing. The latter
could break binary compatibility, therefore I left those stubs in.
SVN revision: 60502
This common interface allows engines to provide whole screen
information to users.
Right now just X is implemented and it queries the size of the default
screen. I hope this is fine.
SVN revision: 59761
Carsten Haitzler
Cedric BAIL
Mike Blumenkrantz
Christopher Michael
Jihoon Kim
Jonas M. Gastal
Jérémy Zurcher
Vincent Torri
Gustavo Sverzut Barbieri
ChunEon Park
Lucas De Marchi
Ulrich Eckhardt
Daniel Juyung Seo
Doyun Kang