gEDA-dev: PCB-gtk rotate tool bug?

[David Carr]

After some research, I think this is what happens:
When I click the mouse button rapidly, GTK begins to treat subsequent
clicks as double and triple clicks.

According to:
http://library.gnome.org/devel/gdk/unstable/gdk-Event-Structures.html#GdkEventButton

When GTK detects a double click it sends the following sequence of events:
GDK_BUTTON_PRESS
GDK_BUTTON_RELEASE
GDK_BUTTON_PRESS
GDK_2BUTTON_PRESS
GDK_BUTTON_RELEASE

The *PRESS events get routed to ghid_port_button_press_cb on line 528 of
gui-output-events.c.  This function appears to process button press events
and then passes the resultant actions along using hid_actionl().  This
function seems to assume that all button presses are of the
GDK_BUTTON_PRESS variety.  However, a few printfs have confirmed that the
GDK_2BUTTON_PRESS and GDK_3BUTTON_PRESS events are making it here as well.

So here is what I think happens:
First click - GDK_BUTTON_PRESS received (object rotates to 90)
Second click - GDK_BUTTON_PRESS received (object rotates to 180)
ALSO, during second click - GDK_2BUTTON_PRESS received (object rotates to
270 and user gets frustrated)

The good news is that this function is passed the GdkEventButton structure
which provides a field called type.  The type field will indicate whether
a given event is a GDK_BUTTON_PRESS, a GDK_2BUTTON_PRESS, or a
GDK_3BUTTON_PRESS.  As a quick fix, I added a couple lines that will cause
ghid_port_button_press_cb to swallow GDK_2BUTTON_PRESS and
GDK_3BUTTON_PRESS events.  When these events are ignored, it seems that
bug is no longer present.

I'm not sure if this solution is optimal, however because I don't know if
PCB actually uses any double click events.  If so, this might break them. 
Nonetheless, I think that we have identified the source of the problem.

Thanks for all your hard work on PCB and gEDA in general,
David Carr