Thanks for your answers Jon.
On Sun, 30 Apr 2000, Jon M. Taylor wrote:
> If you can, the best way to overload existing library
> functionality in an extension is to 1) establish a one-way dependency
> between the libraries (a LibXMI target for LibGWT), and B) overload the
> existing XMI API hooked functions from the XMI private struct of the
> ggi_visual in question with your own 'wrapper' functions, taken from the
> XMI target code. The wrappers then apply transformations, clipping, etc.
> as appropriate for a windowed environment, and then they call down to the
> original XMI API routines.
When you say "a LibXMI target for LibGWT", do you mean:
1) a new LibGWT-aware display target inside LibXMI ?
or: 2) a new LibXMI-specific display target inside LibGWT ?
I really think you meant 1), but I want to make sure.
> This way you get the same encapsulation result as with your
> gwtmiDrawXYZ() wrappers above, but you do not have to change the function
> name or rewrite any code. There are no 'LibGWT drawing routines', only
> LibGWT-enabled versions of existing drawing routines in other libraries.
That's the next path I want to follow with LibGWT. However, before
spreading code throughout (all) other libraries, I wanted to have the
functionality tested in a separate piece of software -- hence my use of
a conventional C library framework.
Furthermore, I think there are two design paths that can be taken for
LibGWT "drawing functions" -- and for this also I'd like to have advice
from foreign eyes:
A- either implement LibGWT-specific display target in other libraries
(e.g. LibXMI, but also LibGGI -- e.g. wrt ggiFlush()). But this would
sort-of pollute these libraries and I don't know if it would be harmless.
B- either implement a more complex framework within LibGWT where, when
LibGWT is attached to a visual, it manipulates the internal operations of
the visual to replace them with its own wrappers.
The two approaches are intrusive wrt. the other libraries. The main
difference between the two approaches is _how_ the intrusion takes
place: either in the source code, or at runtime.
It seems to me that A) is easier to do. For B) I'd need some help from the
dynamic-loading wizards... ;-) B) may have other nice characteristics
(such as the ability to use generic implementations of the wrappers). But
I'd rather go the A) way (given my personal knowledge of the extension
libraries framework of LibGGI -- which is not so good after all).
Of course, I'd like to know the opinion of the maintainer/designers of the
other libraries before asking them to (let me) create new display
targets... After all, one does not always like the way windows blindly
limitate the freedom of big polygons with dictatory clipping... :-))
Rodolphe
