On Mon, 1 May 2000, Rodolphe Ortalo wrote:
> 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.
I meant 2 when I wrote that, but now I see that it must be 1,
because LibGWT will probably be loaded before LibXMI.
> > 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.
Gotcha.
> 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.
Yeah. Doing the dependencies Lib->GWT instead of GWT->Lib
requires the other libs to know about LibGWT, each with their own separate
targets to slip out of sync with the LibGWT API |-/. It would be a lot
nicer if the other libs didn't have to know a thing about LibGWT, and all
the wrapper code for each library could be placed into LibGWT targets.
Nice and centralized. Lib->GWT _works_, but it sure is messy....
> 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.
That is what I had in mind. But you still have to write the
wrapper code, it just goes into a GWT->Lib target instead of a Lib->GWT
target.
> The two approaches are intrusive wrt. the other libraries.
Yes, this is necessary, just as targets are 'intrusive' on the
stubs code for LibGGI. Overloading API calls at runtime is how LibGGI
works.
> The main
> difference between the two approaches is _how_ the intrusion takes
> place: either in the source code, or at runtime.
Runtime.
> It seems to me that A) is easier to do. For B) I'd need some help from the
> dynamic-loading wizards... ;-)
It should be doable. At gwtInit() time, walk the visual's list of
already-attached extensions and load a set of targets to match. Each
target will find the visual private data struct for its extension and
overload the functions pointers it finds there.
> 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).
Well, it is up to you. But I really think B is the way to go, in
the long term at least.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
