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

7.0 KiB
Raw Blame History

important things:

super ultra important things:

  • 10.6 also spits a bunch of NSNoAutoreleasePool() debug log messages even though I thoguht I had everything in an NSAutoreleasePool...
  • formalize what happens if Modifiers by themselves are held
    • OS X: find out if multiple DIFFERENT modifiers released at once produces multiple events
      • yes it does
    • in general, figure out what to do on multiple events, period
    • current behavior:
      • Windows (TODO verify): no modifier release unless one modifier is released while another is still held; I think this can be overcome
      • Unix: all modifiers send press AND release events; left+right sends two events; release mask == pressed keys | released button
      • Mac OS X: all modifiers send press AND release events; left+right sends TODO; release mask == pressed keys &^ released button
      • ideally we would want modifiers to behave like Up and Down: if a modifier was pressed or released, have a field Modifier that indicates which modifier was pressed, then use the Modifiers field to indicate which modifiers are currently held
        • but then we would need to figure out how to deal with the fact that there's left and right and we choose not to differentiate (and because Windows doesn't report two Shift keys being released at once, according to GLFW)
        • also this makes Modifiers different from everything else... maybe I should drop the Modifiers as a bitmask thing???? Or have Modifiers be the flags if Up and Down are nonzero and an individual bit otherwise? This sounds the most reasonable...
    • OS X: the behavior of Modifiers and other keys is broken: keyDown:/keyUp: events stop being sent when the state of Modifiers changes, which is NOT what we want

      • [13:44] pietro10: nope, the system decides

        • welp; this changes everything
  • OS X: handle Insert/Help key change in a sane and deterministic way
    • will need old and new Mac keyboards...
  • make sure MouseEvent's documentation has dragging described correctly (both Windows and GTK+ do)
  • pin down whether or not a click event gets sent if this click changes from a different window to the one with the Area
  • double-check to make sure MouseEvent.Held[] is sorted on Unix after we figure out how to detect buttons above button 5
  • the windows build appears to be unstable:
    • 64-bit crashes in malloc in wine with heap corruption warnings aplenty during DLL loading; in windows 7 it works fine
    • 32-bit: it works, but if I save the class name converted to UTF-16 beforehand, wine indicates that the class name is replaced with the window title, so something there is wrong...
  • david wendt is telling me he's getting frequent crashes on his end with the GTK+ amd64 build... TODO re-evaluate; I think I fixed them all ages ago now
  • GTK+: stderr is flooded with
(test:17575): Gdk-CRITICAL **: gdk_device_ungrab: assertion 'GDK_IS_DEVICE (device)' failed

(test:17575): Gtk-CRITICAL **: gtk_device_grab_remove: assertion 'GDK_IS_DEVICE (device)' failed

figure out why
  • make sure the preferred size of a Listbox is the minimum size needed to display everything on all platforms (capped at the screen height, of course?)
    • same for Area, using the Area's size (this will be easier)
  • make sure the image drawn on an Area looks correct on all platforms (is not cropped incorrectly or blurred)
  • when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (comboboxes will just cut off; the horizontal scrollbar in Area will disappear smoothly; etc.)
    • check my logs; someone in irc.gimp.net/#gtk+ answered this (or provided an answer)
  • see update 18 March 2014 in README
  • resizing seems to be completely and totally broken in the Wayland backend
    • TODO find out if this is a problem on the GTK+/Wayland side (no initial window-configure event?)
  • redrawing controls after a window resize on Windows does not work properly
  • point out that Areas get keyboard focus automatically on click on Mac OS X
  • make sure Areas get keyboard focus when clicking outside the actual Area space on all platforms
  • make sure keyboard events on numpad off on all platforms don't switch between controls
  • 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 choppy: make sure the speed we have now is the conventional speed for GTK+ programs (HIG doesn't list any) and that the choppiness is correct
  • Message boxes are not application-modal on some platforms
  • [12:55] pietro10: I meant to mention: 1073): Gtk-WARNING **: Theme parsing error: gtk.css:72:20: Not using units is deprecated. Assuming 'px'. twice.

other things: