Canvas widgets: Difference between revisions

Jump to navigation Jump to search

Canvas widgets (view source)

Revision as of 14:11, 16 July 2013

3,201 bytes removed ,  16 July 2013
m
→‎Widget declaration: XML vs. Nasal: rm section, hardly relevant any longer
m (→‎The Idea: clean up, remove old PUI/CanvasWidget discussion)
m (→‎Widget declaration: XML vs. Nasal: rm section, hardly relevant any longer)
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: XML vs. Nasal ===
For the widgets the question is if we want to specify it with XML or only Nasal. I'm not yet sure but currently I'd tend to Nasal. Just creating a canvas and setup all contents in some load callback. Eg. placing widgets as children of existing widgets/groups and maybe also modify them.
Regarding your question on Nasal vs. XML for specifying widgets: I feel that widgets should be IMPLEMENTED in scripting space, but I would modify the PUI dialog builder such that the old legacy XML format is still supported, so that GUI XML files may refer to Canvas widgets and use them, without relying on Nasal being used in such cases. That would make it trivial to write a tutorial how existing widgets can be migrated to the Canvas, so that PUI could be completely removed at some point. Also, if someone really wants to use XML for widget declaration, it would not be too complicated to provide a tiny Nasal wrapper that allows XML or a subset of SVG to be used for such purposes. Obviously, none of this should be implemented as part of the core Canvas (C++) code. The XML route is obviously intriguing because it would enable people to create GUIs using wizards (or existing tools)- but a basic "dialog builder" could even be implemented with the current system, the Canvas system is only going to make it easier and more powerful actually.
I also agree that widget specification should really just be done from Nasal initially - however, it would be great to expose some hooks at some point, so that a Nasal-driven widget can load contents from disk (images/textures or even SVG files) to declare a GUI element. Often, GUI declaration is heavily declarative - that's why Mozilla/Firefox use XML (XUL) + scripting.
Obviously, the advantage would be that people could use existing tools (GIMP, Inkscape) to create their images and then just "load" them via Nasal and add some dynamic features to them. Specifying all these things in Nasal would be very tedious, and this is something that most of us coders are really not too good at (i.e. artwork).
This is not to say that all of SVG would need to be supported, but there's already code in OSG to support such image formats - and if we could find a way to leverage native OSG code to handle such things, we would gain lots of flexibility: We have LOTS of users here who are really good at using tools like GIMP or Inkscape, so if they have a way to reuse such artwork, it would be great.
Integration-wise, there are some lessons to be learnt from the way SMIL works via SVG and ECMAScript (JavaScript).
However, like you said earlier: I suggest to keep things simple for now and just focus on the infrastructure, so that people will be able to do these things. For example, the graph widget sounds interesting, but a simple button with an image loaded from the base package, overlaid on it (not supported currently!), would be just as illustrative and much easier to implement, without having to sacrifice any time spent on developing more complex widgets like the graph.
On the other hand, more complex widgets can help with shaping the API, because they require dealing with GUI callbacks from Nasal.


=== Widget Declaration via SVG  ===
=== Widget Declaration via SVG  ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/61610"

Navigation menu