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

More TODOs (and some done TODO elimination).

This commit is contained in:
Pietro Gagliardi 2014-03-25 07:21:21 -04:00
parent 3c0bcb6d68
commit 136f2262fd
2 changed files with 3 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
area_windows.go
View File

@ -139,14 +139,10 @@ func paintArea(s *sysData) {
uintptr(unsafe.Pointer(&ps))) uintptr(unsafe.Pointer(&ps)))
} }
var (
_getWindowRect = user32.NewProc("GetWindowRect")
)
func getAreaControlSize(hwnd _HWND) (width int, height int) { func getAreaControlSize(hwnd _HWND) (width int, height int) {
var rect _RECT var rect _RECT
r1, _, err := _getWindowRect.Call( r1, _, err := _getClientRect.Call(
uintptr(hwnd), uintptr(hwnd),
uintptr(unsafe.Pointer(&rect))) uintptr(unsafe.Pointer(&rect)))
if r1 == 0 { // failure if r1 == 0 { // failure
@ -222,6 +218,7 @@ func scrollArea(hwnd _HWND, wparam _WPARAM, which uintptr) {
uintptr(hwnd), uintptr(hwnd),
which, which,
uintptr(unsafe.Pointer(&si))) uintptr(unsafe.Pointer(&si)))
// TODO in some cases wine will show a thumb one pixel away from the advance arrow button if going to the end; the values are correct though... weirdness in wine or something I never noticed about Windows?
} }
func adjustAreaScrollbars(hwnd _HWND) { func adjustAreaScrollbars(hwnd _HWND) {

2
todo.md
View File

@ -74,11 +74,11 @@ super ultra important things:
- 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 - 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 - 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
- make sure the image drawn on an Area looks correct on all platforms (is not cropped incorrectly or blurred) - make sure the image drawn on an Area looks correct on all platforms (is not cropped incorrectly or blurred)
- GTK+: requested clip rect seems to be larger than the size of the Area (also larger than the visible portion? TODO)
- when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (progress bars/entry lines will just cut off; editable comboboxes will stretch slightly longer than noneditable ones; the horizontal scrollbar in Area will disappear smoothly; etc.) - when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (progress bars/entry lines will just cut off; editable comboboxes will stretch slightly longer than noneditable ones; the horizontal scrollbar in Area will disappear smoothly; etc.)
- the window background of a GTK+ window seems to be... off - I think it has to do with the GtkLayout - 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 - see update 18 March 2014 in README
- resizing seems to be completely and totally broken in the Wayland backend - resizing seems to be completely and totally broken in the Wayland backend
- scrolling Areas in wine by clicking in the page scroll area often causes the main thread to lock up; uitask does not
important things: important things:
- make specific wording in documentation consistent (make/create, etc.) - make specific wording in documentation consistent (make/create, etc.)