We don't want to execute any of the function below if t is NULL. Its not
only about strdup but alsa ecore_x_netwm_name_set which might dereference it.
CID 1039400
- ecore_evas_pixmap_visual_get
- ecore_evas_pixmap_colormap_get
- ecore_evas_pixmap_depth_get
Assign interface functions for above when creating the new interface.
When creating the pixmap, store the visual and colormap for later
retrieval.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- Add "pixmap" structure to engine_data.
- Free the front and back pixmaps when the ecore_evas gets freed.
- On resize, drop the backing pixmap if size is different.
- Before we render, check pixmap size vs EE size and create new
backing pixmap if needed.
- After we have rendered into the backing pixmap, flip it to the
front so that any calls to "pixmap_get" will return the proper one.
- Add pixmap_new_internal code (the actual guts for all this)
NB: These can be used to create an internally double-buffered
ecore_evas that renders to a pixmap (not a window).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When moved mouse among two objects having cursor set,
EVAS_CALLBACK_MOUSE_OUT and EVAS_CALLBACK_MOUSE_IN are fired.
I observed that evas_object_del in callback of EVAS_CALLBACK_MOUSE_OUT
calls EVAS_CALLBACK_MOUSE_IN
so that newly added cursor object was detached.
It is a very tricky things to get header order right on windows. Having that
order only in .c files simplify the work a lot. So let's try to do it with
Ecore_Evas after it rewrite and split into modules.
I add new example related with this. (ecore_evas_extn_socket & plug example)
ecore extn use this infrasturcture, server app and client app can communicate each other
later, this can be used to contorl access message
SVN revision: 83942
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
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
Michal Jagiello
Stefan Schmidt
Mike Blumenkrantz
Chris Michael
Sebastian Dransfeld
Ryuan Choi
Cedric BAIL
Jiyoun Park
Cedric Bail
Jiyoun Park
Gustavo Sverzut Barbieri
Leandro Pereira
Carsten Haitzler
Flavio Vinicius Alvares Ceolin