Re: XFIXES extension proposal

Around 3 o'clock on Dec 1, James Hawtin wrote:

> The only problem with the fixes extension will people use it, as they
> will have to write the code twice so it supports "legancy" ie not Xfree86
> systems. (thinking of selection tracking here)

That's been the argument against such extensions over the last 15 years, 
and it's certainly valid as far as it goes, but I think we can now look 
toward more rapid adoption of extensions in the general population, 
certainly rapidly enough to provide incentive for application developers 
to support the new mechanisms in addition to the old.

> As kludges exist for some of these fixes, a compatibility library could be
> made so people who wrote code in the "new" way, would have some kind of
> support on other systems, but still could write things "clean", in the
> case of selection tracking, it would do the polling, but return events as
> if the XFIXES was there.

Perhaps that would be possible at the toolkit level, but down at the 
protocol library level, there's no flow of control to manage timeouts and 
the like.  As XFree86 doesn't really have control over the dominate 
toolkits, we'll have to see what those groups manage to implement, 
although we might give them some suggestions.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab