Been doing some heavy UI work, and Here are a few quirks/bugs I've found:
1) keyboard_get_frame and associated methods don't work in fullscreen, except in portrait, and only the view was started in portrait. In landscape, or if device is rotated, we get bad values.
Here is a sequence dumping out keyboard frame starting in portrait, and rotating clockwise
start portrait
kb frame ... = (0.0, 760.0, 768.0, 264.0) correct
kb frame ... = (416.0, 0.0, 352.0, 1024.0) maybe correct if x,y,w,h are really y,x,h,w
kb frame ... = (0.0, 0.0, 768.0, 264.0). Incorrect y
kb frame ... = (0.0, 0.0, 352.0, 1024.0) also incorrect
kb frame ... = (0.0, 760.0, 768.0, 264.0) correct again, original orientation
Next, I restarted in landscape, and repeated the test
start in landscape
kb frame ... = (416.0, 0.0, 352.0, 768.0) hmmm. That's not right, should be 1024 width
kb frame ... = (0.0, 0.0, 768.0, 264.0) nope...y is wrong
kb frame ... = (0.0, 0.0, 352.0, 768.0). Still wrong
kb frame ... = (0.0, 760.0, 768.0, 8.0). Nope
kb frame ... = (416.0, 0.0, 352.0, 768.0)
Things seem to work ok in sheet, panel, etc. but,
2) in sheet view, the view's frame property lies about the x,y position. I guess this is because the view cannot be repositioned, however, it makes it tricky to figure out where the keyboard frame is relative to the view.
3) callbacks like keyboard_frame_will_change continue to be called even after the view is closed. I'm not sure if this is a desirable situation, it can lead to funny situations that require restart ( an exception in the will change function ends up in and endless cycle that can't be fixed by going back to console, etc.
4) changing a views size within draw() can cause strange problems. Like it seems the drawing context is set to original bounds. The issue is that, since measure_string can only be called from within draw(), if I want to resize the view to hold the string, there is no way to do it.