20,741
edits
UI Unification: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 43: | Line 43: | ||
Specifically, this means that UI dialogs will no longer contain any logic in the form of Nasal scripts, but that they will need to be reviewed to identify generic functionality that can be added in the form of dedicated tags for layouting, widgets, fgcommands and remote properties which can be supported by all existing, and upcoming, UI front-ends, without having to know anything about FlightGear scripting in the form of Nasal. | Specifically, this means that UI dialogs will no longer contain any logic in the form of Nasal scripts, but that they will need to be reviewed to identify generic functionality that can be added in the form of dedicated tags for layouting, widgets, fgcommands and remote properties which can be supported by all existing, and upcoming, UI front-ends, without having to know anything about FlightGear scripting in the form of Nasal. | ||
If scripting is to be supported sooner or later, it will also need to be [[Canvas Nasal/JavaScript Subset | If scripting is to be supported sooner or later, it will also need to be [[Canvas Nasal/JavaScript Subset|a well-defined subset of ECMAScript that]] can be supported by all front-ends, e.g. by implementing a simple DSL and a corresponding parser for it (JavaScript and Nasal are close enough so that they could certainly share most of the code). | ||
|a well-defined subset of ECMAScript that]] can be supported by all front-ends, e.g. by implementing a simple DSL and a corresponding parser for it (JavaScript and Nasal are close enough so that they could certainly share most of the code). | |||
What is needed is an extensible file format to get rid of these constructs, so that they can be replaced with the corresponding layout/widget tags (think for tabs), as well as custom fgcommand implementations, which could then be shared among all front-ends. Sooner or later, this would end up being fully-declarative, and could be easily processed by all UIs - at which point a 1:1 Qt migration would be much less work, no matter if that involves procedural UI generation or semi-automated translation using some scripted approach. | What is needed is an extensible file format to get rid of these constructs, so that they can be replaced with the corresponding layout/widget tags (think for tabs), as well as custom fgcommand implementations, which could then be shared among all front-ends. Sooner or later, this would end up being fully-declarative, and could be easily processed by all UIs - at which point a 1:1 Qt migration would be much less work, no matter if that involves procedural UI generation or semi-automated translation using some scripted approach. | ||