[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg-devel
Subject: Proposed libX11 ABI break
From: thjaeger () gmail ! com (Thomas Jaeger)
Date: 2009-06-30 4:58:44
Message-ID: 4A499B84.20005 () gmail ! com
[Download RAW message or body]
Eamon Walsh wrote:
> Peter Hutterer wrote:
>> On Fri, Jun 26, 2009 at 03:46:26PM -0400, Eamon Walsh wrote:
>>
>>> Why don't we just not support returning XGE events from those old
>>> functions ?
>>>
>> This was the alternative towards the end of the previous email. To quote:
>>
>
>>>> The only other solution I could come up with so far is to add XGENextEvent()
>>>> and friends as substitutes for XNextEvent & co. In this approach, XNextEvent
>>>> _never_ returns generic events, leaving existing clients ABI-safe.
>>>> XGENextEvent requires an argument of the cookie+data type.
>>>>
>
> New API could be conceptually cleaner and not have the cookies at all,
> just return a malloc'ed buffer. Even if you end up doing the cookie
> thing, new API could bypass that and assume the caller will take care of
> freeing.
As an alternative to new event API, wouldn't it be easier if
applications were required to announce that they support generic events
before event processing begins in order to receive generic events -- say
by calling XGEInit(dpy). If we call XGEInit from XIQueryVersion, then
no client code needs to be changed or recompiled.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic