Board index FlightGear Development

GL2PUI

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

GL2PUI

Postby xcvb » Thu Dec 19, 2019 8:36 pm

Since there are obviously no plans to get rid of PUI soon, I wondered if it would be a good idea to port PUI to OpenGL2. I'm not really an OpenGL expert, but at least I could get something working:

Image

Currently only the border is painted with OpenGL2 (I added pattern effect in the pixel shader).

Now I wonder which is the best solution to proceed:

1.) Stupid idea -> use Qt, PHI or canvas instead
2.) Write a wrapper around glBegin/glEnd functions and map them to OpenGL2 functions
3.) Complete PUI rewrite and make it look a bit more modern (e.g. https://github.com/shi-yan/AssortedWidgets)
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby wkitty42 » Fri Dec 20, 2019 4:10 am

have you not been reading the dev mailing list over the last year or two? there's been some work done to port PUI... i'm aware of one ongoing work with Qt... there's another for canvas, as well, but i don't know what its status is currently...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5984
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: GL2PUI

Postby xcvb » Fri Dec 20, 2019 8:22 am

great to hear that progress is being made
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby slawekmikula » Fri Dec 20, 2019 11:04 am

xcvb wrote in Thu Dec 19, 2019 8:36 pm:Since there are obviously no plans to get rid of PUI soon, I wondered if it would be a good idea to port PUI to OpenGL2.


@xvcb could you elaborate what the benefits would be with this ? There was a lot of talk about it but if this thread started, maybe there is a place for it :)

@wkitty yep, there was a rumors about it, but if I track it correctly there is one person who is involved in Qt part and beside of this he is doing a lot of work everywhere else and without taking RL into it. So looking at this that way, maybe it is something to talk about PUI. I personally would like to have ability to create submenus in PUI main menu (i think it is rather not possible today) :)
slawekmikula
 
Posts: 81
Joined: Sun Feb 19, 2017 9:31 am

Re: GL2PUI

Postby Thorsten » Fri Dec 20, 2019 11:37 am

You'll have a hard time convincing anyone of the value of adding more work to PUI.

You can create truly lovely and complicated dialogs with canvas

Image

- the corresponding widgets are publicly available, or you can wait for Qt to materialize. PUI doesn't have any friends in FG any more.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: GL2PUI

Postby xcvb » Fri Dec 20, 2019 2:04 pm

slawekmikula wrote in Fri Dec 20, 2019 11:04 am:@xvcb could you elaborate what the benefits would be with this ? There was a lot of talk about it but if this thread started, maybe there is a place for it :)

The problem with PUI is, that it is written in OpenGL1 and that you cannot combine OpenGL1 and OpenGL3 code. Some features like geometry shaders are not part of the OpenGL2 standard, so e.g. the grass effect only works on systems where this feature was added as special vendor extension. In OpenGL3 this feature was officially added to the standard and all OpenGL3 compliant GPUs support it.
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby Thorsten » Fri Dec 20, 2019 2:43 pm

The more general problem is that we can't do OpenGL 3 code at all without major restructuring of the whole codebase - for which there is really no workforce around. PUI is the least of the problems.
Thorsten
 
Posts: 11374
Joined: Mon Nov 02, 2009 8:33 am

Re: GL2PUI

Postby Hooray » Fri Dec 20, 2019 9:30 pm

Here are some facts and pointers:
  • There's a long-standing effort to port our PUI based GUI to Qt5
  • All Qt5 code is required to remain entirely optional by core developer consensus: https://sourceforge.net/p/flightgear/ma ... /34196458/
  • Writing/porting a GUI engine from scratch is a fair amount of work, and it's usually redundant, because there's a plethora of existing UI toolkits available these days
  • porting all of our existing GUI would also still present quite a bit of work, primarily because of how we have come to use/extend dialogs via embedded Nasal blobs
  • Under the hood, FlightGear only uses a tiny subset of PUI widgets
  • The PUI widgets used/supported by FlightGear are rather rudimentary/basic and even archaic
  • the primary issue really is how we use Nasal scripting to create/update dialogs procedurally
  • the Canvas system is not optional, it is available in all recent FlightGear versions
  • thanks to the Canvas system it is pretty simple to re-interpret existing dialogs and map those to Canvas equivalents
  • we have an experimental parser that was prototyped a couple of years ago, during the course of a single weekend, and it took roughly 500 lines of code to create a parser that can process most dialogs/widgets
  • the parser is entirely written in Nasal, so does not require any C++ changes, it merely wraps/overrides the corresponding PUI related fgcommands
  • the parser could be simplified, and even made bullet-proof, by patching the built-in hard-coded C++ parser to delegate the creation of widgets to Nasal space, this would take roughly 15 lines of straightforward C++ code, at that point the existing layouting engine and widget builder could be reused

Anybody who's ever done any MFD coding using Nasal and Canvas should be able to make heads and tails of the parser to add missing widgets, it really is straightforward.
In other words, the parser I mentioned was created during a few days only, and it's been used to create/render more dialogs than any other non-PUI solution we've seen so far.

