Split the todo.md file into one for immediate TODOs and one for future work; merged the latter with controlcandidates.md to form a single future stuff list. Also cleaned up all those lists.

This commit is contained in:
Pietro Gagliardi 2014-04-05 19:38:35 -04:00
parent dc96a73c2f
commit 3d04200e8d
2 changed files with 66 additions and 51 deletions

View File

@ -1,3 +1,57 @@
general list:
- Window.SizeToFit() or WIndow.OptimalSize() (use: `Window.SetOptimalSize())`) for sizing a window to the control's interest
- with the current code, will be a bit of a kludge, because preferredSize() assumes it's running on the main thread without locks
- Control.Show()/Control.Hide()
- Groupbox
- character-limited entry fields (not for passwords), numeric entry fields, multiline entry fields
- possible rename of LineEdit?
- especially for password fields - NewPasswordEntry()?
- padding and spacing in Stack
- allow Combobox to have initial settings
- Combobox and Listbox insertions and deletions should allow bulk (...string/...int)
- Combobox/Listbox.DeleteAll
- Combobox/Listbox.Select (with Listbox.Select allowing bulk)
- Checkbox.Check or Checkbox.SetChecked
- Listbox.SelectAll
- Listbox/Combobox.Index(n)
- Index(n) is the name used by reflect.Value; use a different one?
- figure out where to auto-place windows in Cocoa (also window coordinates are still not flipped properly so (0,0) on screen is the bottom-left)
- also provide a method to center windows; Cocoa provides one for us but
- make Combobox and Listbox satisfy sort.Interface?
- 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
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?))
- make sure GTK+ documentation version point differences (x in 4.3.x) don't matter
- I found a GTK+ version number meaning page somewhere; have to find it again (TODO)
twists of fate:
- listboxes spanning the vertical height of the window don't always align with the bottom border of the edit control attached to the bottom of the window...
- this specifically only happens when the window has an odd height; I don't think this can be fixed unless we explicitly ignore the extra pixel everywhere
- need a way to get ideal size for all controls on Windows, not just push buttons (Microsoft...)
style changes:
- make specific wording in documentation consistent (make/create, etc.)
- document minor details like wha thappens on specific events so that they are guaranteed to work the same on all platforms (are there any left?)
- 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
- 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)
- areaView -> goArea (or change the class name to be like the delegate name?) in area_darwin.go?
far off:
- localization
- strip unused constants from the Windows files
- combine more Windows files; rename some?
- tab stops
- rename Stack to Box?
specifics:
WINDOWS
- DateTime Picker
- ListView for Tables
@ -18,6 +72,7 @@ WINDOWS
- commcntl.h has stuff on a font control that isn't documented?
- actually not a control, but localization support: http://msdn.microsoft.com/en-us/library/windows/desktop/bb775454%28v=vs.85%29.aspx
- notes to self:
- groupbox is a mode of the BUTTON class (????)
- OpenGL: http://msdn.microsoft.com/en-us/library/windows/desktop/dd374379%28v=vs.85%29.aspx
- don't use ES_NUMBER for number-only text boxes, as "it is still possible to paste non-digits into the edit control." (though a commenter on MSDN says that's wrong?)
- might want to just have spinners and not numeric text boxes???

62
todo.md
View File

