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?
I think it would be better to support asynchronous update this way all changes would be applied during a window commit. Without asynchronous update then you would need to do a window commit every time the input region/rect is changed. Supporting async allows just one window commit where all changes will be applied.
I have merged some of these API functions today, so this patch will most certainly not apply cleanly anymore. There are still a few APIs on this that are not in upstream yet (mostly cursor APIs, and the input rectangle one).
@CHAN Ok, I went through the list of API functions here and have found which ones are not done yet. The list of these functions is below. I would suggest making new patches for these because this current patch will certainly not apply cleanly any more. Another suggestion I have is to separate it into a patch for ecore_wl2_window functions, and another patch for ecore_wl2_input functions. An even Better suggestion would be a separate patch for Each Function. This will allow easier review and be easier to follow any comments, suggestions, or discussions that will take place.