The screen shot that Thorsten posted exemplifies that it's really easy to create fancy custom widgets, but the few ones we're missing to get rid of PUI would be much easier to re-create.

It's even able to process complex dialogs with lots of embedded Nasal blobs, including even embedded Canvas widgets - for the simple reason that the parser is using the exact technology stack that it is interpreting: Nasal and Canvas.

http://wiki.flightgear.org/Howto:Proces ... .26_Status
Image


Background:
http://wiki.flightgear.org/PUI
http://wiki.flightgear.org/Unifying_the ... via_canvas
http://wiki.flightgear.org/Canvas_Widget_Matrix
http://wiki.flightgear.org/Pui2canvas
http://wiki.flightgear.org/Canvas_Widgets
http://wiki.flightgear.org/Howto:Creati ... GUI_Widget

http://wiki.flightgear.org/QtQuick_use_in_FlightGear
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: GL2PUI

Postby xcvb » Fri Dec 20, 2019 9:50 pm

I know the canvas solution, but I wonder how you are going to replace the menu bar with it. On the Mac there is the Cocoa menu, which works very well in full screen mode, but on Linux or Windows there is no such thing.
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby Hooray » Sat Dec 21, 2019 8:12 am

I don't think the Mac OS stuff is ever going to be touched:
James implemented the native Mac OS menubar - prior to that, there's always only been the built-in PUI menubar.

Replacing/emulating that is really straightforward - once you think about, a menubar is just a "long horizontal window" (without window decoration) with a single row of "buttons" that respond to events (clicks), and once clicked they show a "popup" window (also without decoration).

We do have all the bits for this in place: We can render windows without decoration, and we can add text, images and buttons that respond to clicks.
We are also able to show "popups", e.g. in the form of tooltips: http://wiki.flightgear.org/Tooltips
And these popups, can in turn also contain other buttons - this time arranged in a vertical vbox layout

It takes very little code to come up with a window to parse menubar.xml and show a corresponding row of entries:
Image

You can also easily show popups for each menu:
Image

(Note that this was all proof-of-concept, written by someone on the forum without much Nasal/Canvas experience)

The more "proper" approach would be using a Canvas hbox layout with buttons added for each menu:

http://wiki.flightgear.org/Canvas_Snipp ... Layouts.29
Image

Writing a real parser to process menubar.xml and render a menubar would be a pretty fun exercise, and it'd be lightweight too.

And it would support everything that can be done via the Canvas, including even custom styling, images, resizing, drag&drop and so on

As a matter of fact, a number of aircraft developers have come up with a Canvas based menubar supporting popups for their avionics:
Image

Heck, even other custom FlightGear-specific widgets that are currently hard-coded in C++ can be easily approximated via Canvas, here's a property-list widget approximation that works "as is":
Image

It would be easy to extract/adapt and reuse that code to use it for the built-in menubar, too to directly replace the PUI one.
As far as I am aware, the only "real" issue is the recently added support for localized strings, which I believe hasn't been exposed to Nasal space - so that this would require some work (or additional hooks)

http://wiki.flightgear.org/Menubar
http://wiki.flightgear.org/Howto:Making ... as_Menubar

In summary, it would take more effort to port/update existing C++ code than walking existing aircraft developers through the process of creating/updating and maintaining such a parser - no matter if it's parsing $FG_ROOT/gui/dialogs or menubar.xml - it's a neat little exercise actually, and we could reuse tons of existing code that'd be useful - it's basically a few nested foreach loops, and XML processing (properties) to look for certain nodes/child nodes and pass that stuff to a factory function that handles the creation of the corresponding layout/widget - for instance, an airport-list widget can be emulated easily by adding a VerticalScrollArea with buttons for each entry:

Image

PS: Note that the screen shots above do show window decorations, for the sake of debugging/troubleshooting (being able to close/reopen the menubar while developing the underlying code is indeed useful)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: GL2PUI

Postby xcvb » Sat Dec 21, 2019 9:15 am

How can I remove the window decorations in the menu bar?
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby Hooray » Sat Dec 21, 2019 2:30 pm

Keep in mind that, under the hood, a canvas is just a texture - i.e. an off-screen rendering target that you can draw into.

To actually "display" a canvas, you need to register a so called "placement" - so that the canvas texture is used inside the aircraft, on the fuselage, the scenery or in a GUI dialog.
There is a so called "desktop" placement, which is what tooltips use.

So you can basically look at tooltip.nas to see how this works, because tooltips are already shown as "popups" (canvas dialogs without window decoration): http://wiki.flightgear.org/Tooltips

The code can be seen here: https://sourceforge.net/p/flightgear/fg ... ooltip.nas

As youc an see, it's just a matter of telling the placement to be a "window" rather than a "dialog": http://wiki.flightgear.org/Canvas_Troub ... anvas_code

It would be straightforward to take the tooltip.nas code and adapt that as needed to create all sorts of "popups" for the menubar, including sub-menus.

However, for development purposes, you will likely want to retain the window decoration - because it allows you to easily remove/clean up a placement

