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
26 matches
Mail list logo
