These APIs were used in Tizen, they are added to make management easier.
It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
There are some minor things here that need corrections. Also, can you improve the commit Summary a little please. It makes no mention of adding new APIs
These 2 can go on the same line:
int ret, last_dpy_err;
There should not be a space between * and ewd.
This should return NULL, not 0.
These should probably use EINA_SAFETY macros
Use EINA_SAFETY macro here
Use EINA_SAFETY macro here
To fix the build error, change the meson.build file in src/lib/ecore_wl2 so that it adds wayland-cursor as a dependency:
ecore_wl2_deps = [
dependency('wayland-client'), dependency('wayland-server'), dependency('xkbcommon'), dependency('wayland-cursor'), wayland_protocol, dl, m, ecore, ecore_input, libdrm, buildsystem
When the above is changed, then this patch will build.
The rest of the changes look good.
Most of the proposed API here don't seem to be in line with how we're trying to use the Wayland protocol.
I'm not convinced we need many of these in upstream, particularly the ones which are stubs for code that can't/won't work correctly, or the ones which directly manipulate libwayland internals using an API which matches libwayland--thus forcing our "abstraction" layer to no longer be an abstraction.
This function does nothing besides set an internal value that is never accessed. It's effectively dead code and should not be merged.
I'm quite certain that we don't want to continue mimicking X-style cursors with this type of API in EFL. That applies to all "cursor name" type APIs, regardless of what may exist in higher level components.
Can you provide a common use case for this?
I don't see why this or the following two functions are necessary given that ecore_wl2_window_input_region_set exists and is superior based on it:
This is effectively dead code since it's impossible to know whether a surface is actually minimized.
This really doesn't seem like a sane API in any sense.
ecore_wl2_window_input_rect_set(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)
ecore_wl2_window_input_rect_add(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)
ecore_wl2_window_input_rect_subtract(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)
Those APIs created for two or more input areas.
Anyways, In contrast to ecore_wl2_window_input_rect_set(), the ecore_wl2_window_input_region_set() has additional features. (pending update.)
So now those two APIs has a bit different behavior.
We can use ecore_wl2_window_input_region_set() instead of ecore_wl2_window_input_rect_set(),
if there is no pending update feature in the ecore_wl2_window_input_region_set() API or if we support it.
@devilhorns Do we need to update it asynchronously(pending)? if so, we need a ecore_wl2_window_input_rect_set() API. and any opinion about it?