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. The attached change to Elementary makes a small refactor to use existing code that was already conditional on the Elm engine to retrieve the underlying window - thus allowing elm_win_xwindow_get to return 0 in the case when called on a Wayland based Elm window. Patches have been tested against X11 and Wayland built together by running elementary_test. Cheers, Rob
0001-Ecore_Evas-Return-zero-from-ecore_evas_-_window_get-.patch
Description: Binary data
0001-elementary-win-Refactor-X11-code-to-use-evas_-_windo.patch
Description: Binary data
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
