Master issue for missing features in uiArea

[andlabs]

Merging a bunch of issues here.

• [ ] Support for trackpad gestures (see #81 for details)
• [ ] Independent control of uIArea sizing in both horizontal and vertical directions (to allow areas to be scrollable in only one direction, for instance) (see #82 and linked issues for details)
• [ ] uiAreaSetMinSize() to determine the minimum allowable size of a uiArea for the minimum size of container size allocations; will also need to be axis-dependent
• [ ] uiAreaQueueRedraw() for only a specific part of a uiArea
• [ ] Un-expose unconditional redraw of a uiArea on window resize; fine-tune redrawing after resize as needed (see #251 for details)
• [ ] Related to the previous one: properly implement clipping on Windows (TODO get relevant stackoverflow questions I asked on the matter)
• [ ] Allow keyboard event handlers to know what the key on the keyboard is from the user's perspective (so on a dvorak keyboard, when pressing U, Key will still be 'f' but this new field would be 'u') — but this must be clearly marked as only for the purposes of user interaction, NOT FOR TEXT INPUT (and I have to remember a good reason why; TODO)
• [ ] Having controls overlaid on top of uiAreas; will need to decide how many can be done and figure out how they could or should interact with scrolling and sizing

[mischnic]

but this must be clearly marked as only for the purposes of user interaction, NOT FOR TEXT INPUT (and I have to remember a good reason why; TODO)

Would shift + a key be properly parsed as well (e.g. capital letters, punctuation mark)?

[andlabs]

It should, yes.

[msink]

On Linux if Area set as direct child of Window - it is 1 pixel width, on Windows - fills entire Window.

Well, sorry, there already is #207 for this issue.

[mischnic]

• mousewheel/scroll event in non-scrolling areas
  • https://developer.apple.com/documentation/appkit/nsresponder/1534192-scrollwheel?language=objc

[AndyObtiva]

I noticed that when hooking a key event to area, and I press shift+1 to produce '!', the key value I receive from area key event is that of number 1 (49), not the '!' key value (33) produced by shift+1. This means that in order for me to recognize what character the user intended, I would have to access the current keyboard layout and perform a conversion, which is not something that is typically available in Ruby as far as I know. I think this must be done automatically by libui, giving me the key value for '!' not 1 when I press shift+1.

The SWT library handles this by offering an additional attribute "character" in its key event, which in the case of the example above is the calculated character from holding shift and pressing a key (they still provide the standard key value as well, meaning for shift+1, I get key value as 49 and character as 33 in SWT)

This would be great to add to facilitate fully manual manipulation of user key input should I want to build a string from user input.

Thanks.