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