20,741
edits
Talk:CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
Talk:CompositeViewer support (view source)
Revision as of 11:34, 30 November 2020
, 30 November 2020→View Creation API: new section
(Created page with "~~~~ Apologies Hooray but i've removed the large note about OSG-3.6, as it was rather dominating the page and messing up the layout quite badly. I've put the information in am...") |
(→View Creation API: new section) |
||
| Line 1: | Line 1: | ||
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 12:23, 5 October 2020 (EDT) Apologies Hooray but i've removed the large note about OSG-3.6, as it was rather dominating the page and messing up the layout quite badly. | [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 12:23, 5 October 2020 (EDT) Apologies Hooray but i've removed the large note about OSG-3.6, as it was rather dominating the page and messing up the layout quite badly. | ||
I've put the information in amongst the other information about OSG. | I've put the information in amongst the other information about OSG. | ||
== View Creation API == | |||
{{FGCquote | |||
|we could use XML or a property tree to represent all the properties of a new view - Nasal is perfectly capable of constructing either in response to a 'Create View' dialogue, and passing to SviewCreate() in the normal way.|{{cite web |url=https://sourceforge.net/p/flightgear/mailman/message/37164487/ | |||
|title=<nowiki>[Flightgear-devel] Sview?</nowiki> | |||
|author=<nowiki>Julian Smith</nowiki> | |||
|date=<nowiki>2020-11-29 19:55:56</nowiki> | |||
}} | |||
}} | |||
[[File:CompositeViewer-prototype-UI.png|thumb|[[Canvas]] based GUI dialog to create [[CompositeViewer Support|CompositeViewer views]] dynamically using a configurable [[Compositor]] pipeline.]] | |||
Indeed, I think this is a very good point, and I believe it will present the least amount of work: As mentioned elsewhere, I have been toying with a simple Canvas based UI for the creation of views using the parameters that Fernando laid out at [[Canvas_View_Camera_Element#Create_a_Canvas_Element_subclass]]. | |||
Note that this isn't intended to be a/the definite UI - but rather a simple way to set up views using a GUI, so that people (early-adopters) can more easily experiment with these features, and hopefully also help with wider testing and provide better bug reports along the way. | |||
While it would obviously be possible to create a fancy Nasal (cppbind) or C++ specific API, I have come to the conclusion that it makes sense to go '''only''' through the <code>fgcommand</code> layer, passing a SGPropertyNode/props.Node structure with key/value pairs. | |||
That way, we can trivially support PropertyList/XML files, but also views that are specified directly, as part of a sub-tree (e.g. for the CanvasView element). | |||
Besides, this means that '''any''' UI/frontend can invoke the corresponding back-end code easily: | |||
* [[QtQuick use in FlightGear|Qt5]] | |||
* [[PUI]] | |||
* [[Phi]] | |||
* [[Canvas]] | |||
* [[Nasal]] | |||
* [[Telnet usage]] | |||
It would however make sense to split up the implementation, i.e. so that the underlying compositor and the view can be created separately via two explicit fgcommands - there could still be a a higher-level fgcommand to call those two automatically, but otherwise it's probably easier to set up the whole thing in separate stages/steps, and also much cleaner code-wise. | |||
If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST) | |||