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

[Owen Taylor]

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:

Advantages:

 - 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

Disadvantages:

 - 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.)

Regards,
                                            Owen