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

This commit is contained in:
Pietro Gagliardi 2014-04-29 12:54:15 -04:00
parent f19db96c4e
commit a98072a23b
2 changed files with 2 additions and 2 deletions

View File

@ -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?

View File

@ -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...