|
From: James T. <zak...@ma...> - 2016-06-13 14:07:29
|
> On 13 Jun 2016, at 11:54, Erik Hofman <er...@eh...> wrote: > > Seeing the discussion about GUI options I always thought the following > was the aim: > > 1. Qt for dialogs used by FlightGear itself (main menu items) > 2. PUI/Canvas for aircraft related dialogs > > This setup would make perfect sense since Qt allows dialogs outside of > the main window preventing the outside view from being partly obfuscated > (which would be very welcome for the Property Browser dialog which can > take a great chunk from the outside view) > > This way the Qt GUI does not have to be backwards compatible either. That is roughly correct, but I always imagined I’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. Kind regards, James |