Board index FlightGear The FlightGear project

"Advertising FlightGear"  Topic is solved

Questions about the FlightGear organisation, website, wiki etc.

Re: "Advertising FlightGear"

Postby Johan G » Tue Aug 25, 2020 9:22 pm

Hooray wrote in Tue Aug 25, 2020 8:09 pm:[...] if someone is hoping to get C++ patches committed, it's best to reach out to the devel list first and ask for "bite-sized projects", and then also have the discussion who's around and who's willing to actually help review/integrate and commit those.

That is a really important point. Both here and pretty much everywhere else.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: "Advertising FlightGear"

Postby bugman » Wed Aug 26, 2020 9:01 am

Asking for "bite-sized projects" is not really a way into the C++ code. That will probably get you nowhere. You firstly need to learn a bit about git, set up a FlightGear build environment, sand ign up for the FlightGear development mailing list. The key is to communicate your intent and designs on the FlightGear development mailing list. Also do not develop in isolation and then dump a large pile of code on the FlightGear developers (as was done with osgEarth), but instead discuss developments and integrate parts/infrastructure into the main repositories as you go.

The easiest way "in" is now to go to the test_suite/ directory in the flightgear repository, pick one of the already existing test*.{hxx,cxx} files, and create your own test*() function. Then you can look at creating your own test suites (a set of test*.{hxx,cxx} files). Here you can learn from example. The test suite is the semi-secret back door into the FlightGear repositories and commit access ;)

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: "Advertising FlightGear"

Postby Hooray » Wed Aug 26, 2020 3:20 pm

bugman wrote in Wed Aug 26, 2020 9:01 am:The test suite is the semi-secret back door into the FlightGear repositories and commit access ;)


In a perfect world that would be true, in reality it isn't - as you know.
Testing in FlightGear/SimGear still is very much in the early stages, and like you keep saying, a ton of testing infrastructure is still missing.

In comparison, it's rather newcomers who have a track record of fixing compiler warnings/errors, or fixing memory leaks.
That /might/ change obviously, but adding more testing is certainly no backdoor into the repos.

A bite-sized project is comparatively straightforward, i.e. things like adding fgcommands, Nasal extension functions etc
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Advertising FlightGear"

Postby Johan G » Wed Aug 26, 2020 10:24 pm

bugman wrote in Wed Aug 26, 2020 9:01 am:The key is to communicate your intent and designs on the FlightGear development mailing list. Also do not develop in isolation and then dump a large pile of code on the FlightGear developers (as was done with osgEarth), but instead discuss developments and integrate parts/infrastructure into the main repositories as you go.

This is pretty much what I was after when quoting Hooray. Some years ago a posted links to a YouTube video with a talk by Brian Fitzpatrick and Ben Collins-Sussman (both working at Google) about open source projects and poisonous people. One of the points are not working in a cave and dumb a huge patch over the wall and run, in essence instead doing just as bugman says above.

For those who have not seen the talk I can highly recommend it. I have seen many of the points in action over time already in the little parts of the community I try follow (in essence the forum and the wiki).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: "Advertising FlightGear"

Postby bugman » Thu Aug 27, 2020 10:15 am

@Hooray: A bite-sized project requires mentoring. But most open source projects, FlightGear included, cannot afford this. Mentoring works well on small projects with many core developers. But here that will never work. There's just so much to be done. Even if we had 50 active core developers, I don't think there would be time for such intensive mentoring. That is why you get people making monster code dumps (which often require too much effort to bring into a reasonable shape to merge). The FlightGear core developers simply cannot mentor new contributors at this level.

On the other hand, writing tests does not require all the infrastructure to already be there. You learn and code by copying what is already there. For example writing a route manager test is a piece of cake now - just open test_suite/unit_tests/Navaids/test_routeManager.cxx and test_suite/unit_tests/Navaids/test_routeManager.hxx and create a new RouteManagerTests::test*() function, copying from what is already there. And with good communication on the mailing list, required testing infrastructure can be added as needed.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: "Advertising FlightGear"

Postby Hooray » Thu Aug 27, 2020 3:39 pm

right ... in a perfect world :wink:
You're preaching to the choir: But you can obviously look up the number of active/new core developers and their commit/posting history to see if they used your secret backdoor (or not) :D
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Advertising FlightGear"

Postby icecode » Thu Aug 27, 2020 4:42 pm

On the other hand, writing tests does not require all the infrastructure to already be there. You learn and code by copying what is already there. For example writing a route manager test is a piece of cake now - just open test_suite/unit_tests/Navaids/test_routeManager.cxx and test_suite/unit_tests/Navaids/test_routeManager.hxx and create a new RouteManagerTests::test*() function, copying from what is already there. And with good communication on the mailing list, required testing infrastructure can be added as needed.


I don't think writing tests is a good way to lure new contributors. I'd argue writing tests is the most boring part of software development, and FG has very few people (if any) actually contributing to the project as part of their work. That's just my opinion though.

I think the best way to get familiar with the FG codebase, or any codebase, is to fix bugs. It's also kind of satisfying and gives new contributors a sense of accomplishment. Bugs can also open up to bigger sized projects. They could discover that a particular bug can only be fixed by reworking a specific FG subsystem, consequently contributing new features to the sim as a result of their bug hunt.
icecode
 
Posts: 709
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: "Advertising FlightGear"

Postby Hooray » Thu Aug 27, 2020 7:07 pm

As usual, telling newcomers to write tests in order to become core commiters is just another form of "Dit que le mieux est l'ennemi du bien." ;-)

For exactly the same reason, pie-in-the-sky efforts like HLA/RTI, FGPythonSys or the Qt5 UI have a long-standing multi-year history of killing off other efforts, despite nothing tangible really materializing

