Hi Mike,
On Fri, Oct 16, 2015 at 5:58 PM, Mike Blumenkrantz wrote:
> On Fri, 16 Oct 2015 16:53:28 +0100
> Daniel Stone wrote:
>
>> Hi,
>>
>> On Wednesday, 30 September 2015, Carlos Garnacho
>> wrote:
>>
>> > Currently, there's no means for the DnD origin to know whether the
>> > destination is
On Mon, Nov 2, 2015 at 9:28 AM, Carlos Garnacho wrote:
> On Fri, Oct 30, 2015 at 7:10 PM, Bill Spitzak wrote:
> > I think what is wanted is an indication that the drag really did finish.
> For
>
> That's data_source.drag_finished in the patch you're commenting.
>
According to the documentation
On Fri, Oct 30, 2015 at 7:10 PM, Bill Spitzak wrote:
> I think what is wanted is an indication that the drag really did finish. For
That's data_source.drag_finished in the patch you're commenting.
> instance a file browser acting as the source of a "move" action will want a
> confirmation that t
On Fri, Oct 30, 2015 at 5:51 AM, Jonas Ådahl wrote:
> On Thu, Oct 29, 2015 at 05:51:04PM +0100, Carlos Garnacho wrote:
>> Hey Jonas!,
>>
>> On Thu, Oct 29, 2015 at 9:37 AM, Jonas Ådahl wrote:
>> > Hey Carlos,
>> >
>> > Finally had a look at this one.
>>
>> Cheers :)
>>
>> >
>> > On Wed, Sep 30, 2
On Thu, Oct 29, 2015 at 9:51 PM, Jonas Ådahl wrote:
>
> > > I too would like some clarifications why this is needed. The cursor and
> > > button state, I assume, could be reset on the next enter or by
> > > cancelled/finished, but that the client may want update its UI in some
> > > way.
>
> As
On Thu, Oct 29, 2015 at 05:51:04PM +0100, Carlos Garnacho wrote:
> Hey Jonas!,
>
> On Thu, Oct 29, 2015 at 9:37 AM, Jonas Ådahl wrote:
> > Hey Carlos,
> >
> > Finally had a look at this one.
>
> Cheers :)
>
> >
> > On Wed, Sep 30, 2015 at 10:45:39PM +0200, Carlos Garnacho wrote:
> >> Currently,
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 Thu, Oct 29, 2015 at 9:51 AM, Carlos Garnacho wrote:
> So this x11-style "grab" still happens before start_drag on the
> compositor, all it currently does face to the wayland compositor is
> updating the pointer cursor, but client-side it brings the usual
> grabby effects, input still taken "e
Hey Jonas!,
On Thu, Oct 29, 2015 at 9:37 AM, Jonas Ådahl wrote:
> Hey Carlos,
>
> Finally had a look at this one.
Cheers :)
>
> On Wed, Sep 30, 2015 at 10:45:39PM +0200, Carlos Garnacho wrote:
>> Currently, there's no means for the DnD origin to know whether the
>> destination is actually finis
Hey Carlos,
Finally had a look at this one.
On Wed, Sep 30, 2015 at 10:45:39PM +0200, Carlos Garnacho wrote:
> Currently, there's no means for the DnD origin to know whether the
> destination is actually finished with the DnD transaction, short of
> finalizing it after the first transfer finishes
On 10/17/2015 08:59 AM, Michael Catanzaro wrote:
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 complet
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, Oct 1, 2015 at 12:57 PM, Carlos Garnacho wrote:
> On Thu, Oct 1, 2015 at 8:48 PM, Bill Spitzak wrote:
> >
> >
> > On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho
> wrote:
> >>
> >>
> >> - wl_data_source.drop_performed: Happens when the operation has been
> >> physically finished (eg.
[and again, with the actual CC this time ...]
On Friday, 16 October 2015, Daniel Stone wrote:
> Hi,
>
> On Wednesday, 30 September 2015, Carlos Garnacho > wrote:
>
>> Currently, there's no means for the DnD origin to know whether the
>> destination is actually finished with the DnD transaction,
On Fri, 16 Oct 2015 16:53:28 +0100
Daniel Stone wrote:
> Hi,
>
> On Wednesday, 30 September 2015, Carlos Garnacho
> wrote:
>
> > Currently, there's no means for the DnD origin to know whether the
> > destination is actually finished with the DnD transaction, short of
> > finalizing it after th
[and again, with the actual CC this time ...]
On Friday, 16 October 2015, Daniel Stone wrote:
> Hi,
>
> On Wednesday, 30 September 2015, Carlos Garnacho > wrote:
>
>> Currently, there's no means for the DnD origin to know whether the
>> destination is actually finished with the DnD transaction,
Hi,
On Wednesday, 30 September 2015, Carlos Garnacho wrote:
> Currently, there's no means for the DnD origin to know whether the
> destination is actually finished with the DnD transaction, short of
> finalizing it after the first transfer finishes, or leaking it forever.
>
> But this poses othe
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
On Thu, Oct 1, 2015 at 8:48 PM, Bill Spitzak wrote:
>
>
> On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho wrote:
>>
>>
>> - wl_data_source.drop_performed: Happens when the operation has been
>> physically finished (eg. the button is released), it could be the right
>> place to reset the poin
Hey Michael,
On Thu, Oct 1, 2015 at 6:46 PM, Michael Catanzaro wrote:
> 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 proba
On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho wrote:
>
> - wl_data_source.drop_performed: Happens when the operation has been
> physically finished (eg. the button is released), it could be the right
> place to reset the pointer cursor back and undo any other state resulting
> from the i
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
Hey Michael :),
On Thu, Oct 1, 2015 at 12:43 AM, Michael Catanzaro
wrote:
> 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!
Thanks for the review!
>
> Nit #1: the existing
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
> it's new for Wes
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 documentation of t
Currently, there's no means for the DnD origin to know whether the
destination is actually finished with the DnD transaction, short of
finalizing it after the first transfer finishes, or leaking it forever.
But this poses other interoperation problems, drag destinations might
be requesting several
27 matches
Mail list logo
