On Tue, Oct 20, 2015 at 10:22:45AM +0800, Jonas Ådahl wrote:
> Hi again,
>
> I was about to start migrating generic protocols away from weston into
> wayland-protocols. The idea was to start with input-method.xml, text.xml,
> linux-dmabuf.xml, presentation_timing.xml, scaler.xml and xdg-shell.xml.
On Fri, 2015-10-30 at 22:06 +0100, Carlos Garnacho wrote:
> --- a/clients/dnd.c
> +++ b/clients/dnd.c
> @@ -72,6 +72,7 @@ struct dnd_drag {
> struct item *item;
> int x_offset, y_offset;
> int width, height;
> + uint32_t dnd_action;
> const char *mime_type;
>
> s
On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote:
> The frame event groups separate pointer events together. The primary use-case
> for this at the moment is diagonal scrolling - a vertical/horizontal scroll
> event can be grouped together to calculate the correct motion vector.
If I
On Fri, 2015-10-30 at 21:57 +0100, Carlos Garnacho wrote:
> + This request mandates the final result of the drag-and-drop
> + operation. If the end result is that no action is accepted,
> + the drag source will receive drag_source.cancelled.
Same nit here about "mandates."
Revie
On Fri, 2015-10-30 at 21:55 +0100, Carlos Garnacho wrote:
> Changes since v1:
> - Renamed events to have a common "dnd" namespace.
I don't think this was a great change. The event occurs on drop, and
the previous name described that perfectly, whereas with the new name
it's not very clear how it
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 Fri, Oct 30, 2015 at 1:57 PM, Carlos Garnacho wrote:
>
> +
> +
> +This is a bitmask of the available/preferred actions in a
> +drag-and-drop operation.
> +
> +The current reserved ranges are:
> +
> +0x - 0x00FF: Reserved for the wayland core protoc
On Thu, Oct 29, 2015 at 11:48:01AM +1000, Peter Hutterer wrote:
> This switches the scanner to generate doxygen-compatible tags for the
> generated protocol headers, and hooks up the doxygen build to generate server
> and client-side API documentation.
>
> For the wayland protocol, this generates
On Fri, Oct 30, 2015 at 09:49:20AM +0200, Giulio Camuffo wrote:
> 2015-10-30 2:27 GMT+02:00 Bryce Harrington :
> > On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
> >> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
> >> > Add the possibility for the compositor ba
On Wed, Oct 28, 2015 at 6:34 AM, Peter Hutterer
wrote:
> The frame event groups separate pointer events together. The primary use-case
> for this at the moment is diagonal scrolling - a vertical/horizontal scroll
> event can be grouped together to calculate the correct motion vector.
> Frame event
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 the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
n
Weston now sends wl_data_source.drop_performed and .drag_finished in
order to notify about the different phases of DnD.
wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).
T
These 2 requests have been added:
- wl_data_source.set_actions: Notifies the compositor of the available
actions on the data source.
- wl_data_offer.set_actions: Notifies the compositor of the available
actions on the destination side, plus the preferred action.
Out of the data from these req
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
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
Hi,
On 30-10-15 02:19, Peter Hutterer wrote:
And use the unaccelerated motion events. Better than crashing, and better than
a non-moving mouse.
Signed-off-by: Peter Hutterer
The entire set looks good to me and is:
Reviewed-by: Hans de Goede
Regards,
Hans
---
src/evdev.c | 17 +++
On Fri, Oct 30, 2015 at 08:33:16AM +, Daniel Stone wrote:
> Hi,
>
> On 30 October 2015 at 04:27, Jonas Ådahl wrote:
> > On Fri, Oct 30, 2015 at 08:41:18AM +1000, Peter Hutterer wrote:
> >> On Thu, Oct 29, 2015 at 09:33:14AM +, Daniel Stone wrote:
> >> > Right, so I think we agree here. I'
Hi,
On 30 October 2015 at 04:27, Jonas Ådahl wrote:
> On Fri, Oct 30, 2015 at 08:41:18AM +1000, Peter Hutterer wrote:
>> On Thu, Oct 29, 2015 at 09:33:14AM +, Daniel Stone wrote:
>> > Right, so I think we agree here. I'd prefer to keep the types matching
>> > as well; I do struggle to see how
Hi,
On 30 October 2015 at 00:27, Bryce Harrington wrote:
> On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
>> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
>> > Add the possibility for the compositor backend to provide with the list
>> > of supported pixel for
2015-10-30 2:27 GMT+02:00 Bryce Harrington :
> On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
>> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
>> > Add the possibility for the compositor backend to provide with the list
>> > of supported pixel formats for dmabu
21 matches
Mail list logo
