20,741
edits
Canvas widgets: Difference between revisions
Jump to navigation
Jump to search
→Fully Canvas based implementation (in progress as of 08/2012)
| Line 94: | Line 94: | ||
=== C++ core requirements {{Pending}} === | === C++ core requirements {{Pending}} === | ||
{{Progressbar|40}} | |||
We will need the possibility to create dialog windows from Nasal space. The GUI system listens to a branch in the property tree (eg. /sim/gui/dialogs) and creates a window (=Textured Quad) for every child element (/sim/gui/dialogs/dialog[i]) which is created. Certain properties can be set to affect the appearance and behavior of the dialog: | We will need the possibility to create dialog windows from Nasal space. The GUI system listens to a branch in the property tree (eg. /sim/gui/dialogs) and creates a window (=Textured Quad) for every child element (/sim/gui/dialogs/dialog[i]) which is created. Certain properties can be set to affect the appearance and behavior of the dialog: | ||
| Line 112: | Line 112: | ||
=== Picking & Widget Callbacks {{Pending}} === | === Picking & Widget Callbacks {{Pending}} === | ||
{{Progressbar|40}} | |||
For mouse handling I like the idea of having event handlers (eg. click, drag, hover, etc.). So instead of just one property holding the events of the whole dialog/canvas I want to forward the event to the corresponding element by using picking or maybe for a first step just bounding box checking with the current mouse position. It would still just set the three properties like before (button, x, y) but we could add an helper function which adds a listener to the button property and calls a function with all three parameters if the event was triggered. (I always want to keep the basic idea of only communicatingvia the property tree). | For mouse handling I like the idea of having event handlers (eg. click, drag, hover, etc.). So instead of just one property holding the events of the whole dialog/canvas I want to forward the event to the corresponding element by using picking or maybe for a first step just bounding box checking with the current mouse position. It would still just set the three properties like before (button, x, y) but we could add an helper function which adds a listener to the button property and calls a function with all three parameters if the event was triggered. (I always want to keep the basic idea of only communicatingvia the property tree). | ||
| Line 168: | Line 168: | ||
=== Multiplatform Clipboard Support (native Copy/Paste) {{Pending}} === | === Multiplatform Clipboard Support (native Copy/Paste) {{Pending}} === | ||
{{Progressbar|30}} | |||
...probably needs to be individually implemented for each supported window manager environment (Windows, OSX, X11): | ...probably needs to be individually implemented for each supported window manager environment (Windows, OSX, X11): | ||
* X11: http://michael.toren.net/mirrors/doc/X-copy+paste.txt | * X11: http://michael.toren.net/mirrors/doc/X-copy+paste.txt | ||
| Line 188: | Line 188: | ||
Note: This is currently in progress, see [[Canvas Widgets#Status (08/2012)]]. | Note: This is currently in progress, see [[Canvas Widgets#Status (08/2012)]]. | ||
{{Progressbar|50}} | |||
* The major thing is we need to switch away from the CanvasWidget approach we are using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class {{Done}} | * The major thing is we need to switch away from the CanvasWidget approach we are using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class {{Done}} | ||
| Line 294: | Line 294: | ||
Background: [[Canvas Widgets#Widget declaration: XML vs. Nasal]] | Background: [[Canvas Widgets#Widget declaration: XML vs. Nasal]] | ||
{{Progressbar|10}} | |||
Even more integration with the existing SVG parser would probably help A LOT, because that would allow people to "draw" widgets in Inkscape and save them as SVG, so that they can be loaded by the widget system implemented in Nasal, which loads the SVG data and turns the data into Canvas property node structures. | Even more integration with the existing SVG parser would probably help A LOT, because that would allow people to "draw" widgets in Inkscape and save them as SVG, so that they can be loaded by the widget system implemented in Nasal, which loads the SVG data and turns the data into Canvas property node structures. | ||