On Mon, Oct 6, 2014 at 12:20 AM, Pekka Paalanen wrote:
> On Sun, 5 Oct 2014 18:48:27 -0700
> "Jasper St. Pierre" wrote:
>
> > One of my issues is what happens for objects that have multiple parents,
> > like wl_buffer or wl_callback. What do we do if another person wants to
> > introduce another
On Sun, 5 Oct 2014 18:48:27 -0700
"Jasper St. Pierre" wrote:
> One of my issues is what happens for objects that have multiple parents,
> like wl_buffer or wl_callback. What do we do if another person wants to
> introduce another (like the recently proposed pointer lock extension)? We
> can recom
One of my issues is what happens for objects that have multiple parents,
like wl_buffer or wl_callback. What do we do if another person wants to
introduce another (like the recently proposed pointer lock extension)? We
can recommend that users never use wl_callback directly and instead use
their ow
Ping
On Fri, Apr 11, 2014 at 1:36 AM, Jason Ekstrand
wrote:
> On Fri, Apr 11, 2014 at 2:03 AM, Pekka Paalanen
> wrote:
>
>> On Thu, 10 Apr 2014 09:42:55 -0500
>> Jason Ekstrand wrote:
>>
>> > On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen
>> wrote:
>> >
>> > > Hi Jason,
>> > >
>> > > thanks
On Fri, Apr 11, 2014 at 2:03 AM, Pekka Paalanen wrote:
> On Thu, 10 Apr 2014 09:42:55 -0500
> Jason Ekstrand wrote:
>
> > On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen
> wrote:
> >
> > > Hi Jason,
> > >
> > > thanks for working on this, it does seem very useful, practically a
> > > mandatory
On Thu, 10 Apr 2014 09:42:55 -0500
Jason Ekstrand wrote:
> On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen wrote:
>
> > Hi Jason,
> >
> > thanks for working on this, it does seem very useful, practically a
> > mandatory feature to support.
> >
>
> Hi Pekka,
> Yeah, I've been itching to knock t
On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen wrote:
> Hi Jason,
>
> thanks for working on this, it does seem very useful, practically a
> mandatory feature to support.
>
Hi Pekka,
Yeah, I've been itching to knock this out for a while. Just finally got
around to it. Comments below.
>
>
>
Hi Jason,
thanks for working on this, it does seem very useful, practically a
mandatory feature to support.
We already had the versioning rules documented, right? Whenever bumping
an interface version, also the parent interface (factory) version must
be bumped. That makes the version inference
On Wed, Apr 2, 2014 at 9:51 AM, Jasper St. Pierre wrote:
> Does this help clean up client code? Can you give an example of how a
> client would use this?
>
Without this, the client has to track versions of everything if it's going
to do anything version-dependent with a protocol object. If it's
Does this help clean up client code? Can you give an example of how a
client would use this?
On Wed, Apr 2, 2014 at 10:48 AM, Jason Ekstrand wrote:
> It's worth noting that there is one small backwards-compatability issue
> here. Namely, if the client is built against protocol stubs from an
> e
It's worth noting that there is one small backwards-compatability issue
here. Namely, if the client is built against protocol stubs from an
earlier version of libwayland but links against a library built against a
newer version, then all objects created by the client will report a version
of 1. T
This provides a standardized mechanism for tracking protocol object
versions in client code. The wl_display object is created with version 1.
Every time an object is created from within wl_registry_bind, it gets the
bound version. Every other time an object is created, it simply inherits
it's ver
12 matches
Mail list logo
