Canvas widgets: Difference between revisions

Jump to navigation Jump to search

Canvas widgets (view source)

Revision as of 06:58, 17 October 2013

3,976 bytes removed ,  17 October 2013
→‎Widget Declaration via SVG: remove depreciated stuff
(→‎Widget Declaration via SVG: remove depreciated stuff)
Line 243: Line 243:


The canvas isn't really about end user features, it's a provider of an infrastructure, so that end user features can be more easily expressed and modeled in scripting space, using Nasal. That's why all end user features should be expressible in scripting space, and only the core infrastructure should need C++ extensions to make this easier. The end user APIs will be mostly designed in scripting space.
The canvas isn't really about end user features, it's a provider of an infrastructure, so that end user features can be more easily expressed and modeled in scripting space, using Nasal. That's why all end user features should be expressible in scripting space, and only the core infrastructure should need C++ extensions to make this easier. The end user APIs will be mostly designed in scripting space.
=== Widget Declaration via SVG  ===
{{Pending}}
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.
The widget superclass could be extended to load GUI elements from SVG files, these could then be linked to widget-specific callbacks, i.e. the canvas-events (button, mouse-x, mouse-y, mouseover etc).
Basically, that would mean that non-coders could edit GUI files via SVG, and the widget/svg layer would merely use the existing canvas ID lookup syntax to get a handle to certain elements, i.e. to implement a button or scrollbar and to change attributes easily (resize, color, font etc):
<syntaxhighlight lang="php">
m.root = m.canvas.createGroup();
canvas.parsesvg(m.root, "[[$FG_ROOT]]/gui/svg/button.svg");
var label = m.root.getElementById("label");
label.setText("Widget loaded from SVG");
label.setColor(1,0,0);
</syntaxhighlight>
The widget constructor for each widget (button, textbox etc) could then require certain elements (IDs) to be present in each SVG file, i.e. identifiers it can look up, such as "button_left", "textarea_top", "scrollbar_left" etc - people could then easily create new/custom SVG files, and would just need to make sure that the required elements are available so that they can be addressed by the widget class which implements the callbacks and which uses the vector data from the SVG file to procedurally create the rendered GUI widget.
This would separate the appearance/layout from the code implementing the behavior, i.e. true MVC design.
That would make lots of GUI building C++/Nasal code unnecessary, because we would adopt an existing standard - and it would also mean that our users could help porting the GUI, by creating GUI widgets via SVG elements - and Nasal coders could then focus on implementing the code/logic to connect the SVG elements to events and behavior, which I find more enjoyable than coding widgets by drawing them directly
If somebody needs more flexibility, it would still be possible to provide a bunch of helpers or use the canvas system directly.
None of the existing applications using SVG for the UI directly load svg files, but instead all create them procedurally. With direct SVG loading you always have the problem that you don't know how to scale the different parts of the shapes for different sizes, so I think procedural generation of widgets is the way to go. For sure on can have a look at existing widgets or create new ones with SVG but all of them need to be converted to a procedural approach which can handle different (content) sizes. Just think of what would happen to a button with different caption lengths - do you scale the rounded borders or to you just move them for different sizes.
Another solution would be to mark certain areas as stretchable and move the others on resize, but I don't know how well this would work inside Inkscape.
{{#ev:youtube|HPVaMBqdXTI}}
Supporting the creation of GUI widgets via SVG, means so much less work than creating all widgets from scratch, extending the SVG parser to support more features and possible styling via XSL/CSS would not be too complicated, and probably it would be good for all other canvas uses, too.
There are some open source GUI toolkits that already use SVG to implement their widgets, so these could be borrowed directly and reused in FG to make some fast progress until fully custom widgets are available.
* http://jyro.blogspot.de/2008/09/inkface-svg-based-gui-design.html
* http://code.google.com/p/altcanvas/wiki/InkFace
* http://spark.sourceforge.net/
* https://www.svgopen.org/2004/papers/SPARK/
* http://www.svgopen.org/2003/papers/SPARK/Summary.html


=== Layout Management ({{Not done}}) ===
=== Layout Management ({{Not done}}) ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/63408"

Navigation menu