On Wed, 13 Jun 2001, Andreas Beck wrote:
> I assume you will add a few functions/macros making use of the new split
> functionality to LibGGI as well ?
Actually so far I took the easy way out on that, I simply implemented
the trivial ggiDetachInput and a macro ggiGetInput to take the place of
the slightly less-than-well-documented NULL argument to ggiJoinInputs,
respectively.
Once the inputs are free of the visual they can be split if needed
with the gii function... but for your use I beleive that will give you
an API-legal way to set the visual pointers to NULL, ergo accomplishing
what you were doing anyway.
I'll send a patch for that after I've got the cruft I've built up trying
to fix various things cleaned out of my tree.
As far as supplying a ggiSplitInput I haven't decided if the hairiness
is worth it...the problem being if you split an input and it is
the first input in the joined input, then you have managed to lose the
input handles of the rest in the batch -- all the other visuals
that have that handle are now pointing at that single split input.
We'd have to change internal handling somehow to fix that by
actually swapping the contents of one of the other inputs into the
shared handle's structure and handing back a different handle.
...but now on second thought, that would decrease the complexity of
the giiSplitInput API docs, as well.... Hmm...
Also we don't have a way to query the origin field so you actually
have something to feed giiSplitInputs other than taking the value from
a received event.
--
Brian
