Board index FlightGear Support Compiling

FGRUN I think it's useful add it in a standard way

Building FlightGear from source, and in the need for help?

FGRUN I think it's useful add it in a standard way

Postby abassign » Tue Mar 10, 2015 4:22 pm

I compile the FGFS with the new script, but to have the FGRUN in necessary insert another command:

Code: Select all
./download_and_compile.sh FGRUN


But I noticed that to have "run_fgrun.sh", you must re-enter the compile command with parameter FGRUN.
As the command "run_fgrun.sh" is very comfortable and still small, I think it is better to include it among the standard programs (ALL parameter).
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: FGRUN I think it's useful add it in a standard way

Postby wkitty42 » Tue Mar 10, 2015 6:25 pm

when i compile with the given script, i use the following to get everything done...

Code: Select all
../dnc.sh -p n -j 8 OPENRTI SIMGEAR FGFS DATA FGRUN FGO OPENRADAR ATCPIE TERRAGEAR TERRAGEARGUI

i use that for the first compile... for later compile runs, i leave out FGO and OPENRADAR since they are wget downloads instead of repository updates...

i use "-j 8" because i have an 8-core CPU and i want it to use all 8 cores when compiling...

i use "-p n" because i don't need/want packages downloaded every time... after this recent update/split of the fgdata repo, i allowed packages to be updated so that i would get the Qt5 stuff and be able to use the new "fgfs --launcher"...
"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: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGRUN I think it's useful add it in a standard way

Postby F-JJTH » Sat Mar 14, 2015 1:35 pm

FGRun will be replaced by the built-in launcher in the next weeks, this is a known long term goal that's why FGRun haven't been improved the last 6 months and he won't be improved anymore.
By using FGRun you won't be able to use all the new features in the futur.

Kind regards,
Clément
User avatar
F-JJTH
 
Posts: 696
Joined: Fri Sep 09, 2011 12:02 pm

Re: FGRUN I think it's useful add it in a standard way

Postby wkitty42 » Sat Mar 14, 2015 5:39 pm

having started without any kind of launcher and then finding FGRun and now having played with the Qt5 launcher, i do hope that all the capabilities of FGRun are incorporated into the new one... i'm always getting bitten in the arse when i forget to specify something on the command line with the "--launcher" option... "--http=5500" being one of those... there are others... FGRun saves the last used options so the next time they are already set... i know you and others probably know that but it can be important when one finally gets their fgfs tuned the way they like ;)
"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: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGRUN I think it's useful add it in a standard way

Postby massima » Sat Mar 14, 2015 6:48 pm

I think FGRUN is perfect with a lot of option, but it could be simple to rewrite it using qt5 instead create from scratch a new one.
This is my opinion
User avatar
massima
 
Posts: 264
Joined: Sat Jan 03, 2015 7:48 pm
Location: Italy
Callsign: M-AXX
Version: 2020.4.0
OS: debian testing

Re: FGRUN I think it's useful add it in a standard way

Postby wkitty42 » Sat Mar 14, 2015 7:25 pm

massima wrote in Sat Mar 14, 2015 6:48 pm:I think FGRUN is perfect with a lot of option, but it could be simple to rewrite it using qt5 instead create from scratch a new one.
This is my opinion

it isn't just a rewrite from scratch... it is built into fgfs... not a separate executable... i suspect that when it is completed, "--launcher" will be removed and it will be the first thing you see when starting fgfs but i could be wrong about that ;)
"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: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGRUN I think it's useful add it in a standard way

Postby massima » Sat Mar 14, 2015 9:38 pm

Ok, we'll discover in the next release :mrgreen: .
User avatar
massima
 
Posts: 264
Joined: Sat Jan 03, 2015 7:48 pm
Location: Italy
Callsign: M-AXX
Version: 2020.4.0
OS: debian testing

Re: FGRUN I think it's useful add it in a standard way

Postby legoboyvdlp » Sat Mar 14, 2015 9:41 pm

Just in time for my birthday!! Lol. Are there pictures, wiki articles, etc about what we can expect?

Edit. Just found wiki article.
But does one need Qt5 installed, will qt5 come with fg, or will it not need qt5?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: FGRUN I think it's useful add it in a standard way

Postby wkitty42 » Sun Mar 15, 2015 2:02 am

legoboyvdlp wrote in Sat Mar 14, 2015 9:41 pm:Just in time for my birthday!! Lol. Are there pictures, wiki articles, etc about what we can expect?

Edit. Just found wiki article.
But does one need Qt5 installed, will qt5 come with fg, or will it not need qt5?

fgfs has to at least be built with Qt5... on my linux system, i don't recall any Qt5 stuff being installed when i first pulled fgfs 3.4.0 from the PPA where they (sorry, i don't recall his name as i'm still very new and learning everyone) had built 3.4.0 and then 3.4.1 with Qt5... when i started using the download_and_compile script, Qt5 was not installed on my machine so the --launcher option didnt work with my self-compiled 3.5.0... then some updates were made and i got a new copy of the script because of the fgdata split and that did install some Qt5 stuff on my box... i'm guessing that the installers will take care of what needs to be :)
"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: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGRUN I think it's useful add it in a standard way

Postby hamzaalloush » Tue Mar 17, 2015 9:11 pm

there is a QT5 thread that i'm writting about this very issue, there is a fix commited to master/next i think but needs to be merged into 3.4 immediatly. users with stable debian based distros and native QT5 libraries cannot compile yet.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: FGRUN I think it's useful add it in a standard way

Postby hamzaalloush » Tue Mar 17, 2015 9:17 pm

legoboyvdlp wrote in Sat Mar 14, 2015 9:41 pm:Edit. Just found wiki article.
But does one need Qt5 installed, will qt5 come with fg, or will it not need qt5?


3.4 will need, if you have system-side QT5 libraries, namely the qtbase5-dev package on Ubuntu that provides these QT libraries.

i still think FGRUN is ment to stay,,,

edit: at least if you compile stable FG from the brisa's download_and_compile script, you'll need QT, but it might still error compile even if your compiling by hand... but there's an QT conditional commit on Sourceforge's "next" for those without QT, but i'm not sure if it's merged yet into release/3.4
Last edited by hamzaalloush on Tue Mar 17, 2015 9:49 pm, edited 1 time in total.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: FGRUN I think it's useful add it in a standard way

Postby Hooray » Tue Mar 17, 2015 9:48 pm

fgrun is a separate tool, so can obviously be used just as well - and it is very likely that it will be much more complete than the Qt based launcher for at least 2-3 release cycles, which also applies to other polished front-ends, like for example FGx.

However, the mid-term idea is to phase out external launchers and provide built-in means to start up and configure FG using a simple UI.
Also, for the last few years, Gijs has basically been maintaining fgrun - and here's what he had to say about the future of fgrun in fgfs: http://sourceforge.net/p/flightgear/cod ... 1529/#cd07

Gijs wrote:FGRun will be gone with the next release of FlightGear, in favour of a built-in launcher that's built to work with the aircraft center. Therefore, I'm closing this issue to prevent anyone from spending a lot of time on fixing things in FGRun.


The other issue here being that the Qt launcher in its current form is implemented in a way that makes it only useful during startup, i.e. the current implementation basically kills the UI once the simulator has initialized. So it's not just a certain disparity features-wise, but the UI also won't be available at run-time, which may take another 1-2 release cycles to address.

Obviously, people can continue to use external launchers like fgrun/fgx still - but there are pretty strong advantages once a built-in launcher is properly integrated - so if/when, the Qt5-based UI will evolve, it is likely that external launchers will generally become obsolete for most purposes/end-users - which isn't such a bad thing actually, given the crazy number of FG GUI front-ends we have seen over the years.

Keep in mind that an external launcher like fgrun will also eat up resources while FG is running - while an integrated solution could be much more efficient.
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: FGRUN I think it's useful add it in a standard way

Postby hamzaalloush » Tue Mar 17, 2015 9:55 pm

i applaud this effort by Gijs, but i still think users should be able to use external tools as well, as you have confirmed now thankfully.

