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:
parent
24d40fa12d
commit
14bb9e3621
|
@ -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
15
todo.md
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue