On Wed, Sep 30, 2015 at 3:15 AM, Bryce Harrington wrote:
> On Tue, Sep 29, 2015 at 10:28:03AM +0300, Pekka Paalanen wrote:
>> On Mon, 28 Sep 2015 00:30:10 +0200
>> Frederico Cadete wrote:
>>
>> > Otherwise, auto-enable depending on whether the system has the necessary
>> > libraries.
>> > ---
>>
On Tue, May 05, 2015 at 03:01:53PM -0500, Derek Foreman wrote:
> This lets device_added() do additional processing before the update is
> sent, which will be useful later when recognizing keyboard capabilities.
Is the point of this to unset the keyboard capability for a keyboard
device or how is i
On Tue, May 05, 2015 at 03:01:52PM -0500, Derek Foreman wrote:
> Break device_removed() out into its own function like device_added().
>
> Signed-off-by: Derek Foreman
With one nit below, this is Reviewed-by: Jonas Ådahl
> ---
> src/libinput-seat.c | 12 +---
> 1 file changed, 9 inser
On Tue, May 05, 2015 at 03:01:51PM -0500, Derek Foreman wrote:
> We're going to need this on device removal in the future, so pull it out
> into a separate function now.
>
> Signed-off-by: Derek Foreman
Reviewed-by: Jonas Ådahl
> ---
> src/libinput-seat.c | 17 -
> 1 file chan
On Tue, Sep 29, 2015 at 04:51:58PM -0500, Derek Foreman wrote:
> On 23/09/15 12:15 PM, Giulio Camuffo wrote:
> > 2015-09-23 19:46 GMT+03:00 Derek Foreman :
> >> On 01/02/15 08:18 AM, Giulio Camuffo wrote:
> >>> The xwm gets a primary view for a X window using the get_primary_view
> >>> vfunc of the
Dear Peter,
from the techinical point of view, calling an API several times doesn't matter.
I'm with you,
as we call dequeue() for a queue to get the queued item in order.
Regarding a queue, we know that we're using a queue therefore we'll call
dequeue in natural ways.
By the way, regarding a ca
On Tue, Sep 29, 2015 at 10:28:03AM +0300, Pekka Paalanen wrote:
> On Mon, 28 Sep 2015 00:30:10 +0200
> Frederico Cadete wrote:
>
> > Otherwise, auto-enable depending on whether the system has the necessary
> > libraries.
> > ---
> > configure.ac | 36
> > 1 f
On Tue, Sep 29, 2015 at 03:11:33PM +0300, Pekka Paalanen wrote:
> On Tue, 29 Sep 2015 14:50:41 +0300
> Egor Starkov wrote:
>
> > Systemd notifications support was converted into loadable
> > module, so systemd-notify.h header is not needed.
> >
> > Signed-off-by: Egor Starkov
> > ---
> > Makef
On Tue, Sep 29, 2015 at 09:18:52PM +0100, Daniel Stone wrote:
> Hi,
>
> On 29 September 2015 at 20:26, Carlos Garnacho wrote:
> > I would like to throw the idea of holding a regular
> > conference/meeting/bof though, I think it's a nice way to passively
> > check the state of development around o
On Tue, Sep 29, 2015 at 05:34:41PM +0100, Daniel Stone wrote:
> Hi,
> Leaving the more mechanical issue of how we deal with extension
> development for the moment ...
>
> > I don't think we've really had a maintainer since krh. I tried to take
> > over reviewing and releasing things and got exhaust
On 23/09/15 12:15 PM, Giulio Camuffo wrote:
> 2015-09-23 19:46 GMT+03:00 Derek Foreman :
>> On 01/02/15 08:18 AM, Giulio Camuffo wrote:
>>> The xwm gets a primary view for a X window using the get_primary_view
>>> vfunc of the shell_interface struct. Storing it is dangerous though because
>>> it do
Hi,
On 29 September 2015 at 21:18, Carlos Garnacho wrote:
> On Tue, Sep 29, 2015 at 6:34 PM, Daniel Stone wrote:
>> It's probably most helpful to look at the context in which we had our
>> maintainers, and the way Wayland development has ebbed and flowed. krh
>> was building Wayland quite litera
Hi,
On 29 September 2015 at 20:26, Carlos Garnacho wrote:
> I would like to throw the idea of holding a regular
> conference/meeting/bof though, I think it's a nice way to passively
> check the state of development around other areas, seeing working code
> in action without keeping track of extra
Hey Daniel,
On Tue, Sep 29, 2015 at 6:34 PM, Daniel Stone wrote:
> Hi,
> Leaving the more mechanical issue of how we deal with extension
> development for the moment ...
>
> On 29 September 2015 at 14:53, Pekka Paalanen wrote:
>> On Tue, 29 Sep 2015 14:02:52 +0200
>> Carlos Garnacho wrote:
>>>
Hi Jonas,
On 18 September 2015 at 08:00, Jonas Ådahl wrote:
> Right now, the way to get a protocol officially declared stable is, more
> or less, to implement it in weston, wait for a while maybe making
> changes, and then when agreed upon moved to the wayland repository. While
> being in weston,
Hey Pekka,
On Tue, Sep 29, 2015 at 3:53 PM, Pekka Paalanen wrote:
>> > Whoever is a known expert on that area.
>> >
>> > Who decides who is an expert? Uhh...
>>
>> It wouldn't be good if every maintainer thinks like that :), even
>> worse if that results in no action taken... I understand the
Awesome, thanks Damien! It looks beautiful, and it'll be extremely
handy having the A/R/T columns now.
Series-awareness would be a lovely feature, so definitely keep up the
great work.
Bryce
On Tue, Sep 29, 2015 at 04:33:07PM +0100, Damien Lespiau wrote:
> Hi all,
>
> You may have noticed alre
On 29/09/15 12:47 PM, Bill Spitzak wrote:
> Another important point is that the compositor can check what *type* of
> event was used for the raise. It could accept press/release and ignore
> move events, for instance. Keyboard events could be ignored if the
> client no longer has keyboard focus, wh
Hi,
On 29 September 2015 at 19:07, Bill Spitzak wrote:
> On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman
> wrote:
>> I'm not sure I follow - are you saying we need a "special buttons" focus
>> for multimedia keys? (backlight keys? do we need a backlight focus
>> too, or?)
>
> I thought the ass
On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman
wrote:
> I'm not sure I follow - are you saying we need a "special buttons" focus
> for multimedia keys? (backlight keys? do we need a backlight focus
> too, or?)
>
I thought the assumption was that if a key does a global action, it is the
compo
Hi,
On 29 September 2015 at 18:47, Bill Spitzak wrote:
> Another important point is that the compositor can check what *type* of
> event was used for the raise. It could accept press/release and ignore move
> events, for instance. Keyboard events could be ignored if the client no
> longer has key
Another important point is that the compositor can check what *type* of
event was used for the raise. It could accept press/release and ignore move
events, for instance. Keyboard events could be ignored if the client no
longer has keyboard focus, while clicks are ignored if the client no longer
has
Hi,
Leaving the more mechanical issue of how we deal with extension
development for the moment ...
On 29 September 2015 at 14:53, Pekka Paalanen wrote:
> On Tue, 29 Sep 2015 14:02:52 +0200
> Carlos Garnacho wrote:
>> On Mon, Sep 21, 2015 at 2:28 PM, Pekka Paalanen wrote:
>> > Technically, peopl
Hi all,
You may have noticed already, patchwork.freedesktop.org looks different.
That new version includes:
- Some re-design. Design is very much an iterative process, thoughts
and comments are welcome,
- Showing the number of Reviewed-by, Acked-by, Tested-by tags,
- Some cleanup of the
Hi,
On 23 September 2015 at 17:33, Derek Foreman wrote:
> On 25/02/15 08:03 AM, David FORT wrote:
>> As stated in the very good blog post[1] of Pekka Paalanen, server-side we
>> can have
>> sometime troubles with object that the server has deleted but that the client
>> is still requesting. This
On 29/09/15 08:05 AM, Benoit Gschwind wrote:
> Hello,
>
> Maybe my thought is insignificant, but I would like to share it anyway,
> as young window manager developer.
No opinion is insignificant. :)
Mine is different than yours, however.
> I think all your arguments (both side) are valid. But I
On Tue, 29 Sep 2015 08:15:26 -0500
Derek Foreman wrote:
> On 28/09/15 02:29 PM, Chris Michael wrote:
> > Please find attached patch to fix issue with weston_log message not
> > ending with a return
> >
Hi,
please use git-send-email the next time, this patch does not apply as is.
I did the cha
Hi,
On 29 September 2015 at 14:05, Benoit Gschwind wrote:
> Maybe my thought is insignificant, but I would like to share it anyway,
> as young window manager developer.
It's fair enough, and I see what you have to say. All I really have to
say in return is two things:
- if we add global co-ord
On Tue, 29 Sep 2015 14:02:52 +0200
Carlos Garnacho wrote:
> Hi Pekka,
>
> On Mon, Sep 21, 2015 at 2:28 PM, Pekka Paalanen wrote:
> > On Fri, 18 Sep 2015 22:44:16 +0800
> > Jonas Ådahl wrote:
> >
> >> On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:
> >> > On Fri, 18 Sep 2015 15:
On 28/09/15 02:29 PM, Chris Michael wrote:
> Please find attached patch to fix issue with weston_log message not
> ending with a return
>
>
>
> From 8de51c0e54d6a60a5c326ec3af1c0134044be5ce Mon Sep 17 00:00:00 2001
> From: Chris Michael
> Date: Mon, 28 Sep 2015 15:24:18 -0400
> Subject: [PATCH]
Hello,
Maybe my thought is insignificant, but I would like to share it anyway,
as young window manager developer.
I think all your arguments (both side) are valid. But I will defend the
point of view of Jasper. While technically I agree there is no need of
absolute positioning and many solution a
On Tue, 29 Sep 2015 14:50:41 +0300
Egor Starkov wrote:
> Systemd notifications support was converted into loadable
> module, so systemd-notify.h header is not needed.
>
> Signed-off-by: Egor Starkov
> ---
> Makefile.am | 4 +---
> src/main.c | 1 -
> src/systemd-notify.h |
Hi Pekka,
On Mon, Sep 21, 2015 at 2:28 PM, Pekka Paalanen wrote:
> On Fri, 18 Sep 2015 22:44:16 +0800
> Jonas Ådahl wrote:
>
>> On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:
>> > On Fri, 18 Sep 2015 15:00:19 +0800
>> > Jonas Ådahl wrote:
>> >
>> > > Hi,
>> > >
>> > > I'd like
Systemd notifications support was converted into loadable
module, so systemd-notify.h header is not needed.
Signed-off-by: Egor Starkov
---
Makefile.am | 4 +---
src/main.c | 1 -
src/systemd-notify.h | 47 ---
3 files changed, 1 i
Please find attached patch to fix issue with weston_log message not
ending with a return
From 8de51c0e54d6a60a5c326ec3af1c0134044be5ce Mon Sep 17 00:00:00 2001
From: Chris Michael
Date: Mon, 28 Sep 2015 15:24:18 -0400
Subject: [PATCH] compositor-wayland: Terminate weston_log error message
Si
On Fri, 25 Sep 2015 16:07:12 -0500
Derek Foreman wrote:
> On 25/09/15 02:46 PM, Hardening wrote:
> > Le 25/09/2015 19:15, Derek Foreman a écrit :
> >> On 25/09/15 08:19 AM, Hardening wrote:
> >>> Le 25/09/2015 11:31, Pekka Paalanen a écrit :
> On Thu, 24 Sep 2015 23:40:26 +0200
> David
Le 29/09/2015 09:58, Jonas Ådahl a écrit :
> On Tue, Sep 29, 2015 at 09:43:01AM +0200, David FORT wrote:
>> This is required if we want to correctly remove a wl_seat compositor-side. A
>> wl_seat is announced as a global object, then it is bound by the client. When
>> the compositor wants to remove
On Tue, Sep 29, 2015 at 09:43:01AM +0200, David FORT wrote:
> This is required if we want to correctly remove a wl_seat compositor-side. A
> wl_seat is announced as a global object, then it is bound by the client. When
> the compositor wants to remove the seat, it shall announce the global removal
Hi Derek, and thanks a lot for your feedback,
I think it makes sense if you consider the compositor can know if a past
input event could have happened "not long ago" or "a very long time ago"
(if the event happened not long ago, raise the window, otherwise blink). It
is really a matter of policy,
On Sun, Sep 27, 2015 at 10:51:40PM +0200, Hardening wrote:
> Le 24/09/2015 01:59, Jonas Ådahl a écrit :
> > On Wed, Sep 23, 2015 at 11:17:33AM -0500, Derek Foreman wrote:
> >> On 25/02/15 08:03 AM, David FORT wrote:
> >>> This is required if we want to correctly remove a wl_seat server-side.
> >>>
This is required if we want to correctly remove a wl_seat compositor-side. A
wl_seat is announced as a global object, then it is bound by the client. When
the compositor wants to remove the seat, it shall announce the global removal of
the object. The client can then call the release request on the
On Mon, 28 Sep 2015 00:30:10 +0200
Frederico Cadete wrote:
> Otherwise, auto-enable depending on whether the system has the necessary
> libraries.
> ---
> configure.ac | 36
> 1 file changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/configure.ac b/
42 matches
Mail list logo