(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 )
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: "Advertising FlightGear"

Postby Johan G » Thu Aug 27, 2020 9:03 pm

Hooray wrote in Thu Aug 27, 2020 7:07 pm:[...] despite the OSG port never having been completed [...]

And that was more than a decade ago...
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: "Advertising FlightGear"

Postby bugman » Thu Aug 27, 2020 10:10 pm

Icecode GL wrote in Thu Aug 27, 2020 4:42 pm:I don't think writing tests is a good way to lure new contributors. I'd argue writing tests is the most boring part of software development, and FG has very few people (if any) actually contributing to the project as part of their work. That's just my opinion though.


For a non-developer, or someone not knowing C++, it's a quick way to learn via copy and paste. For example:


Simply copy and paste that function, rename it, make a complex flight plan, then check the result using the code that you pasted.

I think the best way to get familiar with the FG codebase, or any codebase, is to fix bugs. It's also kind of satisfying and gives new contributors a sense of accomplishment. Bugs can also open up to bigger sized projects. They could discover that a particular bug can only be fixed by reworking a specific FG subsystem, consequently contributing new features to the sim as a result of their bug hunt.


This is a good way as well. But you should first enquire about bugs, as some are easy and some are hell. For example for the particles and precipitation bugs from back in 2016 that helped me dive into the FG internals. That bug was insanely complex to find - and it took a long time to explain to James and the others what the issue was. Such bugs would turn off most potential developers. So some initial feedback from developers, stating that you want to do it yourself, would be helpful.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: "Advertising FlightGear"

Postby bugman » Thu Aug 27, 2020 10:40 pm

Hooray wrote in Thu Aug 27, 2020 7:07 pm:As usual, telling newcomers to write tests in order to become core commiters is just another form of "Dit que le mieux est l'ennemi du bien." ;-)


Not at all. I have very good experience with that with my own software projects. It resulted in a very high user to developer conversion! As a side note, I have a rule that you must first write a system, functional, GUI, or unit test prior to writing any code - otherwise the commits will not be accepted (the nature of my projects is that there is a lot of unnoticed bit-rot, and I have 100% test coverage).

For exactly the same reason, pie-in-the-sky efforts like HLA/RTI, FGPythonSys or the Qt5 UI have a long-standing multi-year history of killing off other efforts, despite nothing tangible really materializing


I'm not so sure:

  • HLA/RTI, I'm not sure about. But I'm pretty sure that didn't kill anything though.
  • FGPythonSys was an experiment. I got a lot from it (learning C++, learning the bare-metal internals of Python and its C interface, learning FG internals). And the project benefited by receiving the test suite infrastructure I developed for it.
  • Qt5 UI is not dead. There are just a lot of other things to do first. If it killed off any ideas for a Canvas GUI, I am quite happy about that. I do a lot of GUI coding 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.

(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 ;)

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Check your facts buggy ;-)

Postby Hooray » Sat Aug 29, 2020 12:11 pm

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 :lol:


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%20status


bugman 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 :D

Open the property browser/performance monitor and see for yourself, it nicely shows up there - and guess what it's called there: "CanvasGUI" :lol:

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&#p288924p288906

Later on, I actually even went further, and shared patches to completely remove PUI at build time: http://wiki.flightgear.org/FlightGear_a ... abling_PUI

I 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:

Image

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_Handling
Image

And 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):

Image

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 :lol:

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.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Check your facts buggy ;-)

Postby bugman » Tue Sep 01, 2020 10:23 am

Hooray wrote in Sat Aug 29, 2020 12:11 pm: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 ?


May I respectfully say that this is rubbish. These are not from my experiences. These 'lessons' are directly from the highly respected book Producing Open Source Software. I applied what I read in that book and, not surprisingly, it worked surprisingly well!


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.


There is no form of this type of suggestion in the book. It probably won't work.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: "Advertising FlightGear"

Postby icecode » Tue Sep 01, 2020 10:44 am

A quick look at the book you posted suggests that the author only worked on very successful open source projects with tons of manpower available (see https://producingoss.com/en/sources.html).

I don't think you should judge suggestions on whether they appear on the book or not. Likewise, I don't think the book holds eternal wisdom about every open source project that has ever been created. It might provide useful general advice, but that's it. FG is a special project with its own quirks, i.e. we can't apply the same rules as the people at the Linux kernel or the Apache HTTP server.
icecode
 
Posts: 709
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Check your facts buggy ;-)

Postby bugman » Tue Sep 01, 2020 10:49 am

Continuing:

Hooray wrote in Sat Aug 29, 2020 12:11 pm:
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 :lol:


This is wrong. Apart from threaded Nasal Garbage Collection, there is pretty much nothing to gain from threading. As far as I am aware, most systems are GPU-limited or Terrasync-download-limited, not CPU-limited. And for those, threading is not a magical answer. Threading, if introduced, is not guaranteed to even make things faster. But it is guaranteed to introduce dead-locks and nasty racing all over the place. And note that a thread-safe property tree with locking for all operations will be a lot slower and likely introduce a big CPU bottleneck!


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%20status


bugman 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 :D


The canvas GUI you speak of is not a replacement for the current PLIB GUI (PUI) that all users interact with. No core developer wants to see a Canvas replacement for the PUI. Every core developer is in agreement that PUI will be replaced by Qt Quick and the QML markup language - that was discussed at length and enshrined in the FlightGear Policy and Roadmap Document. No core developer wants the burden of maintaining our own FG specific GUI toolkit, as all core developers are acutely aware that fully-fledged GUI toolkits are monsterous. You may wish to see that Canvas replaces all, but that is not at all where the project is heading. Not even dissenting voices are considering forking the FlightGear project to create an internally maintained Canvas-based GUI to fully replace the current PUI.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 6 guests