[Xr] What happended to the idea of getting rid of the xrs argument?
spitzak at d2.com
Mon Jun 2 21:11:37 PDT 2003
Is this dead or not? I still feel it would be a very good idea. I need to
know what kind of outcome we can expect from this as it affects whether fltk
will use Xr or not. If the argument is required then I must write a wrapper
function for every Xr function, in which case I may as well retain
back-compatability. If the xrs argument is deleted then I will change the
interface to match Xr exactly, in the hope that program can really call Xr in
The only real argument I heard for keeping the xrs argument is that this is
more "object oriented" in that writing object.XrLine(...) is somehow useful
and better than just writing XrLine(...).
Unfortunately I cannot see how Xr in it's current state helps this. It is
extremely unlikely any object provided by a higher-level interface will be a
subclass of XrState, because of the need to create light-weight and
non-displayed objects and the need to port to non-Xr systems.
If you have a call that returns an "xrs object" then this is exaclty the same
as the current situation, there is no real difference between typing
x->XrFoo(...) and XrFoo(x,...).
The only way to implement the above in any reasonable way is to have the
toolkit provide a wrapper for every Xr call, which means the toolkit must be
rewritten for every Xr update. Also any possible implementation will probably
be slowed by the addition of a "did I create the xrs, if not create it" test.
If another method to create the xrs is added then the programming problem is
exactly the same as for the non-xrs version.
In any case I am much more convinced this would be a very good idea and am
anxious to find out if there is any chance it could or will happen.
More information about the cairo