20,741
edits
UI Unification: Difference between revisions
Jump to navigation
Jump to search
→Motivation
No edit summary |
|||
| Line 43: | Line 43: | ||
}}</ref> | }}</ref> | ||
If a | If a sizable number of core developers has argued against making Qt a dependency and there's a consensus to confine its use to a GUI module, then there are legitimate concerns<ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/34537005/ | |url = https://sourceforge.net/p/flightgear/mailman/message/34537005/ | ||
|title = <nowiki> Re: [Flightgear-devel] GUI questions (again) </nowiki> | |title = <nowiki> Re: [Flightgear-devel] GUI questions (again) </nowiki> | ||
| Line 84: | Line 84: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
James always imagined he’d write some code to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources. Of course, I think aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35155721/ | |||
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jun 13th, 2016 | |||
|added = Jun 13th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Regarding the Canvas GUI system, we could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the {{fgcommand|show-dialog}} command to create a canvas and call the parser.<ref>{{cite web | Regarding the Canvas GUI system, we could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the {{fgcommand|show-dialog}} command to create a canvas and call the parser.<ref>{{cite web | ||