since QT is bieng agreed upon to be the launcher for FG accross platforms, does this mean it will merge into FG as well?? i think Canvas is much better for menu since we are using built-in framework.

not to mention other QT dependance and maintanance issues.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: FGRUN I think it's useful add it in a standard way

Postby hamzaalloush » Tue Mar 17, 2015 9:57 pm

Hooray wrote in Tue Mar 17, 2015 9:48 pm:Keep in mind that an external launcher like fgrun will also eat up resources while FG is running - while an integrated solution could be much more efficient.


i currently use optirun command on the fgrun executable successfully with bumblebee, and the GPU is used throught the FG sessions.

there might be more little details that i do not know about for performance which are valid, but up until now fgrun is good for me.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: FGRUN I think it's useful add it in a standard way

Postby Hooray » Tue Mar 17, 2015 10:27 pm

Well, we did have a long discussion about Qt5 which covered most points (do a forum search for "Qt5" if you want to learn more).

The thing is, the whole step is long overdue - and for FG it is a huge improvement. FlightGear has become a fairly sizable code base, with tons of legacy code, while making very little use of modern frameworks/libraries. Accepting Qt5 as a general dependency would be a huge shift in thinking, and it could help improve/modernize the FG architecture significantly.
However, it's a tedious process, too - i.e. updating all the legacy code accordingly and getting rid of old cruft in the process.
And so far, there's only a single core developer pursuing this. And looking back in time, we've seen similar efforts that ultimately turned out to be too tedious to be accepted by the wider communtiy of contributors, so that such efforts would ultimately turn out to be merely "experiments" - and "iterations" of a process to arrive at a completely different solution.

Regarding the run-time GUI, that stuff is currently being prototyped - so we will see how this evolves.
The thing is, Canvas is hardware-accelerated and works pretty well - but it is also entirely "custom", i.e. a niche solution - not unlike Nasal scripting, and not unlike the package manager currently being developed. FlightGear already contains tons of half-baked "custom" solutions all over the place, which more often than not meant a "technology lock-in" for the remaining team of active core developers - because people tend to believe in hugely different approaches and technology stacks.
Overall, Canvas -and even the new mongoose/httpd web GUI (Phi)- almost certainly would not have been implemented, had Qt been accepted as a dependency years ago.
And FG as a whole is a legacy code base that contains so many components that would frankly be obsolete by accepted Qt5 now - but this could also provide a "chance for change".

Maintenance is generally a no-brainer once you adopt an industry standard like Qt5 or OpenSceneGraph.
In fact, had a language like Perl, Python or Lua been used instead of Nasal for FG scripting, we would not be having certain issues right now.

Regarding Canvas vs. Qt5 in particular: it really depends on what you have in mind - Anything solely Canvas-based can also be "recursively" supported, i.e. dialogs showing instruments or vice versa - equally, dialogs could show HUDs, while HUDs could show dialogs and so on. Accepting Qt5 as an official build time dependency could provide plenty of options, but would be akin to using a Ferrari sports car to patch up your VW beetle ... and especially people familiar with C++ coding will be quite aware of the impact Qt has, i.e. it being easily much more complex than FG as a whole.

Then again, there are overlapping efforts - the Aircraft Center is entirely Canvas based and could be trivially extended to also provide the exact same functionality that the Qt5 launcher is now providing - in fact, we have seen patches doing exactly that - and the very core developer who is now working on Qt5 support, was also contemplating to use Nasal/Canvas for these purposes: http://wiki.flightgear.org/Initializing_Nasal_early

In the long term, FG would be better off by being modernized through accepting dependencies like Qt5, even though this may certainly be a major inconvenience for other contributors - not unlike the original OSG port/migration in early 2006 was. In the mid-term, it isn't unlikely that Qt5 "inclusion" will be up for debate - even if all active core developers would spend 90% of their time working out how to integrate Qt5 into FG, we would still only be using a tiny fraction of Qt in FG, while still requiring the whole shebang to be installed/built for compilation.


Regarding fgrun: tools like "optirun" don't have any impact on fgrun's memory occupancy while fgfs is running, so memory used there won't be available to fgfs
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


Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest