Hey all,
On Sun, Jun 30, 2024 at 7:58 PM Carlos Garnacho wrote:
>
> Hi all,
>
> On Tue, Jun 25, 2024 at 11:56 PM Carlos Garnacho wrote:
> >
> > Hi all,
> >
> > It was agreed in the last meeting around the text-input protocol to do
> > some follow up
Hi all,
On Tue, Jun 25, 2024 at 11:56 PM Carlos Garnacho wrote:
>
> Hi all,
>
> It was agreed in the last meeting around the text-input protocol to do
> some follow ups to discuss remaining issues and possible further
> improvements. I would like to call a second meeting
up comment on it.
>
>
> Otherwise, I'll appreciate some notes.
We will surely take minutes and make them public after the meeting :).
Cheers,
Carlos
an appropriate date/time.
The meeting could be held at https://meet.gnome.org/car-oot-bcf-kt4 .
I will announce the poll results by Jun 30th.
Cheers,
Carlos
Hi!,
On Sun, May 12, 2024 at 2:18 AM Carlos Garnacho wrote:
>
> On Tue, May 7, 2024 at 1:40 PM Carlos Garnacho wrote:
> >
> > Hi!,
> >
> > On Wed, Apr 17, 2024 at 2:37 PM Vlad Zahorodnii
> > wrote:
> > >
> > > Hello,
> > >
> &
On Tue, May 7, 2024 at 1:40 PM Carlos Garnacho wrote:
>
> Hi!,
>
> On Wed, Apr 17, 2024 at 2:37 PM Vlad Zahorodnii
> wrote:
> >
> > Hello,
> >
> > The Wayland Governance Meeting is semi-regular meeting to drive
> > discussion on wayland-prot
ts/282
as there are changes there benefiting IM integration.
The meeting could be held at https://meet.gnome.org/car-oot-bcf-kt4,
and the date/time can be decided at
https://nuudel.digitalcourage.de/mdlGZkeersnxI8fS
I will announce the poll results on May 12th.
Cheers,
Carlos
Hi,
On Thu, Oct 19, 2023 at 11:58 PM Carlos Garnacho wrote:
>
> Hi,
>
> I would like to propose a meeting about the color management protocol
> [1] after next week (it's late to schedule for next, plus there's
> people still likely at XDC). After talking with GIMP
Hi,
On Thu, Oct 19, 2023 at 11:58 PM Carlos Garnacho wrote:
>
> Hi,
>
> I would like to propose a meeting about the color management protocol
> [1] after next week (it's late to schedule for next, plus there's
> people still likely at XDC). After talking with GIMP
Hi Pekka,
(this time on list)
On Fri, Oct 20, 2023 at 12:44 PM Pekka Paalanen wrote:
>
> On Thu, 19 Oct 2023 23:58:18 +0200
> Carlos Garnacho wrote:
>
> > Hi,
> >
> > I would like to propose a meeting about the color management protocol
> > [1] after next
und on the wayland-protocols wiki page [4].
Cheers,
Carlos
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
[2] https://nuudel.digitalcourage.de/QYCvHEj5KR4HADfD
[3] https://meet.gnome.org/car-oot-bcf-kt4
[4] https://gitlab.freedesktop.org/wayland/wayland-protoco
client for the IM here. Non-keyboard-driven text input might welcome
these additional high-level actions, but it also would benefit of
toolkit buy-in besides compositors/IMs, it is not something clients
were used to being told to do.
Cheers,
Carlos
could
then pass the toplevel surface as the drag source. This way lifetime
correctness is guaranteed, and "snap back" animations on failed DnD
have a surface to return to.
Cheers,
Carlos
omewhat amiss
though.
Amusingly, running on plain Mutter (e.g. `mutter --wayland
--display-server` on a TTY) does also seem to fix the issue. The most
immediate difference I can think of is the involvement of input
methods.
Since this does not seem to be a generic Wayland issue, feel free to
file a bug at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues and
move discussion there, this might still end up in Mutter, or in IBus,
unclear yet.
Cheers,
Carlos
On 5/25/22 17:35, Thiago Macieira wrote:
On Wednesday, 25 May 2022 13:18:11 PDT Carlos wrote:
Model name: Cortex-A72
This is a 64-bit capable CPU, according to Wikipedia:
https://en.wikipedia.org/wiki/ARM_Cortex-A72
Why are you running 32-bit?
you're correct. Ca
On 5/23/22 19:54, Thiago Macieira wrote:
On Monday, 23 May 2022 13:42:45 PDT Carlos wrote:
:) I know. 32-bit. But I have no option
processor : 3
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS: 144.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
On 5/23/22 16:01, Thiago Macieira wrote:
On Monday, 23 May 2022 11:07:35 PDT Carlos wrote:
QImage::scaled: Image is a null image
This first line probably indicates an out-of-memory condition: some operation
prior to this failed to allocate memory for its image, so scaled() simply
complained
On 5/23/22 16:01, Thiago Macieira wrote:
On Monday, 23 May 2022 11:07:35 PDT Carlos wrote:
QImage::scaled: Image is a null image
This first line probably indicates an out-of-memory condition: some operation
prior to this failed to allocate memory for its image, so scaled() simply
complained
Hello list:
I'm not a wayland power user. I need it though, to run a handful of
instances that require it.
The most relevant section (I think), is below.
It happens as soon as an x number of programs (or sessions of the same
program) are minimized to the panel. It doesn't matter whether the
or these specific accessibility features, this is something that each
compositor has to deal with by themselves. Wayland is largely an IPC
protocol, and does not specify how images get to your screen. Weston
is a reference implementation of a wayland compositor,
nd make others miss them (i.e. in a grabbing manner)
2. To make clients work seamlessly with Orca
To fix 1, I tend to think this is something best left to an
integration library (as IIUC the goal is also to maximize
reutilization). The API sounds like it could be reasonably agnostic
Hi Pekka,
Thank you for your comments!
On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen wrote:
> On Wed, 16 Oct 2019 10:54:08 +0200
> Olivier Fourdan wrote:
>
> > Hey Carlos,
> >
> > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho
> wrote:
> > >
>
Hi Dorota!
On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz <
dorota.czaplejew...@puri.sm> wrote:
> On Wed, 16 Oct 2019 10:43:00 +0200
> Carlos Garnacho wrote:
>
> > This protocol takes over 3 different, but interrelated aspects of
> > DE/client interaction:
me up with are "activation" or "launch",
"presentation" sounded more neutral though.
Cheers,
Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
immediately switching focus to a surface makes sense.
- Window raising/activation: allowing existing clients to request
focus in a controlled manner.
Signed-off-by: Carlos Garnacho
---
Makefile.am | 1 +
unstable/presentation/README | 5
per event, we now send 10/120 * v120 value. So we
> need the compositors to handle a new API, but at least the wayland client
> side doesn't change.
>
> Any comments? Anything I've overlooked?
Semantics aside, I think the reasoning sounds good.
Cheers,
Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ata_offer, if any, upon receiving this event.
> +
> + interface="zwp_primary_selection_offer_v1" allow-null="true"/>
> +
> +
> +
> +
> +Destroy the primary selection device.
> +
> +
> +
> +
> +
> +
> + A wp_primary_selection_offer represents an offer to transfer the
> contents
> + of the primary selection clipboard to the client. Similar to
> + wl_data_offer, the offer also describes the mime types that the
> source
> + will transferthat the
>
This is in the original protocol, so definitely more my fault than yours,
but would be nice not to drag this further :). I guess the original
intention was:
"...describes the mime types that the data can be converted to..."
Besides that, the patch is
Reviewed-by: Carlos Garnacho
Cheers,
Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, Aug 16, 2018 at 4:46 PM, Jonas Ådahl wrote:
> On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote:
>> Hi!,
>>
>> Thanks Simon for moving this forward. FTR this looks good to me. Had
>> some chat with Jonas on IRC about the suitability of xdg vs wp
&g
Hi!,
Thanks Simon for moving this forward. FTR this looks good to me. Had
some chat with Jonas on IRC about the suitability of xdg vs wp
prefixes, but I personally think your choice is fine. Either way, this
is
Acked-by: Carlos Garnacho
On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser wrote:
> T
Hey,
With the serial number behavior cleared out, this all reads great to
me. Can't be part and judge though :), so no R-b label.
Cheers,
Carlos
On Mon, Jul 30, 2018 at 4:14 PM, Dorota Czaplejewicz
wrote:
> From: Carlos Garnacho
>
> This new protocol description is an e
tors can use wl_keyboard
>> > interface instead.
>> > - All state is double-buffered, with specified state.
>> > - Use Unicode codepoints to measure strings.
>> >
>> > Signed-off-by: Dorota Czaplejewicz
>> > Signed-off-by: Carlos Garnacho
:20:53 PDT Dorota Czaplejewicz wrote:
>> > > On Sun, 11 Mar 2018 20:30:14 +0100
>> > >
>> > > Carlos Garnacho wrote:
>> > > > This new protocol description is a vast simplification over v2,
>> > > > highlights
>> > > > a
st for clients.
> - There is no event to send keysyms. Compositors can use wl_keyboard
> interface instead.
>
> Reviewed-by: Drew DeVault
> ---
>
> Hi,
>
> This patch follows the original proposal by Carlos Garnacho. It's the
> result of my work on behalf
both directions.
- There is no event to send keysyms. The handling ought to be by all means
identical to wl_keyboard's, compositors might just use that interface.
Signed-off-by: Carlos Garnacho
---
Hey,
Belatedly, here's my proposed v3 of the text-input protocol, a rename of
what is i
New IDs are internally dealt with as objects, however this test
expected to deal with 'n' as the uint32_t type that's just seen
through the wire. We should give it an object instead, and
expect an object from it.
https://bugs.freedesktop.org/show_bug.cgi?id=99899
Signed-off-by:
touch interface can cope with such input
redirection situations on individual touchpoints.
Signed-off-by: Carlos Garnacho
Reviewed-by: Peter Hutterer
---
Changes since v3: Applied wording improvements from Yong Bakos, added
the clarification suggested by Daniel, and made wl_touch.leave part of
Just print the output, as with the other events.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
Reviewed-by: Bryce Harrington
---
clients/eventdemo.c | 108 +++-
1 file changed, 107 insertions(+), 1 deletion(-)
diff --git a/clients
It will allow zooming in/out the loaded image.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
---
clients/image.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/clients/image.c b/clients/image.c
index db9ccd6..5057d0a 100644
--- a/clients
.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
Reviewed-by: Bryce Harrington
---
Makefile.am | 6 +-
clients/window.c | 230 ++-
clients/window.h | 54 +
3 files changed, 288 insertions(+), 2 deletions(-)
diff
pdate to use standalone XML.
Signed-off-by: Carlos Garnacho
---
Makefile.am | 4 +-
libweston/compositor.c | 2 +
libweston/compositor.h | 12 +++
libweston/input.c | 216 +++-
libweston/libinput-device
vice added.
> * add a libinput_device_switch_get_state() function for callers to query the
> state if they need it and only send the actual changes after we have a
> context initialised. That has a small potential for race conditions, so
> I'm tending to the first option
>
>
touch interface can cope with such input
redirection situations on individual touchpoints.
Signed-off-by: Carlos Garnacho
---
v2: Reuse leave events for this purpose. This meant one had to be added
on wl_touch.
v3: Improved wording (I hope!) largely inspired on the suggestions from
Daniel
Hey Daniel :),
On Tue, Nov 22, 2016 at 12:43 PM, Daniel Stone wrote:
> Hi Carlos,
>
> On 12 November 2015 at 12:31, Carlos Garnacho wrote:
>> The leave events in the respective device interfaces has been further
>> documented so those can convey the necessary inf
do momentum with wheel/axis scrolling
> (out of the box). maybe it needs enabling?
FWIW, that should happen out of the box whenever we got
wl_pointer.axis_stop on both axes:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n3399
The usual caveats apply, that doesn't help if the a
to a single element.
Signed-off-by: Carlos Garnacho
Signed-off-by: Peter Hutterer
Reviewed-by: Jason Gerecke
---
unstable/tablet/tablet-unstable-v2.xml | 540 +
1 file changed, 540 insertions(+)
diff --git a/unstable/tablet/tablet-unstable-v2.xml
b/unstable/tablet/t
From: Peter Hutterer
This is a straightforward copy/paste with a _v1 -> _v2 rename. No functional
changes otherwise.
Signed-off-by: Peter Hutterer
Reviewed-by: Jason Gerecke
Reviewed-by: Carlos Garnacho
---
Makefile.am| 1 +
unstable/tablet/tablet-unstable
ssary, a client may still opt to share
the underlying wl_buffer.
Signed-off-by: Peter Hutterer
Reviewed-by: Jason Gerecke
Reviewed-by: Carlos Garnacho
---
unstable/tablet/tablet-unstable-v2.xml | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/unstable/tablet/tablet-
From: Peter Hutterer
Signed-off-by: Peter Hutterer
Reviewed-by: Jason Gerecke
Reviewed-by: Carlos Garnacho
---
unstable/tablet/tablet-unstable-v2.xml | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/unstable/tablet/tablet-unstable-v2.xml
b/unstable
Hi!,
On Thu, Jul 7, 2016 at 11:30 PM, Jason Gerecke wrote:
> On 06/30/2016 05:16 AM, Jonas Ådahl wrote:
>> On Thu, Jun 30, 2016 at 01:10:33PM +0200, Carlos Garnacho wrote:
>>> Hi!,
>>>
>>> On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl wrote:
>>>>
Hi!,
On Fri, Jul 8, 2016 at 3:46 AM, Peter Hutterer wrote:
> Unimplemented and it wasn't supposed to be in the series.
Looks good to me, makes sense to add this later.
Reviewed-by: Carlos Garnacho
Cheers,
Carlos
___
wayland-devel mail
his is just useful for
labeling purposes (eg. setting "Switch to mode 1/2/3" labels instead
of a generic "Switch mode" on all three), so having this in libinput
is dubious in the first place. To be resolved through a different call
than libinput_tablet_pad_mode_group_button_is_t
; The branch is available on
> https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v2
After going through
https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v3, the
whole series looks good to me and is,
Reviewed-by: Carlos Garnacho
I take it 7/10 and 9/10 from the former v2 seri
Hi!,
On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> The pad ha
Hi!,
On Thu, Jun 30, 2016 at 5:27 AM, Peter Hutterer
wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> T
to a single element.
Signed-off-by: Carlos Garnacho
Signed-off-by: Peter Hutterer
Reviewed-by: Jason Gerecke
---
Changes since v3:
- Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
groups may have separate modes which are announced through a mode_switch
event.
-
tion.
>
> For the stylus-like devices leave the current accel, pointer acceleration on a
> stylus is hard to handle.
>
> This also adds the missing bits for actually using the speed factor set
> through the config interface.
>
> Signed-off-by: Peter Hutterer
Looks go
> +
> +
Hmm, we've got a request and an event for this. Presumably the
compositor sends this after .enter and after every .language request
from the client? Are there situations where the compositor might want
to have the last say? should the client shut up and follow? the
bidirectionality here makes it a bit unclear on who takes precedence
:).
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + Sets the text direction of input text.
> +
> + It is mainly needed for showing input cursor on correct side of the
> + editor when there is no input yet done and making sure neutral
> + direction text is laid out properly.
> +
> +
> +
The description doesn't sound very convincing :)... Can't this be eg.
inferred from the .language event or the locale?
> +
> +
> +
> + Configure what amount of surrounding text is expected by the
> + input method. The surrounding text will be sent in the
> + set_surrounding_text request on the following state information
> updates.
> +
> +
> +
> +
Hmm, maybe "configure" is not the best term? this is a "reply me back
with data" event, so perhaps "request" is better?
> +
> +
> +
> + The input method changed on compositor side, which invalidates all
> + current state information. New state information should be sent from
> + the client via state requests (set_surrounding_text,
> + set_content_hint, ...) and update_state.
IMO the expected requests perfom should be clearly stated here, i.e.
no ellipsis.
> +
> +
> +
Won't argue hard against this, but after all this is an unstable
protocol, this argument can be always added in future versions if it
turns out needed :).
Cheers,
Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hey :),
On Tue, May 17, 2016 at 2:50 AM, Peter Hutterer
wrote:
> On Tue, May 17, 2016 at 01:30:03AM +0200, Carlos Garnacho wrote:
>> Hey :),
>>
>> On Wed, May 11, 2016 at 4:51 AM, Peter Hutterer
>> wrote:
>> > From: Carlos Garnacho
>> >
>> >
Hey :),
On Wed, May 11, 2016 at 4:51 AM, Peter Hutterer
wrote:
> From: Carlos Garnacho
>
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
>
> The pad has three functionalities: buttons, rings and strip
Signed-off-by: Carlos Olmedo Escobar
---
src/libinput.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index bcd0dcd..e5a1ae4 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -2578,6 +2578,7 @@ libinput_post_event(struct libinput
Hi!,
On Fri, Apr 22, 2016 at 4:02 AM, Peter Hutterer
wrote:
> On Thu, Apr 21, 2016 at 05:46:24PM -0700, Jason Gerecke wrote:
>> On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer
>> wrote:
>> > From: Carlos Garnacho
>> >
>> > The pad's interfac
ing whether source->set_actions before
> proceeding with updating the current action, just always update the
> action when we know all parts are valid dnd data device objects.
Totally makes sense.
Reviewed-by: Carlos Garnacho
Cheers,
Carlos
___
vent_tablet_pad_get_button() to the more explicitly named
> libinput_event_tablet_pad_get_button_number(). Just to drive the point home.
The whole series look great to me, just the small glitch I pointed out
in 1/5. Other than that, the whole series is:
Revi
ibinput, "Tablet unknown to libwacom\n");
> + } else {
> + log_error(libinput,
> + "libwacom error: %s\n",
> + libwacom_error_get_message(error));
> + }
> +
> + if (error)
> +
Hey!,
On Mon, Apr 11, 2016 at 1:32 AM, Peter Hutterer
wrote:
> Supposed to be [-1, 1] but we only generated [0, 1]
>
> Reported-by: Carlos Garnacho
> Signed-off-by: Peter Hutterer
Also:
Tested-by: Carlos Garnacho
Thanks :),
Carlos
___
one to remove
>> before too long now that v1 has made it upstream...
>
> hmm, good point, not sure why I didn't use wl_fixed other than "i didn't
> think of it". It has finer granularity and provides the required range, so
> it would be the better choice.
A couple of grammar nitpicks below:
2016-03-01 1:09 GMT+01:00, Peter Hutterer :
> Signed-off-by: Peter Hutterer
> Reviewed-by: Daniel Stone
> ---
> Changes to v5:
> - remove leftover statement falsely claminig wp_tablet_tool.destroy requires
> a remove event first
>
> Makefile.am
Signed-off-by: Carlos Olmedo Escobar
---
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
b/unstable/pointer-constraints/pointer-constraints
Hey :),
On Fri, Feb 26, 2016 at 1:54 PM, Pekka Paalanen wrote:
> On Mon, 15 Feb 2016 16:59:02 +0800
> Jonas Ådahl wrote:
>
>> On Thu, Feb 11, 2016 at 01:52:36PM +0100, Carlos Garnacho wrote:
>> > The xdg_launcher interface is added for the launcher, it's used
>&g
Hey :),
On Mon, Feb 15, 2016 at 9:59 AM, Jonas Ådahl wrote:
> On Thu, Feb 11, 2016 at 01:52:36PM +0100, Carlos Garnacho wrote:
>> The xdg_launcher interface is added for the launcher, it's used
>> to notify of the startup ID to be transmitted to the launchee,
>> pl
ake drag-and-drop target hidden. This allows
drag-and-drop to work between X11 clients in Xwayland, and avoids
a crash with (currently unhandled) wl_resource-less data sources.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=94218
Signed-off-by: Carlos Garnacho
---
I'm sending this patch
Hi Michal,
On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek wrote:
> On 22 February 2016 at 15:57, Carlos Garnacho wrote:
>> Hi Michal,
>>
>> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 2
Hi Michal,
On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote:
> Hello,
>
> On 20 February 2016 at 01:31, Carlos Garnacho wrote:
>
>> +
>> +
>> +This protocol provides the ability to have a primary selection device to
>> +match that of the X
Hey Jonas,
On Mon, Feb 22, 2016 at 8:53 AM, Jonas Ådahl wrote:
> On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote:
>> From: Lyude
>>
>> This primary selection is similar in spirit to the eponimous
>> in X11, allowing a quick "select text + middle c
Signed-off-by: Carlos Garnacho
---
After having talked with Lyude, I'll be trying to move this ahead.
Changes since v3:
- Added a rather verbose protocol description, including a
high-level overview of the workings.
- Made event emission 1:1 with wayland core
Hey Daniel :),
I see Jonas replied, I'll try to give some more detail.
On Thu, Feb 18, 2016 at 11:03 AM, Daniel Stone wrote:
> Hi,
>
> On 31 July 2015 at 14:53, Carlos Garnacho wrote:
>> On Wed, Jul 29, 2015 at 4:52 AM, Jonas Ådahl wrote:
>>> On Thu, Jul 23, 201
ceive startup IDs that are guaranteed to be unique, whereas
in X11 this is a best effort of the launcher client.
Some notes have also been added about focus stealing prevention,
although that's mostly up for compositors to implement.
Signed-off-by: Carlos Garnacho
---
I've got no full
aviour. For the Cintiq I think it might
> be better to put a device-specific quirk in to simply supress those events
> since we don't have anything outside of these boundaries. Jason, Carlos, any
> comments?
I agree, reporting those would mean that such tablets could move
"outs
es the first offer.
>
> That seems better than a livelock though. Maybe we can grab all available
> offers when cloning the selection instead of just the first (but that should
> be done in addition to this patch, I think, because we could have an app that
> doesn't offer text at a
; +Sent after we've send offer events for all of the available mime
> types.
> +
Here I see a slight difference with wl_data_device and wl_data_offer
that would be great to even out, as it better allows clients to
abstract wl_data_* and zwp_primary_selection_* in common interfaces.
In zwp_primary_selection, you first receive a
zwp_primary_selection_device_v1.selection_offer, and then this event
in zwp_primary_selection_offer_v1, whereas in the wayland core
protocol both the "offer introduction" and the "offer being put to
use" events happen both on wl_data_device (.data_offer and .selection,
respectively).
This event can be maybe seen as belonging to the offer (it's state of
the offer, at least), but I admit I'm more sold on the final event
where you can start using the offer to be a device one.
Cheers
Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
this patch.
Signed-off-by: Carlos Garnacho
---
xwayland/dnd.c | 2 +-
xwayland/selection.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xwayland/dnd.c b/xwayland/dnd.c
index a036b30..f17e4cd 100644
--- a/xwayland/dnd.c
+++ b/xwayland/dnd.c
@@ -162,7 +162,7
We're not always dealing with weston_data_sources that have a
wl_resource, or data_sources that belong to drag-and-drop. Check
harder for these on the drag-and-drop code paths triggered from
common code.
Signed-off-by: Carlos Garnacho
---
src/data-device.c | 8 ++--
1 file chang
The wrapped weston_data_source struct has new fields which were left
uninitialized, so its access is unreliable.
Signed-off-by: Carlos Garnacho
---
src/clipboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/clipboard.c b/src/clipboard.c
index da7dbb6..54a578f 100644
- Fixed coding style issues.
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
Reviewed-by: Jonas Ådahl
---
clients/dnd.c | 36 +--
clients/window.c | 34 ++
clients/window.h | 3 +
src/compositor.h |
ted we should add a note about the per version requirements
> (wl_data_source.set_actions, wl_data_offer.accept and wl_data_offer.finish
> during DND), see here is such a paragraph.
Oh indeed. Makes sense to mention this in wl_data_device_manager docs,
Reviewed-by: Carl
Hi Jonas!
On Sat, Jan 16, 2016 at 9:37 AM, Jonas Ådahl wrote:
> On Fri, Jan 15, 2016 at 02:49:33PM -0800, Bryce Harrington wrote:
>> On Fri, Jan 15, 2016 at 09:11:40PM +0100, Carlos Garnacho wrote:
>> > These 2 requests have been added:
>> >
>> > - wl_d
Hey Bryce :),
On Sat, Jan 16, 2016 at 12:13 AM, Bryce Harrington
wrote:
> On Fri, Jan 15, 2016 at 09:14:25PM +0100, Carlos Garnacho wrote:
>> That way we'll be able to set the corresponding pointer surface to
>> a current DnD operation.
>>
>> Signed-off-by: Carlos
2:
- Split from DnD progress notification changes.
Changes since v1:
- Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
- Fixed coding style issues.
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
---
clients/dnd.c | 36 +++
That way we'll be able to set the corresponding pointer surface to
a current DnD operation.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
---
clients/window.c | 16
clients/window.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/clients/window.c b/cl
nges since v2:
- Handle wl_data_offer.finish. Fixed commit log inconsistencies.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.
Changes since v1:
- Updated to protocol v2.
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
Reviewed-by: Jonas Ådahl
---
le the keyboard grab being cancelled. Initialize new
wl_data_source fields.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
---
src/compositor.h | 1 +
src/data-device.c | 76 +++
2 files changed, 77 insertions(+)
diff --git a/sr
v2:
- Updated to behave alright-ish with version < 3.
Changes since v1:
- Remove unneeded include. Remove extra newlines. Other minor
code fixes.
Signed-off-by: Carlos Garnacho
Reviewed-by: Jonas Ådahl
---
clients/dnd.c | 106 ++
1
ata_offer.accept and
wl_data_source.cancelled.
Changes since v2:
- Minor rewording.
Changes since v1:
- Renamed events to have a common "dnd" namespace. Made dnd_performed to
happen invariably, data_device.cancelled may still happen afterwards.
Signed-off-by: Carlos Garnacho
rity
- Improved wording as suggested by Bryce
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
Reviewed-by: Mike Blumenkrantz
Reviewed-by: Jonas Ådahl
---
protocol/wayland.xml | 205 ++-
1 file changed, 204 insertions(+), 1 del
Hey Jonas,
On Fri, Jan 15, 2016 at 6:32 AM, Jonas Ådahl wrote:
> On Thu, Jan 14, 2016 at 11:43:39PM +0100, Carlos Garnacho wrote:
>> Weston now sends wl_data_source.dnd_drop_performed and .dnd_finished in
>> order to notify about the different phases of DnD.
>>
>>
Hey Jonas,
On Fri, Jan 15, 2016 at 7:10 AM, Jonas Ådahl wrote:
> On Thu, Jan 14, 2016 at 11:46:34PM +0100, 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
>
urce_actions.
- Fixed coding style issues.
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
---
clients/dnd.c | 32 +--
clients/window.c | 25
src/compositor.h | 5 ++
src/data-device.c | 169 --
4
es.
Added version checks. Spaces vs tabs fixes. Fixed resource
versioning.
Changes since v1:
- Updated to protocol v2.
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
---
clients/dnd.c | 39 +++-
clients/window.c | 3 +-
src/compositor.h | 3 ++
src/
e moment.
Changes since v1:
- Added wl_data_offer.source_actions to let know of the actions offered
by a data source.
- Renamed wl_data_source.finished to "drag_finished" for clarity
- Improved wording as suggested by Bryce
Signed-off-by: Carlos Garnacho
Reviewed-by: Michael Catanzaro
Revie
Hi Michal,
On Mon, Jan 11, 2016 at 11:34 AM, Michal Suchanek wrote:
> On 24 December 2015 at 01:58, Carlos Garnacho wrote:
>
>> @@ -757,6 +883,40 @@
>>
>>
>>
>> +
>> +
>> +
>> +
>> +
>>
1 - 100 of 296 matches
Mail list logo
