From: Brian S. Julin <bri@tull.umassp.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Jun 1999 02:15:34 -0400 (EDT)

GII nitpicks

Barring any intrusion by the "real world" expect a GII:: perl5 XS module 
set tomorrow evening my time.  I really don't care much about input 
handling personally, but wanted the modules done right as perl may be 
a great language but doesn't always promote great code :-}.  Some
people even seem to forget it's OO.  Anyway I can't believe I spent so much
time writing this just so I could subclass GGI:: objects under it on
mere principle :)

So, I need someone very familiar with LibGII and somewhat Perl literate 
to run it into the ground and find the bugs, and to write the source 
tree test suite which is pretty basic at the moment.

This was the first time I really looked at LibGII hard, and
I have come up with a couple of nitpicks with the GII API.

1) The order of the h,w members of gii_expose_event is 
counterintuitive.  Not worth breaking binary compatibility 
over of course.  (Perhaps we should decide what version bump of
GGI/GII is going to break binary compatibility beforehand and
then we could add #if directives to implement the change 
when we bump the version, then take them out at our leisure.  That
way noone has to keep a big list of trivial unimportant changes.)

2) There should be an evPtrButtonRepeat event.  For two reasons.
One is that Vojtech's new input drivers implement soft repeat for
mice buttons.  The other reason pertains to press-and-hold 
functions e.g. the way MAC OS lets you edit the filename on an icon.
Apps wanting this type of interface can just wait for N repeat events.
This gives the user a system wide way to configure the mouse
press-and-hold "responsiveness" by setting the mouse repeat rate.
This would typically be on the order of > 0.5 seconds so it wouldn't
cause a flood of events.

3) Not sure I like the fact that a joined input effectively 
destroys the old event handles, but I've a workaround.  Seems
a bit tacky, though.

4) Default quit handler on CTRL-C for would be nice if it could
be made to gracefully get out of the way of non-newbies and their
signal/event handlers.

Couple other questions:

Under what normal (app, not library) circumstances would one call
g(g|i)iInit() more than once?  Currently my modules call it when the
package is use()d, but if there's a reason to offer calling it again
in the Perl5 API I want to.

Is the #if 0'd filter stuff on the way in, or on the way out?
Docs available anywhere if the former?

P.S.  Oh, Vojtech's softrepeat code I believe has hooks for setting
repeat rates on individual keys/buttons; somone may want to standardize a set
of commands to deal with this.  Also, is there a standard way to tell
an input driver to switch to using valuator events and drop the 
prefab Ptr events, JOOC?

--
Brian S. Julin