Decided not to cap mouse buttons at 3; reflected this in the public interface and in the TODO file. Platform implementations come next.

2 files changed, 2 insertions, 2 deletions

diff --git a/area.go b/area.go
index 0fc33d2..4fca39a 100644
--- a/area.go
+++ b/area.go
@@ -72,7 +72,8 @@ type AreaHandler interface {
 
 // MouseEvent contains all the information for a mous event sent by Area.Mouse.
 // Mouse button IDs start at 1, with 1 being the left mouse button, 2 being the middle mouse button, and 3 being the right mouse button.
-// (TODO "If additional buttons are supported, they will be returned with 4 being the first additional button (XBUTTON1 on Windows), 5 being the second (XBUTTON2 on Windows), and so on."?) (TODO get the user-facing name for XBUTTON1/2; find out if there's a way to query available button count)
+// If additional buttons are supported, they will be returned with 4 being the first additional button. The association between button numbers and physical buttons are system-defined.
+// (TODO find out if there's a way to query available button count)
 type MouseEvent struct {
 	// Pos is the position of the mouse in the Area at the time of the event.
 	// TODO rename to Pt or Point?
diff --git a/todo.md b/todo.md
index 8dbed53..41d99ae 100644
--- a/todo.md
+++ b/todo.md
@@ -15,7 +15,6 @@ super ultra important things:
 - make sure MouseEvent's documentation has dragging described correctly (both Windows and GTK+ do)
 	- fix OS X so that it follows these rules
 - cap click count to 2 on all platforms
-	- cap mouse button count to 3? or should a function be used instead?
 - the windows build appears to be unstable:
 	- 64-bit crashes in malloc in wine with heap corruption warnings aplenty during DLL loading; in windows 7 it works fine
 	- 32-bit: it works, but if I save the class name converted to UTF-16 beforehand, wine indicates that the class name is replaced with the window title, so something there is wrong...