On Tue, 2015-12-15 at 18:56 +0100, Carlos Garnacho wrote:
> These patches make it a lot more similar to what GTK+ wants (and I
> assume
> other toolkits), it is my hope that it helps see how badly we need
> to
> shape drag-and-drop up to have something usable.
Regarding other toolkits/client
On Fri, 2015-12-18 at 12:03 -0500, Lyude wrote:
> + version="1">
> +
> + Provides the ability to have a primary selection buffer to
> match that of
> + the X server. This allows users to select bodies of text, and
> then paste
> + them in another buffer without having to do the
E_MANAGER_DND_ACTION_MOVE,
> +
> WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY);
> +
> } else {
> input->drag_offer = NULL;
> types_data = NULL;
Is it normal to add
"mandates."
Reviewed-by: Michael Catanzaro
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
ot a great choice of word here... how about
"determines" instead?
Reviewed-by: Michael Catanzaro
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
This fixes the issues I pointed out before.
Reviewed-by: Michael Catanzaro
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, 2015-10-29 at 16:37 +0800, Jonas Ådahl wrote:
> Correct me if I'm wrong, but this event is meant to be sent after a
> destination has read all the data it needs, meaning we could
> effectively
> send this for regular clipboard sources as well? Then just call it
> "finished".
I don't think
On Fri, 2015-10-16 at 18:43 -0700, Bill Spitzak wrote:
> I think you misunderstood. The *destination* (if the cursor is still
> pointing at it) is what sets the cursor.
To clarify: you mean the destination sets the cursor as soon as the
drop completes, correct? (Currently the source controls the c
On Thu, 2015-10-01 at 21:57 +0200, Carlos Garnacho wrote:
> Remember, toolkits preserve some state. The drag source is in control
> of the pointer cursor as long as the DnD operation holds, so it
> should
> reset its internal current cursor to the regular one for the next
> time
> the pointer enter
On Thu, 2015-10-01 at 21:36 +0200, Carlos Garnacho wrote:
> But this is a very valid concern, if you preemptively accept() with a
> random mimetype, the user quickly finishes the drag before transfers
> are done, and it isn't accepted in the end, you'd get the wrong
> feedback, and the wrong outcom
One problem with this model is that a broken or malicious client could
force the drag source to be leaked by [sending accept and] never
destroying its data offer... but only once per user-initiated drag, so
we can probably ignore that issue
On Thu, 2015-10-01 at 12:00 +0200, Carlos Garnacho wr
On Wed, 2015-09-30 at 17:43 -0500, Michael Catanzaro wrote:
> Minor issue: this and the next patch introduce the requirement that
> accept is called on the data offer before the mouse grab is released.
> I
> now see this has always been required by mutter -- not sure why --
> but
Reviewed-by: Michael Catanzaro
Nit regarding data_offer.action and data_source.action: "This event can
be emitted multiple times during the drag-and-drop operation, mainly in
response to source side changes (through data_source.set_actions),
destination side changes (th
Reviewed-by: Michael Catanzaro
On Wed, 2015-09-30 at 22:50 +0200, Carlos Garnacho wrote:
> The policy in weston in order to determine the chosen DnD action is
> deliberately simple, and is probably the minimals that any compositor
> should be doing here.
>
> Besides honoring
Reviewed-by: Michael Catanzaro
Looks mostly good to me. The only problem I see is that you've left
stale conditionals in both data_offer_accept and data_offer_receive,
which can't be hit anymore since you added the bails up above. Be sure
that fd gets freed in data_offer_receive whe
Reviewed-by: Michael Catanzaro
These are important fixes for the protocol that will allow drags to
work between GTK+ and Chrome. Thanks for working on this, Carlos!
Nit #1: the existing documentation doesn't use the DnD abbreviation, so
I would write out "drag-and-drop" in the d
16 matches
Mail list logo