@ -1,23 +1,8 @@
so I don't forget:
- Window.SizeToFit() or WIndow.OptimalSize() (use: `Window.SetOptimalSize())`) for sizing a window to the control's interest
- Control.Show()/Control.Hide()
- Groupbox
- character-limited entry fields, numeric entry fields, multiline entry fields
- possible rename of LineEdit?
- especially for password fields - NewPasswordEntry()?
- [all platforms except Windows] Listbox should have a border style
- padding and spacing in Stack
- allow Combobox to have initial settings
- Combobox and Listbox insertions and deletions should allow bulk (...string)
- Combobox/Listbox.DeleteAll
- Combobox/Listbox.Select (with Listbox.Select allowing bulk)
- Checkbox.Check or Checkbox.SetChecked
- Listbox.SelectAll
- should Labels be selectable?
- should message box text be selectable on all platforms or only on those that make it the default?
- Listbox/Combobox.Index(n)
- Index(n) is the name used by reflect.Value; use a different one?
- Message boxes should not show secondary text if none is specified.
- Message boxes should not show secondary text if none is specified. [TODO figure out what I meant by this]
- note that you can change event channels before opening the window; this allows unifying menus/toolbars/etc.
- will probably want to bring back Event() for this (but as NewEvent())
- add bounds checking to Area's sizing methods
@ -25,24 +10,21 @@ so I don't forget:
- should all instances of -1 as error returns from Windows functions be changed to ^0 or does the uintptr() conversion handle sign extension?
important things:
- 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?))
- figure out where to auto-place windows in Cocoa (also window coordinates are still not flipped properly so (0,0) on screen is the bottom-left)
- also provide a method to center windows; Cocoa provides one for us but
- I think Cocoa listbox item text is too low?
- NSPopUpButton does allow no initial selection ([b setSelectedIndex:-1]); use it
- need to use it /after/ adding initial items, otherwise it won't work
- find out if I can do the same with the ListBoxes
- NSComboBox scans the entered text to see if it matches one of the items and returns the index of that item if it does; find out how to suppress this so that it returns -1 unless the item was chosen from the list (like the other platforms)
- some Cocoa controls don't seem to resize correctly: Buttons have space around the edges
- make sure GTK+ documentation version point differences (x in 4.3.x) don't matter
- LineEdit heights on Windows seem too big; either that or LineEdit, Button, and Label text is not vertically centered properly
- are Checkboxes and Comboboxes too small?
- Cocoa has similar margining issues (like Comboboxes having margins)
- sometimes the size of the drop-down part of a Combobox becomes 0 or 1 or some other impossibly small value on Windows
- make gcc (Unix)/clang (Mac OS X) pedantic about warnings/errors; also -Werror
- problem: cgo-generated files trip -Werror up; I can't seem to turn off unused argument warnings with the -Wall/-Wextra/-pedantic options
- make sure scrollbars in Listbox work identically on all platforms (specifically the existence and autohiding of both horizontal and vertical scrollbars)
- pin down this behavior; also note non-editability
- listboxes spanning the vertical height of the window don't always align with the bottom border of the edit control attached to the bottom of the window...
- I think the behavior is, for the most part, a platform detail; perhaps a better option is to simply dictate the autohiding of scrollbars for both Listbox and Area (this will also let us consolidate scroll view code in GTK+ and Mac OS X)
- make sure mouse events don't trigger if the control size is larger than the Area size and the mouse event happens outside the Area range on all platforms
- area test time label weirdness
- does not show anything past the date on windows
@ -83,45 +65,23 @@ super ultra important things:
- the window background of a GTK+ window seems to be... off - I think it has to do with the GtkLayout
- see update 18 March 2014 in README
- resizing seems to be completely and totally broken in the Wayland backend
- redrawing Areas on Windows seems to be flaky: make the window small, scroll, then make it large again and watch the vertical corruption
- TODO find out if this is a problem on the GTK+/Wayland side (no initial window-configure event?)
- redrawing Areas on Windows seems to be flaky: make the window small, scroll, then make it large again and watch the vertical corruption (alternatively "especially after changing the Area size to something larger than the window size and then resizing the window(???)")
- redrawing controls after a window resize on Windows seems to be flaky
- make sure the first and last rows and columns of an Area are being drawn on Windows
- make sure the first and last rows and columns of an Area are being drawn on all platforms
- clicking on Areas in GTK+ don't bring keyboard focus to them?
- make sure GTK+ keyboard events on numpad off don't switch between controls
- for our two custom window classes, we should allocate extra space in the window class's info structure and then use SetWindowLongPtrW() during WM_CREATE to store the sysData and not have to make a new window class each time; this might also fix the s != nil && s.hwnd != 0 special cases in the Area WndProc if done right
- make sure keyboard events on numpad off on all platforms don't switch between controls
- for our two custom window classes on Windows, we should allocate extra space in the window class's info structure and then use SetWindowLongPtrW() during WM_CREATE to store the sysData and not have to make a new window class each time; this might also fix the s != nil && s.hwnd != 0 special cases in the Area WndProc if done right
- references: https://github.com/glfw/glfw/blob/master/src/win32_window.c#L182, http://www.catch22.net/tuts/custom-controls
- Area redraw on Windows is still a bit flaky, especially after changing the Area size to something larger than the window size and then resizing the window(???)
- this is a bit flakier as SetWindowLongPtr() can fail, and it can also succeed in such a way that the last error is unreliable
- despite us explicitly clearing the clip area on Windows, Area still doesn't seem to draw alpha bits correctly... it appears as if we are drawing over the existing image each time
- on Windows, Shift+(num pad key) triggers the shifted key code when num lock is off; will need to reorder key code tests on all platforms to fix this
- pressing global keycodes (including kwin's zoom in/out) when running the keyboard test in wine causes the Area to lose keyboard focus; this doesn't happen on the GTK+ version (fix the Windows version to behave like the GTK+ version)
- GTK+ indefinite progress bar animation is too fast; HIG doesn't list a preferred speed?
- Message boxes are not application-modal on some platforms
- cast all objc_msgSend() direct invocations to the approrpiate types; this is how you're supposed to do things: https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html http://lists.apple.com/archives/objc-language/2014/Jan/msg00011.html http://lists.apple.com/archives/cocoa-dev/2006/Feb/msg00753.html and many others
important things:
- make specific wording in documentation consistent (make/create, etc.)
- document minor details like wha thappens on specific events so that they are guaranteed to work the same on all platforms (are there any left?)
- what happens when the user clicks and drags on a listbox
- should field descriptions in method comments include the receiver name? (for instance e.Held vs. Held) - see what Go's own documentation does
- 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)
other things:
- on windows 7, progress bars seem to animate from 0 -> pos when you turn off marquee mode and set pos; see if that's documented or if I'm doing something wrong
- clean up windows struct field names (holdover from when the intent was to make a wrapper lib first and then use it rather than using the windows API directly)
- make all widths and heights parameters in constructors in the same place (or drop the ones in Window entirely?)
far off:
- localization
- strip unused constants from the Windows files
- combine more Windows files; rename some?
- tab stops
maybe:
- rename Stack to Box?
- make Combobox and Listbox satisfy sort.Interface?
- 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 focus
- provide an event for leaving focus so a focus rectangle can be drawn
- change the Windows code to use extra class space (as in http://www.catch22.net/tuts/custom-controls)
- this is a bit flakier as SetWindowLongPtr() can fail, and it can also succeed in such a way that the last error is unreliable
- need a way to get ideal size for all controls on Windows, not just push buttons (Microsoft...)
- cast all objc_msgSend() direct invocations to the approrpiate types; this is how you're supposed to do things (TODO get Apple mailing list excerpt saying this)