These APIs were used in Tizen, they are added to make management easier.
- ecore_wl2_display
- ecore_wl2_input
- ecore_wl2_window
No Linters Available |
No Unit Test Coverage |
Buildable 14061 | |
Build 9765: arc lint + arc unit |
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
src/lib/ecore_wl2/Ecore_Wl2.h | ||
---|---|---|
688 | @since 1.23 | |
701 | @since 1.23 | |
741 | @since 1.23 | |
753 | @since 1.23 | |
763 | @since 1.23 | |
1599 | @since 1.23 | |
1610 | @since 1.23 | |
1621 | @since 1.23 | |
1631 | @since 1.23 | |
src/lib/ecore_wl2/ecore_wl2_display.c | ||
701 | These 2 can go on the same line: int ret, last_dpy_err; | |
890 | There should not be a space between * and ewd. Ecore_Wl2_Display *ewd; | |
1139 | This should return NULL, not 0. EINA_SAFETY_ON_NULL_RETURN_VAL(display, NULL); | |
src/lib/ecore_wl2/ecore_wl2_input.c | ||
1864 | These should probably use EINA_SAFETY macros | |
1881 | Use EINA_SAFETY macro here | |
1897 | 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.
Great work !! :) We cannot push this upstream yet tho because of the freeze for 1.23 release. After the freeze is over, I will push these changes.
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.
src/lib/ecore_wl2/ecore_wl2_input.c | ||
---|---|---|
771 | What? | |
1824 | This function does nothing besides set an internal value that is never accessed. It's effectively dead code and should not be merged. | |
1895 | 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. | |
1911 | Can you provide a common use case for this? | |
src/lib/ecore_wl2/ecore_wl2_window.c | ||
836 | 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:
| |
1120 | This is effectively dead code since it's impossible to know whether a surface is actually minimized. | |
1134 | See above. | |
1818 | 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.
This will likely need to be rebased against EFL master due to the Ecore_Wl2.h file changes
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 I have already merged some of these new APIs. I will have to go through the list in the patch and find out which ones are not completed yet, then we can examine those APIs and discuss them.
@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.
Window Functions:
Input Functions:
@devilhorns Hi.
I made a patch for ecore_wl2_input_keyboard_repeat_set, ecore_wl2_input_default_input_get.
Um.. i can't see the actual useage in tizen accept above two APIs.
That's why i added only 2 APIs first. i will add more APIs if there is someone asks.