In D12144#232351, @bu5hm4n wrote:

Making the unregister in line 231 conditionally for not widgets should fix that.

In D12144#232166, @bu5hm4n wrote:

1. This breaks legacy drop targets on none efl.ui.dnd elements.
2. This breaks registering 2 events, unregistering 1 -> no event will be delivered anymore.

update source codes

upload codes

update patches

update source

update codes

This patch will be replaced with D11979

clean up the codes

In D11979#228719, @jsuya wrote:

In my opinion, if Efl.Ui.Image needs to do the same, I think I can handle this on line 939. Is it only necessary to support legacy?

update condition

update condition

modify condition

consider group

update source codes

update codes

update source code

update source code

clean up

update codes

update version

update comments

update codes based on comments

change the API name

remove interface and support legacy API

remove libweb dependency for libwebpdemux

update codes

Add checking return value for getting next frame

update codes

update codes

modified code for comments

This is tested by my environments and removed the duplicated register cases.

clean up the codes

update codes

update files

update sample codes

update codes

for DnD-4(1): I think the event enter and left in _motion_cb, the event enter and left in _enter_state_change_cb are different. the events in motion_cb are triggered by motion.
but the events in _enter_state_change_cb are triggered by wayland enter and left events.
I have a doubt to serve same events about both cases.
for DnD-4(2): when the drag object moved to the target object and the drag is finished, the target->currently_inside flag should be false. but _enter_state_changed_cb dose not change the target->currently_inside flag to false when drag is done.

hello, @bu5hm4n
for CnP-2 (new case)
I have a question about elm_cnp_loss_callback_set() function.
I think the loss_callback behavior is changed compared to before.

hello, @bu5hm4n
for CnP-1
The serial is updated by only input codes, so when we try to copy and paste using button(the serial is updated and copy and paste work well)
ex)
src/lib/ecore_wl2/ecore_wl2_input.c:697: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:721: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:768: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:942: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:969: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:1062: input->display->serial = serial;
src/lib/ecore_wl2/ecore_wl2_input.c:1241: input->display->serial = serial;

hello, @bu5hm4n
for Dnd-4
before EFL_UI_DND_EVENT_DROP_ENTERED and EFL_UI_DND_EVENT_DROP_LEFT event are triggered by only motion events.
but the events in _enter_state_change_cb() will emit additional event to the application.

hello, @bu5hm4n
for DnD-1: drop event register twice is not reproduced with the patch in my environment.

I have question about _enter_state_change_cb(), I think in _motion_cb() we emit EFL_UI_DND_EVENT_DROP_LEFT, EFL_UI_DND_EVENT_DROP_ENTER already.
should we emit the event in _enter_state_change_cb()?
(before the drag enter and leave event are triggered by the drag object moves)

I think this seems to be bug, there is a case that drop_target is added twice.
how about remove _drop_event_register() in elm_drop_target_add()?

Case: DnD-1
I think the drop left and drop entered event order are important.

@ bu5hm4n
I created the patch for resolving DnD-2 problem.
please review this :)
https://phab.enlightenment.org/D11846

update codes

update codes

update code

fix warning

update comments

This revision is divided into D11517, D11518, D11519

In D11513#219509, @segfaultxavi wrote:

This patch looks very similar to D11511. Can you take into account the comments I made there?

Updating D11514: evas_vg: refined the documentation for evas vector APIs

evas_vg: refined the evas vector APIs set

update source

@segfaultxvai
hello, thanks for the comment, I will divide this patch for readability(D11513 is the first path of this)
Evas_Vg_Join enum values refers to src/lib/efl/interfaces/efl_gfx_types.eot:71(Efl.Gfx.Join)
and in case of other comments, I will change to follow your comments.

In D11511#219479, @segfaultxavi wrote:

Looks like you are defining new enums here that are already present in Eo files. Can you explain why?

=> because I think legacy APIs should use legacy enum values, so I defined evas enum types
ex) for hiding gfx enums
evas_vg_shape_path_set(Evas_Vg_Shape *obj, const Evas_Vg_Path_Command *op, const double *points)
evas_vg_shape_stroke_dash_get(Evas_Vg_Shape *obj, const Evas_Vg_Dash **dash, unsigned int *length)
evas_vg_gradient_stop_set(Evas_Vg_Gradient *obj, const Evas_Vg_Gradient_Stop *colors, unsigned int length)
evas_vg_shape_stroke_dash_set(Eo *obj, const Evas_Vg_Dash *dash, unsigned int length)

I think @zmike worked on the move of this stuff from Legacy to Eo some time ago, it might be worth asking his opinion.

update cdes

abandon this revision

evas_vg: refined the documentation for evas vector APIs

update tags

updated version for new evas enums

I will update as other patch