On Sun, 26 Jan 2020 13:36:04 +0100 Marcel Hollerbach <[email protected]> said:
just a very very very initial set of feedback.
1. warning fix:
diff --git a/src/lib/eina/eina_abstract_content.c
b/src/lib/eina/eina_abstract_content.c index fa89ee60bd..652cab4b14 100644
--- a/src/lib/eina/eina_abstract_content.c
+++ b/src/lib/eina/eina_abstract_content.c
@@ -184,7 +184,7 @@ eina_content_type_get(Eina_Content *content)
return content->type;
}
-EAPI const Eina_Slice
+EAPI Eina_Slice
eina_content_data_get(Eina_Content *content)
{
return eina_rw_slice_slice_get(content->data);
diff --git a/src/lib/eina/eina_abstract_content.h
b/src/lib/eina/eina_abstract_content.h index b9e4723973..4eff00fbbd 100644
--- a/src/lib/eina/eina_abstract_content.h
+++ b/src/lib/eina/eina_abstract_content.h
@@ -63,7 +63,7 @@ EAPI const char* eina_content_type_get(Eina_Content *content);
*
* @return The path to the file. Do not free this.
*/
-EAPI const Eina_Slice eina_content_data_get(Eina_Content *content);
+EAPI Eina_Slice eina_content_data_get(Eina_Content *content);
/**
* Create a new content object, with the slice of data with a specific type.
2. how much is meant to work?:
How much is meant to work so far? I found copy & pasting from efl now to
something else leads to some garbage at the end of the string. 1 char it looks
like. i see the junk when pasting into terminology (which is using the current
git master implementation) and gtk2 (my mail client - sylpheed). Trying to copy
& paste from anything into the new cnp implementation results in a pair of
ERR's:
ERR<40939>:elementary ../src/lib/elementary/elm_cnp.c:36
_elm_sel_format_to_mime_type() Specified mime type is not available
ERR<40939>:elementary ../src/lib/elementary/elm_cnp.c:180
_callback_storage_error() Content cound not be received because of (null).
and .. nothing is pasted. is this expected at this stage or "that should work"?
that's as far as i've gotten so far in exploring what works so far or not...
> Hi,
>
> as i have said on EDD, i wanted to work on cnp & dnd. My current state
> of work can be found in
> https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/work_cnp.
>
> The overall idea of this whole thing is to get the API into different
> levels:
> - Eina now has a struct (Eina_Content) that handles a data blob and a
> type. This data blob can be converted to different types. This also
> allows API users to add more types, and possible convertions
>
> - Ecore_Evas now has a module API for handling cnp and dnd operations,
> for more details, the documentation should help, i dont think it makes
> much sense to write here every single detail. Just one thing that was
> the mantra during the design of this: Every data blog is always Passed
> as Eina_Content, so the type can never be split from the data, by
> design. This way we should get rid of all the *ups, this was not \0
> terminated* errors we had in the past. Sanity checks and smaller fixes
> on content can also be implemented in the eina side.
>
> - Ecore_X is the first (and for now only) protocol that has support in
> this new thing. No multiseat support is added to this, or was meant to
> be ever used. The difference here to the legacy code is not big in terms
> of how we do the protocol. However, a lot of things have now been tested
> for the first time, and a few bugs have been found. That means, we now
> *really* get notified if someone else in the display server takes over
> selection, which sadly broke a lot of the new Textbox tests, which have
> been all fixed. I have tested this with chromium firefox, thunderbird
> and cross efl. However, i did not test yet enlightenment or anything
> around that. I would be really happy if a few people could give it a test!
>
> - Last but not least: The elm API. The legacy API was implemented with
> as much original code from 1.18 as possible, the reason i went back to
> this state, was that there was a "kind of" abstraction between drop
> containers drag containers and protocol operations, that was somehow
> lost during the move to selection_manager. Now, this old code is back,
> and just calls the new efl.ui.drag / selection API in the places where
> it is needed. The Efl.Ui.Drag and Efl.Ui.Selection API has been
> reworked. Listening to events implicitly turns on the listening to the
> ecore evas events, this means, you do not need to explicitly register
> things as "drop targets" anymore. Additionally, the API is now
> structured that there is a difference between drop, drag & selection.
> A DROP is a DND operation that has entered your window.
> A DRAG is a DND operation that was started by your window. This way we
> can ensure that it is clear when a drag or when a drop is finished.
> Before there was a major confusion in the API when it comes to this.
> The selection is now also defined in a way that you only have selection
> and the clipboard, some platforms may support the two. Others only
> support the clipboard (like wayland). However, X11 specific things like
> the secondary buffer have been dropped. Additionally, for supporting a
> wider range of usecases, the action enum have been replaced with a
> simple string.
>
> I am not sure when i can come up with protocol implementations for
> wayland and or macos, i would be really happy if some people could help
> me with that. Additionally, i really need more help with testing, as I
> cannot imagine all the usecases we have right now out there. If you find
> any buggy behavior, feel free to write me here, of create a phab ticket,
> thank you :)
>
> Greetings,
> bu5hm4n
>
>
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
