20,741
edits
(→Status) |
|||
Line 24: | Line 24: | ||
For the time being, this approach has a number of major advantages, i.e. it has proven to be able to deal with existing UI resources (dialogs, and the [[Menubar]]), without the original legacy UI dialogs (or any C++ code) having to be touched/modified, so that the primary thing missing to parse/process these dialogs are a handful of missing Canvas widgets, which can also be implemented in scripting space usually. | For the time being, this approach has a number of major advantages, i.e. it has proven to be able to deal with existing UI resources (dialogs, and the [[Menubar]]), without the original legacy UI dialogs (or any C++ code) having to be touched/modified, so that the primary thing missing to parse/process these dialogs are a handful of missing Canvas widgets, which can also be implemented in scripting space usually. | ||
Besides, this approach also is the only effort that can easily support procedurally created and updated dialogs like [[Aircraft Checklists]] | Besides, this approach also is the only effort that can easily support procedurally created and updated dialogs like [[Aircraft Checklists]], [[Tutorials]], [[Joystick Configuration]] (as well as a number of custom aircraft dialogs). | ||
Also, the '''pui2canvas''' approach can help address a number of long-standing PUI related issues, such as rendering arttfacts on some ATI/AMD GPUs, but also PUI/Canvas inter-operability issues related to [[Canvas Event Handling]]. | Also, the '''pui2canvas''' approach can help address a number of long-standing PUI related issues, such as rendering arttfacts on some ATI/AMD GPUs, but also PUI/Canvas inter-operability issues related to [[Canvas Event Handling]]. | ||