On mån, 2013-05-13 at 13:49 +0200, John Kåre Alsaker wrote:
> On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson
> wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' event which
> signals
> > tha
On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' event which signals
> > that the compositor is done sending a batch of events for an wl_output
> > and related extension obj
On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> For the wl_output case I suggest we add a 'done' event which signals
> that the compositor is done sending a batch of events for an wl_output
> and related extension objects (which versioned message arguments won't
> handle). This would
For the wl_output case I suggest we add a 'done' event which signals that
the compositor is done sending a batch of events for an wl_output and
related extension objects (which versioned message arguments won't handle).
This would be analogous to wl_surface.commit, only coming from the server
side.
On mån, 2013-05-13 at 12:19 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 10:23:44 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
> >
> > >
> > > In short, I think this is far too complex for what it achieves. In
> > > the case of scaling f
On Mon, 13 May 2013 10:23:44 +0200
Alexander Larsson wrote:
> On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> >
> > In short, I think this is far too complex for what it achieves. In
> > the case of scaling factor stuff, you can just do it with a second
> > event.
>
> I agree tha
On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> In short, I think this is far too complex for what it achieves. In
> the case of scaling factor stuff, you can just do it with a second
> event.
I agree that what I posted have some open issues, and it was mostly
meant as a start of a
On Wed, May 8, 2013 at 5:51 AM, wrote:
> From: Alexander Larsson
>
> This allows an event to be extended in a backwards compatible way (on
> the client side) by marking an argument with a since attribute.
> Any arguments with a since value later than then value of the message
> itself will be ma
From: Alexander Larsson
This allows an event to be extended in a backwards compatible way (on
the client side) by marking an argument with a since attribute.
Any arguments with a since value later than then value of the message
itself will be marked optional and the demarshaller will supply
defau
