[Xr] What happended to the idea of getting rid of the xrs argument?

Owen Taylor otaylor at redhat.com
Wed Jun 4 12:36:09 PDT 2003

On Tue, 2003-06-03 at 00:11, Bill Spitzak wrote:
> 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 future.
> 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.

I just wanted to comment that my perspective as a toolkit author
is exactly opposite.

We try very hard to make all GTK+ API's usable from a wide range
of languages; an api with calls like XrFill() would be a big 
problem from that perspective. While certainly the FLTK authors
have more experience writing C++ interfaces than I do, I can't
imagine that many C++ programmers would be comfortable with
a drawing API that was largely static methods.

(Most Xr API calls don't have a "lightweight" object associated
with them; they don't fit into the mold of line.draw())

As for non-Xr platforms ... the approach for GTK+ would be try to 
use Xr on all platforms. There are advantages and disadvantages
to that, of course:


 - No worries about how consistent drawing between different platforms
 - Could (eventually) ditch all the copied-from Xlib drawing code
   used on framebuffer targets.
 - No need to wrap Xr


 - HW acceleration on non-RENDER platforms wouldn't be available
   (Xc-on-OpenGL would probably be the right way to tackle that.)
 - Text APIs may be a problem, since some platforms may not
   support fast rendering of glyphs to all Xr surfaces. (We'd like
   to keep using Uniscribe and native fonts on Windows.)


More information about the cairo mailing list