You're once again repeating the mistake trying to transfer your own experiences/project to the FlightGear project ... which unfortunately doesn't work.
Because last I checked, "nmr-relax" was a different project, not so much related to FlightGear - but maybe I'm wrong ?
And well, over the years, James and other more senior developers have also been toying with also establishing such a "rule" based system, but they also concluded that it's probably not worth the hassle - more recently, this is what he said a couple of weeks ago:
We could try to make a rule like, for each new feature you add, you have to investigate & close 25 bug reports … but, well, that’s kind of arbitrary … and not great for people’s enthusiasm either.bugman wrote:HLA/RTI, I'm not sure about. But I'm pretty sure that didn't kill anything though.
How is that ?
I'd encourage you to check your facts: HLA/RTI has a long-standing history of being raised whenever people are showing up that are eager to improve multi-core support (subsequently killing off the original idea/effort), FlightGear's support for networking and for distributed setups. It's the single most influential
Duke Nukem Forever- feature the project has seen in its lifetime
bugman wrote:Qt5 UI is not dead. There are just a lot of other things to do first.
Which is fine and comes with the territory obviously, but also complicates other efforts - i.e. by having been announced to be ready since ~2016:
http://wiki.flightgear.org/PUI#Replacement%20statusbugman wrote:If it killed off any ideas for a Canvas GUI, I am quite happy about that.
Sorry to disappoint you, but I don't think the Canvas UI subsystem got killed at all (suggesting that, would be akin to stating that Nasal failed because you once dabbled with Python support in FlightGear); the Canvas GUI subsystem actually exists and is part of FlightGear (and has been since ~2012) - unlike the Qt5 UI. You've been failing to acknowledge that
Open the property browser/performance monitor and see for yourself, it nicely shows up there - and guess what it's called there: "CanvasGUI"
And it's indeed been implemented and added at the encouragement of James himself:
"we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class "It's been widely used by many aircraft developers using the Canvas system to implement avionics, especially whenever they begin providing a GUI option using the exact same Canvas GUI subsystem.
bugman wrote:I do a lot of GUIcoding in my projects, and creating a fully functional Canvas GUI toolkit with asynchronous and threaded event handling, and dealing with locking and windowing, seems crazy to me and a maintenance nightmare.
You've been mentioning your GUI coding experience for many years now, and while it's indeed impressive, you've been drawing the wrong conclusions since day 1: FlightGear's existing PUI-based GUI is
not threaded at all - I've pointed that out numerous times to you, when you were still highlighting how a UI inevitably must be threaded. You've been enormously influential by your comments in the whole Qt/UI debate, despite not having shown the slightest bit of familiarity with the way how the existing PUI engine is integrated, and how Nasal/Canvas relate to that, versus how Qt5 is being integrated.
Next, you presented a "challenge" by asking for PUI to be stripped out of FlightGear - I shared the exact steps needed to do this at runtime using the subsystemFactory:
viewtopic.php?f=71&t=29789&#p288924p288906Later on, I actually even went further, and shared patches to completely remove PUI at build time:
http://wiki.flightgear.org/FlightGear_a ... abling_PUII have also pointed out how the existing Canvas UI system has got event handling and windows since its very inception (again, since some time in 2012), and it simply works - without introducing new dependencies, and without introducing threading ... and without being optional. It's exactly what aircraft developers are using to show MFD screens inside dedicated dialogs - embedded either as canvas widgets inside PUI dialogs, or shown in dedicated/standalone Canvas dialogs:
You mentioned window management, here's the original demo from around 2012 (again, implemented at the encouragement of James):
What else ? Right, you mentioned event handling right, also implemented back in 2012:
http://wiki.flightgear.org/Canvas_Event_HandlingAnd by the way, unlike any other alternate in-sim FlightGear GUI we've seen so far, it's the only non-PUI option that's been shown to render functional PropertyList/XML dialogs without those having to be edited, all using ~600 lines of code (written during a few weekends):
So, not sure where you are seeing the "failure" here - you may in fact be in for a huge surprise here.
What you've been describing as a mammoth task and a maintenance nightmare for the last couple of years, is quite the opposite actually. With James specifically acknowledging exactly that a while ago:
James Turner wrote:https://sourceforge.net/p/flightgear/ma ... /35863607/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.
https://sourceforge.net/p/flightgear/ma ... /36199572/My impression is that
if you make a Canvas UI option, the Qt based solution will be still-born almost by default - because I won’t be able to create any enthusiasm or interest around it. Maybe I’m wrong about that, but
for sure Canvas based approaches attract a lot more support and man-power very easily. And my guess each person who works on the Canvas based Ui is one fewer who might ever help out with the Qt based one.
[...]
let’s say the Qt UI is 1/4 of my time per week spent on FG (might be a little more, but I have lots of other things to work on), vs
Thorsten’s time and 4 or 8 enthusiastic people he can recruit - I’m obviously going to fall massively behind in comparison - within three or six months they might build a complete replacement UI.
So, James talked about 3-6 months - and that's basically how many different people have shown up over the years who were interested in creating a solution from scratch.
Finally, let's keep in mind, many of these talks took place 4-5 years ago - but that's also when the "pui2canvas" screen shot showing map-canvas.xml got created
So, please stop talking about "mammoth tasks" and "maintenance nightmare" -given that the only person intimately familiar with replacing PUI using Qt has been stating the exact opposite for years, otherwise you're just deluding yourself here
bugman wrote:(more recently, there's apparently a push towards C++17/VSG adoption/migration - despite VSG not even yet being a thing at all ... and despite the OSG port never having been completed in the first place )
There is nothing wrong with planning for the future
Certainly not. But as an OSS project there is clearly something very wrong once we keep announcing new features for years in a row -without delivering- while discouraging the development of features that we consider a threat to the new feature in question (no matter if that's VSG, Qt5, FGPythonSys or HLA/RTI). That's the kind of stuff that forks are made off Thorsten summed it up very nicely when he said this:
https://sourceforge.net/p/flightgear/ma ... /36200307/Thorsten wrote:There was plenty of effort spent by various people
making sure it's going to be the Qt option only - so now you need to
deliver. As I said, I'll focus on making my aircraft dialogs future proof
and exploring the fun of more radical canvas designs.