[Xr] What happended to the idea of getting rid of the xrs
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