Proposed libX11 ABI break
Thomas Jaeger
thjaeger at gmail.com
Mon Jun 29 21:58:44 PDT 2009
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.
More information about the xorg-devel
mailing list