I would suggest having side-by-side screenshots of the PUI and CUI dialogs on the wiki article. It would be useful for tracking progress, graphic design, aesthetic layout, and how close to functional this is
Regards,
Edward
bugman wrote in Tue Jun 14, 2016 2:10 pm:As for Qt being optional, over the last two years on the mailing list, that position has obviously evolved. I'm only stating what I see. And that is that it will be only optional for a tiny subset of people. The majority will use it, probably without knowing, as it will be the default GUI shipped with FG.
James Turner wrote:I would say do the PUI fix for now, I am still very much undecided about which technology to use for in-sim GUI. I am somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is I am fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy my ideas about how simple + robust such an API should be. I need to evaluate if the current API can be improved or needs to be drastically changed.
The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes me nervous about multi-window setups and other more esoteric OSG configs.
So, yes, I’d say do PUI for now, since this is worth a fairly quick fix as it’s the default airport.
Kind regards,
James
James wrote:https://sourceforge.net/p/flightgear/ma ... /37701750/
It was going to be Qt but it started to get very complicated with changes in Qt 5.15 + Qt 6, so I’m going with a more light-weight approach now.
Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’. (If for some reason anyone wants the code to render Qt Quick in OpenGL mode into OpenSceneGraph, I have it working nicely on a branch, from about two years ago...)
So now i’m going with something much lightweight using some C++ compatibility code, some Nasal for styling and the existing widget rendering from Thomas with some extensions and additions: some pieces are in FlightGear & FGData already. I have basic dialogs working okay but not the more complex ones and everything looks kind of ugly, I need to improve the visual look before I share screenshots to avoid everyone freaking out The disadvantage of this approach is I’m far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for me.
Hooray wrote in Fri Sep 02, 2022 2:52 pm:https://wiki.flightgear.org/PUI#2022James wrote:So now i’m going with something much lightweight using some C++ compatibility code, some Nasal for styling and the existing widget rendering from Thomas with some extensions and additions: some pieces are in FlightGear & FGData already. I have basic dialogs working okay but not the more complex ones and everything looks kind of ugly, I need to improve the visual look before I share screenshots to avoid everyone freaking out The disadvantage of this approach is I’m far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for me.
Hooray wrote in Sun Sep 04, 2022 3:11 pm:I slider is basically nothing more than a button responding to a drag/drop event, which in turn changes its position horizontally or vertically - so, we already have that, too - using event handling and updating the position of the widget
Unrelated to all of this, aircraft devs kept using the canvas UI system - because they could not afford to create UIs that would only work in Qt enabled builds,
Hooray wrote:Also note, any new widget/layouting directive that is supported by the parser, will automatically benefit all GUI dialogs, including those kept outside $FGDATA, i.e. aircraft specific dialogs living in other hangars
Users browsing this forum: No registered users and 1 guest