interesting
/
andlabs-ui
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Finished the Area clicking stuff: formalized the behavior in documentation in area.go, pointed out that Mac OS X already behaves as expected, updated some comments, and removed the relevant TODO.

This commit is contained in:
Pietro Gagliardi 2014-05-23 23:48:17 -04:00
parent f4afa2a951
commit 511f774649
4 changed files with 4 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
area.go
View File

@ -94,9 +94,8 @@ type MouseEvent struct {
// Down and Up shall not both be nonzero. // Down and Up shall not both be nonzero.
Up uint Up uint
// If Down is nonzero, Count indicates the number of clicks: 1 for single-click, 2 for double-click. // If Down is nonzero, Count indicates the number of clicks: 1 for single-click, 2 for double-click, 3 for triple-click, and so on.
// If Count == 2, AT LEAST zero events with Count == 1 will have been sent prior. // The order of events will be Down:Count=1 -> Up -> Down:Count=2 -> Up -> Down:Count=3 -> Up -> ...
// (This is a platform-specific issue: some platforms send none, some send one, and some send two.)
Count uint Count uint
// Modifiers is a bit mask indicating the modifier keys being held during the event. // Modifiers is a bit mask indicating the modifier keys being held during the event.

1
area_darwin.go
View File

@ -86,6 +86,7 @@ func areaMouseEvent(self C.id, e C.id, click bool, up bool) {
me.Up = which me.Up = which
} else if click { } else if click {
me.Down = which me.Down = which
// this already works the way we want it to so nothing special needed like with Windows and GTK+
me.Count = uint(C.clickCount(e)) me.Count = uint(C.clickCount(e))
} else { } else {
which = 0 // reset for Held processing below which = 0 // reset for Held processing below

2
events_notdarwin.go
View File

@ -16,7 +16,7 @@ For GTK+, we pull the double-click time and double-click distance, which work th
On GTK+ this will also allow us to discard the GDK_BUTTON_2PRESS and GDK_BUTTON_3PRESS events, so the button press stream will be just like on other platforms. On GTK+ this will also allow us to discard the GDK_BUTTON_2PRESS and GDK_BUTTON_3PRESS events, so the button press stream will be just like on other platforms.
Thanks to mclasen, garnacho_, and halfline in irc.gimp.net/#gtk+. Thanks to mclasen, garnacho_, halfline, and tristan in irc.gimp.net/#gtk+.
TODO - technically a GDK_BUTTON_3PRESS is detected in half the time as a GDK_BUTTON_2PRESS... handle? TODO - technically a GDK_BUTTON_3PRESS is detected in half the time as a GDK_BUTTON_2PRESS... handle?
*/ */

6
todo.md
View File

@ -26,12 +26,6 @@ super ultra important things:
- make sure MouseEvent's documentation has dragging described correctly (both Windows and GTK+ do) - make sure MouseEvent's documentation has dragging described correctly (both Windows and GTK+ do)
- pin down whether or not a click event gets sent if this click changes from a different window to the one with the Area - pin down whether or not a click event gets sent if this click changes from a different window to the one with the Area
- double-check to make sure MouseEvent.Held[] is sorted on Unix after we figure out how to detect buttons above button 5 - double-check to make sure MouseEvent.Held[] is sorted on Unix after we figure out how to detect buttons above button 5
- cap click count to 2 on all platforms? or normalize higher order clicks...
- Windows: down up doubledown up
- triple-clicks and higher: http://blogs.msdn.com/b/oldnewthing/archive/2004/10/18/243925.aspx have to do it ourselves, but Microsoft provides everything we need to
- Unix: down up down doubledown up [down doubeldown tripledown up]
- TODO higher than triple-click?
- Mac OS X: down up doubledown up tripledown up 4down up...
- the windows build appears to be unstable: - 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 - 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... - 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...