sorry, quite late to the discussion here
On Fri, Apr 17, 2015 at 04:27:19PM +0200, Michal Suchanek wrote:
> On 17 April 2015 at 16:15, Carlos Garnacho wrote:
> > Hey Michal,
> >
> > On Fri, Apr 17, 2015 at 2:47 PM, Michal Suchanek wrote:
> >
> >
> >>> In the X11 world, this would roughly be a V
On Tue, Jun 09, 2015 at 07:26:15PM +0200, Carlos Garnacho wrote:
> Hey Jonas :),
>
> On jue, 2015-06-04 at 12:34 +0800, Jonas Ådahl wrote:
> > On Fri, Apr 17, 2015 at 02:16:41PM +0200, Carlos Garnacho wrote:
> > >
> > > Let's expand on that example, maybe far-streched, but certainly
> > > pos
Hey Jonas :),
On jue, 2015-06-04 at 12:34 +0800, Jonas Ådahl wrote:
> On Fri, Apr 17, 2015 at 02:16:41PM +0200, Carlos Garnacho wrote:
> > Hey Jonas,
> >
> > This is drifting a bit off the topic of the original thread, better
> > to
> > spin this off. I'll reply to the DnD bits in another email.
On Fri, Apr 17, 2015 at 02:16:41PM +0200, Carlos Garnacho wrote:
> Hey Jonas,
>
> This is drifting a bit off the topic of the original thread, better to
> spin this off. I'll reply to the DnD bits in another email.
Hey, sorry for the delay. Some comments/questions below.
>
> On Fri, Apr 17, 201
Hey Jonas,
Late reply, let's try to pick this up again...
On mar, 2015-04-21 at 14:29 +0800, Jonas Ådahl wrote:
> On Sat, Apr 18, 2015 at 04:53:46PM +0200, Carlos Garnacho wrote:
> > Hey Jonas,
>
> Hi,
>
> Thanks for the explanations. I'll reply inline.
>
> >
> > On vie, 2015-04-17 at 15:50 +
On Sat, Apr 18, 2015 at 04:53:46PM +0200, Carlos Garnacho wrote:
> Hey Jonas,
Hi,
Thanks for the explanations. I'll reply inline.
>
> On vie, 2015-04-17 at 15:50 +0800, Jonas Ådahl wrote:
>
>
> >
> > > For the touch case, depending on how the grab is implemented, with
> > > the
> > > curren
On 04/20/2015 04:05 AM, Carlos Garnacho wrote:
- The last touch drags the window, the previous ones remain static and
are eventually lifted. Why do they apply where your finger no longer
is? Why do they apply at all? can one of these touches create an
xdg_popup (and another grab on another touch
On 04/18/2015 07:53 AM, Carlos Garnacho wrote:
Let me try to correct this by removing some unnecessary data. In
particular no list of actions is sent by the destination. Also there is
no need for the compositor to echo the selected action back to the
destination. More importantly I have added
On vie, 2015-04-17 at 14:40 -0700, Bill Spitzak wrote:
> On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
>
> > Let's expand on that example, maybe far-streched, but certainly
> > possible:
> > - I'm manipulating a client window with 2 fingers on the
> > touchscreen
> > (say zooming an image)
> >
Hey Jonas,
On vie, 2015-04-17 at 15:50 +0800, Jonas Ådahl wrote:
>
> > For the touch case, depending on how the grab is implemented, with
> > the
> > current guidelines the only 2 choices are "leave the client in
> > inconsistent state" or "make the client still receives ongoing
> > touches
>
On 17 April 2015 at 23:40, Bill Spitzak wrote:
> On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
>
>> Let's expand on that example, maybe far-streched, but certainly possible:
>> - I'm manipulating a client window with 2 fingers on the touchscreen
>> (say zooming an image)
>> - Any other interactio
On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
Let's expand on that example, maybe far-streched, but certainly possible:
- I'm manipulating a client window with 2 fingers on the touchscreen
(say zooming an image)
- Any other interaction on the client makes it pop up an xdg_popup
(say a third tou
On 17 April 2015 at 14:16, Carlos Garnacho wrote:
> Hey Jonas,
>
> This is drifting a bit off the topic of the original thread, better to
> spin this off. I'll reply to the DnD bits in another email.
>
> On Fri, Apr 17, 2015 at 9:50 AM, Jonas Ådahl wrote:
>> On Thu, Apr 16, 2015 at 12:55:31PM +02
Hey Michal,
On Fri, Apr 17, 2015 at 4:27 PM, Michal Suchanek wrote:
>> Nothing prevents wayland compositors today from undoing grabs when
>> clients get destroyed, or surfaces don't respond to pings. Affecting
>> this proposal, the pointer should re-enter the surface underneath and
>> keyboard
On 17 April 2015 at 16:15, Carlos Garnacho wrote:
> Hey Michal,
>
> On Fri, Apr 17, 2015 at 2:47 PM, Michal Suchanek wrote:
>
>
>>> In the X11 world, this would roughly be a Virtual Core
>>> Pointer+Keyboard grab (not that touch and active grabs are trouble
>>> free in X11, but...), GTK+ for exa
Hey Michal,
On Fri, Apr 17, 2015 at 2:47 PM, Michal Suchanek wrote:
>> In the X11 world, this would roughly be a Virtual Core
>> Pointer+Keyboard grab (not that touch and active grabs are trouble
>> free in X11, but...), GTK+ for example does grab both devices on every
>> of those grabbing plac
On 17 April 2015 at 14:16, Carlos Garnacho wrote:
> Hey Jonas,
>
> This is drifting a bit off the topic of the original thread, better to
> spin this off. I'll reply to the DnD bits in another email.
>
> On Fri, Apr 17, 2015 at 9:50 AM, Jonas Ådahl wrote:
>> On Thu, Apr 16, 2015 at 12:55:31PM +02
Hey Jonas,
This is drifting a bit off the topic of the original thread, better to
spin this off. I'll reply to the DnD bits in another email.
On Fri, Apr 17, 2015 at 9:50 AM, Jonas Ådahl wrote:
> On Thu, Apr 16, 2015 at 12:55:31PM +0200, Carlos Garnacho wrote:
>> Hey Jonas,
>>
>> On Thu, Apr 16,
On Thu, Apr 16, 2015 at 12:55:31PM +0200, Carlos Garnacho wrote:
> Hey Jonas,
>
> On Thu, Apr 16, 2015 at 10:15 AM, Jonas Ådahl wrote:
>
>
>
> >
> > I'd have to agree on that it doesn't seem like the best thing to let the
> > compositor choose the preferred action. Having it apply compositor
>
On 04/16/2015 03:55 AM, Carlos Garnacho wrote:
In gtk+/gnome we currently have the following keybindings active during DnD:
- Cursor keys move the drag point, modifiers affect speed
- Esc key cancels drag
- Modifiers alone pick an action from the offered list
The user has to hold the mouse
Hey Jonas,
On Thu, Apr 16, 2015 at 10:15 AM, Jonas Ådahl wrote:
>
> I'd have to agree on that it doesn't seem like the best thing to let the
> compositor choose the preferred action. Having it apply compositor
> specific policy given what the keyboard state or similar will probably
> never wor
Hi,
Disclaimer: I don't know much how XDND works, but have some comments
anyway. See below:
On Sat, Apr 11, 2015 at 12:59:48PM +0200, Carlos Garnacho wrote:
> On vie, 2015-04-10 at 12:44 -0700, Bill Spitzak wrote:
> > On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
> >
> > > > However the
> > > >
On vie, 2015-04-10 at 12:44 -0700, Bill Spitzak wrote:
> On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
>
> > > However the
> > > compositor could send state along with A to the dest.
> >
> > This could also work,
>
> Thanks I think I finally made it clear what I am asking for.
In fairness, you
On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
However the
compositor could send state along with A to the dest.
This could also work,
Thanks I think I finally made it clear what I am asking for.
So "intersection" is now f(A,B,state), and what I propose is:
source sends A to compositor
Hey Bill,
On mié, 2015-04-08 at 14:18 -0700, Bill Spitzak wrote:
>
> >* Additionally to modifier state, there's other
> > keyboard/accessibility features as DnD is done in
> > GNOME/GTK+
> > (eg. DnD driven by cursor keys), these must be
> > implemented on
> >
On 04/08/2015 07:46 AM, Carlos Garnacho wrote:
I may be missing something. As far as I can tell your proposal is that
the source and destination send sets of actions to the compositor, the
compositor then intersects the sets, and sends the result of the
intersection to the source and destina
Hey Bill,
On mié, 2015-03-18 at 19:40 -0700, Bill Spitzak wrote:
> This is still bothering me as being much too complicated.
The bad news is, DnD is complex, there's plenty of prior usecases here
that won't be fair/possible to have "simplified".
>
> I think a list of actions can be sent from t
Hey Bryce,
Thanks for the review! I'm attaching new patches fixing the issues
you/Marek have seen, the doc blurbs have been reworded in a few places.
This v2 also adds a wl_data_offer.source_actions event. This allows
drag destinations to adapt their action mask accordingly, instead just
being
This is still bothering me as being much too complicated.
I think a list of actions can be sent from the DnD source to the target,
and the target selects one. There is no need for the compositor to do
any intersection of the sets and there is no need to communicate the set
of target actions to
On Mon, Feb 16, 2015 at 04:37:34PM +0100, Carlos Garnacho wrote:
> These 2 requests have been added:
>
> - wl_data_source.notify_actions request: Notifies the compositor of the
> available actions on the data source.
> - wl_data_offer.notify_actions request: Notifies the compositor of the
> av
Resending from the right address...
Hi Bill,
On Mon, Feb 16, 2015 at 10:17 PM, Bill Spitzak wrote:
> I would think the drop target client can figure out what action to perform,
> there is no need to communicate it's set of actions to the compositor or for
> the compositor to have any of this log
Hi Bill,
On Mon, Feb 16, 2015 at 10:17 PM, Bill Spitzak wrote:
> I would think the drop target client can figure out what action to perform,
> there is no need to communicate it's set of actions to the compositor or for
> the compositor to have any of this logic to "determine the action both part
I would think the drop target client can figure out what action to
perform, there is no need to communicate it's set of actions to the
compositor or for the compositor to have any of this logic to "determine
the action both parts agree on".
The drop target will have to say what action it did.
These 2 requests have been added:
- wl_data_source.notify_actions request: Notifies the compositor of the
available actions on the data source.
- wl_data_offer.notify_actions request: Notifies the compositor of the
available actions on the destination side, plus the preferred action.
Out of t
34 matches
Mail list logo
