20,741
edits
Canvas widgets: Difference between revisions
Jump to navigation
Jump to search
→Keyboard Handling {{Feedback}}
| Line 160: | Line 160: | ||
The values are only valid for one single window (coordinates are relative to window origin). | The values are only valid for one single window (coordinates are relative to window origin). | ||
=== Keyboard Handling {{Feedback}} | === Keyboard Handling === | ||
{{Feedback}} | |||
James was definitely right regarding osgGA: UI processing is really simplified compared to PUI. | James was definitely right regarding osgGA: UI processing is really simplified compared to PUI. | ||
| Line 176: | Line 177: | ||
BTW: There is already a property to toggle the mouse cursor via setprop, so this could also be wrapped in gui.nas, obviously being able to use a canvas texture as the cursor would prove the point that "everything is a canvas" in the design. | BTW: There is already a property to toggle the mouse cursor via setprop, so this could also be wrapped in gui.nas, obviously being able to use a canvas texture as the cursor would prove the point that "everything is a canvas" in the design. | ||
I was looking through our earlier discussions, and how osgGA can be used for keyboard support. | |||
And like I mentioned, I think it would make sense to adopt the same approach that you used for mouse support here. | |||
Overall, I feel it would make sense to closely model this after the way this is handled in Java, i.e. using the same "property events" that are supported in Java for mouse/keyboad and "windows" - just specific to canvas textures, instead of just "windows". | |||
So instead of "window" events, we'd have "texture" events, so that these can also be used for non-GUI purposes, such as instruments | |||
Looking at our last discussion on forwarding mouse events to nested canvases, it would then really make sense to also have "window/texture" events (create, update, redraw, resize, move etc). So that we don't need to add any C++ code for such things. | |||
And by having "high level" events such as "mouse-enter", "mouse-leave" or "texture-resize", "texture-moved", "has-focus","lost-focus" etc, it would be very simple to implement MFDs and GUI widgets in Nasal without requiring C++ workarounds. | |||
So it's really just about supporting 10-15 event types in the C++ code which set some properties, so that the rest can be implemented in Nasal. | |||
Obviously, some events would be texture specific, while others would be specific to groups or elements and should probably be forwarded, like you suggested earlier. | |||
And then it'd be very close to how this is handled in Java, because we could use conventional Nasal listener callbacks to model the details in scripting space. | |||
Specialized widgets could then use these events to implement widget-specific events, i.e. for list view, tree views or other complex widgets - but these could then be implemented in Nasal. | |||
=== Multiplatform Clipboard Support (native Copy/Paste) === | === Multiplatform Clipboard Support (native Copy/Paste) === | ||