See:
http://wiki.flightgear.org/Canvas_Snipp ... one_Canvas
http://wiki.flightgear.org/Canvas_Snipp ... as_Desktop
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: GL2PUI

Postby xcvb » Sun Dec 22, 2019 10:15 am

OK, I get it. Thank you very much for the information.

On the other hand, there are only a few pure virtual methods in the class FGMenuBar, so the C++ code would also not be that complicated to implement a menu bar in OpenGL2 or OpenGL3.
xcvb
 
Posts: 108
Joined: Sat Mar 14, 2015 2:08 pm
Version: GIT
OS: Linux

Re: GL2PUI

Postby Hooray » Sun Dec 22, 2019 11:22 am

if you want to write C++ code, you will obviously have to patch/rebuild fgfs - so, it would be better to discuss this on the devel list.

On the other hand, if you have ever done any Nasal/Canvas coding, you have probably noticed that writing a Nasal parser to create a Canvas based menubar by processing menubar.xml is a rather straightforward exercise - and you won't have to write any low-level GL code, it's automatically using OSG under the hood.

So I guess, if someone were to spend 10 hrs coding in C++ to update PUI, the same 10 hours spent by someone working on the Qt5/QQ2 port would provide more bang for the buck, and obviously 10 hrs spent fine-tuning the pui2canvas parser, would provide a fast track solution to get rid of PUI without having to be a core developer, and even without having to touch any C++ code.

Then again, if people interested in an interim Canvas-based UI were to team up with C++ folks, much of the work of re-implementing the layouting/dialog builder routines would be obsolete, because FGPUIDialog.cxx could simply be adapted to override built-in widgets, analogous to how the addcommand() API makes it possible to register/override fgcommands implemented in Nasal.

There is already a mechanism in place to inherit from the abstract Canvas.Widget baseclass, this approach would also work to hook into the existing dialog builder, at that point you don't even have to deal with XML processing/properties anymore.

Again, if you want to write C++ code, it's best to reach out to the devel list, if all you need is a non-PUI menubar, that can be trivially accomplished via canvas, including fancy features like sub-menus, images, checkboxes etc

Writing a Nasal module to process our existing menubar.xml file to render a Canvas-based menubar would probably be less than 250 lines of code, it could be prototyped via the Nasal console, and once it works well enough it could be turned into an addon, so that people can easily decide whether they want to use that or not

Finally, there's more to PUI than the menubar, when I came up with the pui2canvas parser it was intended as a proof-of-concept because I considered the menubar far too trivial to make a point - many of the people back then, didn't even realize that there is already a built-in "Canvas GUI" system that supports windows, dialogs, event handling etc - as well as a handful of widgets and a really powerful widget API.

However, people not wanting PUI and those working towards a Qt5 based UI do have a very valid point, too: "coding dialogs" is begging for trouble, that is exactly the situation we reached by adding more and more Nasal blobs to our dialogs, if it wasn't for those, it would indeed be trivial to use _any_ other UI toolkit, it is the amount of Nasal code that is making matters more complicated than necessary.

The irony however is that thanks to the UI/Qt5 transition dilemma, we've already reached the point where aircraft developers no longer want to use PUI, and no longer want to "wait" for Qt5 - which means, they end up using Nasal and Canvas again, so that more and more aircraft are using fancy dialogs that are indeed not declarative but coded - ironically, that shields aircraft developers from the UI dilemma, but it also complicates any efforts to modernize our UI in the future.

Conceptually, having a declarative UI is the right thing - having Nasal blobs all over the place is hugely problematic, and so is "coding dialogs" without establishing logical boundaries, i.e. in terms of "layouts", "widgets" and "event handlers".

Admittedly, what some aircraft developers have meanwhile come up with is by far superior to what we have in the Canvas Widget department - the issue is, there is no encapsulation boundary, so that such dialogs are not designed with modularity or code reuse in mind.

But again, coming up with a handful of widgets to emulate those missing to get up to par with PUI (README.gui), is really comparatively straightforward in comparison to coding dialogs from scratch - most Canvas dialogs are easily more complex than the widget boilerplate needed to create/register new widgets.

I'd suggest, you take a look at some of the existing Canvas dialogs and widgets under $FG_ROOT/Nasal/canvas/gui to see for yourself:

wiki.flightgear.org/Howto:Creating_a_Canvas_GUI_Widget

For example, here's the code for the "Label" widget: https://sourceforge.net/p/flightgear/fg ... /Label.nas

The parent class can be seen here: https://sourceforge.net/p/flightgear/fg ... Widget.nas

The "view" part (MVC) of all widgets can be seen here: https://sourceforge.net/p/flightgear/fg ... tStyle.nas



So the point really is, writing C++ code to do something that can be done in Nasal through Canvas/OSG without it being performance critical is kinda controversial, given that PUI is indeed scheduled to be phased out - i.e. be prepared to see your work going to the waste bin once the Qt5 stuff materializes
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11469
Joined: Tue Mar 25, 2008 8:40 am


Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest