Removed the TODOs about AppQuit: fixed on OS X, never a problem on Windows, unfixable elsewhere (these are window manager window-local(? apparently...) events so they never hit us; thanks to some people in irc.gimp.net/#gtk+). Also added some notes to the future plans document (related to all that).

This commit is contained in:
Pietro Gagliardi 2014-04-07 12:49:23 -04:00
parent 24d40fa12d
commit 14bb9e3621
2 changed files with 4 additions and 15 deletions

View File

@ -21,6 +21,9 @@ general list:
- should a noneditable Combobox be allowed to return to unselected mode by the user?
- provide a way for MouseEvent/KeyEvent to signal that the keypress caused the Area to gain/lose focus
- provide an event for leaving focus so a focus rectangle can be drawn
- when adding menus:
- provide automated About, Preferneces, and Quit that place these in the correct location
- Quit should pulse AppQuit
problem points:
- because the main event loop is not called if initialization fails, it is presently impossible for MsgBoxError() to work if UI initialization fails; this basically means we cannot allow initializiation to fail on Mac OS X if we want to be able to report UI init failures to the user with one (which would be desirable, maybe (would violate Windows HIG?))
@ -38,6 +41,7 @@ style changes:
- what happens when the user clicks and drags on a listbox
- I think this is a platform behavior...
- should field descriptions in method comments include the receiver name? (for instance e.Held vs. Held) - see what Go's own documentation does
- need to figure out exactly how to indicate that a struct{}{} is sent on an event channel (I use about six or so different wordings so far...)
- make passing of parameters and type conversions of parameters to uitask on Windows consistent: explicit _WPARAM(xxx)/_LPARAM(xxx)/uintptr(xxx), for example
- do this for type signatures in exported functions: (err error) or just error?
- do this for the names of GTK+ helper functions (gtkXXX or gXXX)

15
todo.md
View File

@ -52,21 +52,6 @@ super ultra important things:
```
figure out why
- I think it has to do with invalid list deletions; roll back the panics and check
- the user can still [NSApp terminate:] from the Dock icon, bypassing Go itself
- ideally we need a QuitItem() function for this case if/when we add menus
- check this on all platforms
- Mac OS X (64-bit): window:good dock:BYPASSED appmenu:(none default?) expose:TODO altF4:(unassigned) ctlQ:(unassigned by default; likely because of the appmenu lack of assignment)(kb:good otherwise)
- Mac OS X (32-bit): window:TODO dock:TODO appmenu:TODO expose:TODO altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- Windows XP: window:good taskbar:good taskmgr:good altF4:good(kb:good) ctlQ:(unassigned)
- Windows 7: window:good taskbar:good taskmgr:good altF4:good(kb:good) ctlQ:(unassigned)
- wine (KDE): window:good taskbar:good altF4:good(kb:TODO) ctlQ:(unassigned)
- KDE: window:good taskbar:good altF4:good(kb:TODO) ctlQ:(unassigned)
- Weston: window:TODO taskbar:TODO altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- GNOME Shell: window:good taskbar:good expose:good altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- MATE (for GNOME 2): window:TODO taskbar:TODO altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- xfce: window:good taskbar:good altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- Unity: window:good taskbar:good appmenu:(no default) altF4:good(kb:BYPASSED) ctlQ:(unassigned)
- LXDE: window:good taskbar:good altF4:TODO(kb:TODO) ctlQ:TODO(kb:TODO)
- Cocoa: NSScrollView support is hacky at best
- https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/NSScrollViewGuide/Articles/Creating.html#//apple_ref/doc/uid/TP40003226-SW4 the warning about pixel alignment may or may not be heeded, not sure
- frame sizes are a bit of a hack: the preferred size of a NSScrollView is the preferred size of its document view; the frameSize method described on the above link might be better but a real solution is optimal