Completed extending of mouse buttons to the system's limit; defined (as undefined) the mouse drag behavior for buttons >= 3; implemented all that on the GTK+ side, and decided to have MouseEvents.Held[] be sorted (documentation only for now; need to check the code to make sure it follows). Good Lord...

1 files changed, 2 insertions, 6 deletions

diff --git a/todo.md b/todo.md
index 440310b..4c06a24 100644
--- a/todo.md
+++ b/todo.md
@@ -13,12 +13,8 @@ super ultra important things:
 - OS X: handle Insert/Help key change in a sane and deterministic way
 	- will need old and new Mac keyboards...
 - make sure MouseEvent's documentation has dragging described correctly (both Windows and GTK+ do)
-	- fix OS X so that it follows these rules
-	- native Windows (not wine) and OS X don't respond to mouse button 4 and 5 drags?!
- [16:45] <JeffLaptop> no, just tried, and the navigation buttons don't.
- [16:45] <andlabs> ok, thanks a lot
- [16:45] <JeffLaptop> only the l, m, and r ones do.
-		- oh...
+	- figure out what to do about dragging into or out of a window; will likely need to be undefined as well...
+- double-check to make sure MouseEvent.Held[] is sorted on all platforms
 - cap click count to 2 on all platforms
 - 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