Problems with X.org and incompatibilities with in-house software

[Richard Brown]

Alan Coopersmith wrote:
> Richard Brown wrote:
>   
>> Our applications make extensive use of a large number of X extensions,
>> these include, but are not limited to, MIT-Sundry-Nonstandard (many of
>> our oldest programs from the early days use this) ,TOG-CUP, Xtrap,
>> Xfree86-Misc, XEvIE, EVI, PEX, (for many of our 3D modelling and CAD
>> applications),
>>     
>
> PEX?  Really?  And you've had this supported on any system made since the
> mid-90's?   Even Sun dropped that in Solaris 7 in 1998, and XFree86 removed
> it long ago, before the current X.Org organization took over the development
> of X.
>
>   
We've used PEX with some older hardware, though we done most stuff over 
by now with OpenGL. I suppose PEX is not that important anymore and we 
can move completely to OpenGL. If PEX does not have any software 
renderer that does not need a hardware support, and it could be 
re-enabled with just setting it back into the compile process, why not 
put it back in. If supporting any of these features would drain your 
resources and take massive amounts of time, I can understand that, and 
would not ask that. But if it would just take just changing a few 
compile time things to bring it back in, why not put this stuff back 
into X.org. I can understand if some of these extensions would require 
massive reworking to make working again, I could not ask anyone to 
commit that kind of time.

We will probably work to rewrite our software to work around many of the 
problems and stay with X.

I would be interested in the rationale to disable extensions. "This 
isn't needed anymore" is not good enough. Assume that there is someone 
still using the extension, somewhere, an older program that needs it. 
Perhaps, if the extension required rewriting of thousands of lines of 
code to keep it working, that might be a good reason to disable it. But 
dropping support for these things "because we can" or because "we didnt 
like how it looked there", didnt seem like a good idea.

Xprint: This allows printing to a postscript file. Seems immensely 
useful to me as it allows X itself to be used as a printer API. Why was 
this removed? Is there any major code problem that would have to be fixed?

Xtrap, TOG-CUP, Xfree86-misc, XeVIE, EVI, MIT-Sundry-Nonstandard. Again, 
some  programs may need it. Any code problems that would have to be 
fixed, again, wht are the technical problems, are these broken, do they 
require major work?

XeVIE seemed very recent. Why was this removed? Is there really huge 
amounts of broken code there? Xtrap allows capturing of user events? Why 
remove such functionality? Again, does it contain broken code?


If it requires major work to get these back in, i can understand and i 
will not request that, we will just spend the time to rework our 
software to not use them. But if its a simple thing of putting them back 
into the compile, why not?