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

[David Forster]

On Wed, Jun 11, 2003 at 09:22:48AM -0700, Bill Spitzak wrote:
> The problem is that the programmer now has to call "fltkRectangle"
> rather than "XrRectangle". This immediately makes their drawing code
> non-portable to other toolkits, which are unlikely to implement
> "fltkRectangle".

> I think this non-portability is a handicap. My "proof" (if there is
> any) is in the popularity of OpenGL and the fact that people can
> call OpenGL directly from every toolkit in the world, but nobody
> calls Xlib or GDI32 or DirectX without making lots of
> toolkit-specific code. I have certainly found that a block of Glut
> code that draws OpenGL can be cut and pasted with NO changes into an
> fltk program, into a Qt program, and into an MFC program. This is
> despite the fact that the "context creation" is vastly different in
> each of these toolkits. Therefore I believe the reason for this is
> that there is no "context" argument.

Your not making much sense here.  The OpenGL designers left the state
argument out for efficiency reasons, not `cut-and-pastability.'  The
fact that OpenGL is so widely used is because it's a standardized and
complete API that's avaliable on many platforms.  Introducing a state
argument wouldn't effect OpenGL code portability, just as it doesn't
for Xr and Quartz.  I mean, what about the POSIX read()/write()
functions?  They each use an explicit `state' argument and yet there's
plenty of `portable' code there.

However, my idea of `portable code' isn't necessarily cut and pastable
code, but rather code I don't have to touch when porting between one
platform to the next.  I.e., if I wrote a SWF render (Flash) for Xr, I
might have a library with the API:

SwfAnimation *SwfCreate(void *swfbuffer);
void          SwfDestroy(SwfAnimation *swf);
void SwfSetSize(SwfAnimation *swf, double w, double h);
void SwfRender(XrState* xrs, SwfAnimation *swf, int time);
void SwfMouseAt(SwfAnimation *swf, double x, double y);

Now lets assume someone ports Xr to Quartz and they want to use my SWF
library on MacOS X.  Why is my code now no good?

In fact, as an aside, this might be a good example where I want thread
safety.  I might not want to block all other rendering while my SWF
render strains over a complex animation.  So I'd have my SwfRender()
loop run on it's own thread with it's own XrState*.

Irregardless, I'm not saying having a no-XrState API is pointless.  I
can see where it comes in handy, but I don't see why having your own
wrapper is all that bad or why Xr needs to provide a universal one.
At API boundaries you simply use an explicit XrState* argument and
keep your wrapper API internal.

> If code could be cut & pasted without changes it would help a lot
> for matching appearances between programs or making portable "theme
> plugins". It would also make it lots easier to write libraries that
> lie atop Xr that can be called from different toolkits. And it would
> make demos of how to use Xr much easier to write and test.

While I doubt a universal theme API would ever be created, how does
the XrState* issue affect it?:

Theme *ThemeLoad(const char *theme);
void   ThemeRenderBevel(XrState* xrs, Theme *theme, ...);
void   ThemeRenderButtonBackground(XrState *xrs, Theme *theme, ...);

Actully, both the GTK+ and Qt projects would probably reject this on
the basis they want themes to be portable to all their supported
platforms, not just platforms where they use Xr.

Finally, the XrState object does not significantly obfuscate code to
make it impossible/difficult for people to learn.  People who can't
handle it are probably not going to be doing anything useful on Xr's
level.  Besides, Xr's main responsibility is to real and complex
applications, not sample code and demos.


Really this whole issue could be resolved by creating a seperate but
`standard' wrapper API.  If everyone uses it, code will look the same
accross projects and be copyable.

I'm actully working on some code where I might use a global XrState*
object, and have written my own wrapper.  You can grab it at:

ftp://forster.homeunix.net/pub/xrs/Xrs.h

I havn't actully tested yet, but it's pretty simple...It's MIT
licensed so anyone fell free to use it in your own code.  But I think
Xr is fine the way it is.

Respectfully,
-David Forster