summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPietro Gagliardi <[email protected]>2014-04-07 12:49:23 -0400
committerPietro Gagliardi <[email protected]>2014-04-07 12:49:23 -0400
commit14bb9e3621ebb7839f1542510289e6b9035dce64 (patch)
treeb88a97bf0025d3e714c8c7538db73ff419540c68
parent24d40fa12d184ebd595344c5c1775d0175a2f4d1 (diff)
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).
-rw-r--r--futureplans.md4
-rw-r--r--todo.md15
2 files changed, 4 insertions, 15 deletions
diff --git a/futureplans.md b/futureplans.md
index dc38485..768cfb8 100644
--- a/futureplans.md
+++ b/futureplans.md
@@ -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)
diff --git a/todo.md b/todo.md
index 8f560ad..e1a327b 100644
--- a/todo.md
+++ b/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