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?
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg
