Board index FlightGear Development

Announcing FFGo: a new FlightGear launcher

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.

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Feb 05, 2016 12:49 pm

pommesschranke wrote in Fri Feb 05, 2016 8:06 am:yes. I'm looking forward to it. then it will be very easy to see which aircraft I never tried.

Correct.
pommesschranke wrote in Fri Feb 05, 2016 8:06 am:I have another feature idea:
one ~/.ffgo/apt file for each FG Version.

I am a bit reluctant to make this depend on the FG version, because for instance 2016.1.0 is a different thing for each combination of FG, SG and FGData commits. But if I understand your needs well enough, we should be able to come up with a satisfactory solution.

I suspect your main problems are:
  • being able to programatically change FFGo's settings for --fg-root, --fg-scenery, FG_BIN and FG_AIRCRAFT depending on the installation you want to use (maybe also FG_WORKING_DIR);
  • avoid the automatic rebuild of ~/.ffgo/apt whenever FFGo sees it has been built from a differently-timestamped apt.dat.gz.
But I don't think you have a particular desire to maintain completely separate configurations for these FG installations (most notably the part corresponding to the Options Window---below the INTERNAL OPTIONS ABOVE. EDIT CAREFULLY! line of ~/.ffgo/config). Right?

In this case, what would be really needed is a way to programmatically choose a particular file to use for the role of ~/.ffgo/apt (“apt digest file”, aka “airport database” in FGo!-speak). This would be easy, except there is a small complication because ~/.ffgo/apt works in conjuction with ~/.ffgo/timestamp, which contains the timestamp apt.dat.gz had when ~/.ffgo/apt was built (this is inherited from FGo!). I don't like this coupling much, and it would add confusion if we had to have ~/.ffgo/apt-suffix and ~/.ffgo/timestamp-suffix for several suffixes corresponding to your various FG installations (let's release the word: profiles).

I think the way forward would be make a tiny change to the format of the apt digest file so that its header includes a hash (SHA512 or something like that) of the apt.dat.gz file from which it was built. This way:
  • the apt digest file is self-contained (nor need for a separate timestamp file to be able to tell whether it needs to be rebuilt);
  • it won't be uselessly rebuilt if for some reason apt.dat.gz had its timestamp changed but not its contents. And if I run the hash function on the decompressed contents of apt.dat.gz, that would even not be fooled by identical apt.dat files compressed separately (the .gz format includes a timestamp, therefore compressing two identical files yields different .gz files unless you play tricks with your system clock).
If this way works for you, FFGo could offer a --ffgo-apt-path option to select the apt digest file to use; then I could post a Python 3 script I use here to manage different FFGo “profiles” that would handle all the rest:
  • modifications of your choice to each variable you want above the INTERNAL OPTIONS ABOVE. EDIT CAREFULLY! line of ~/.ffgo/config;
  • setting up a custom environment (for instance, LD_LIBRARY_PATH, but you could also put FG_AIRCRAFT and any others there---personally, I prefer managing the aircraft paths with FFGo's FG_AIRCRAFT setting, but it is really mapped to FlightGear's --fg-aircraft option, thus you can use the FG_AIRCRAFT environment variable at the same time, with the same precedence order as used by FlightGear);
  • possibly passing specific options to FFGo;
all this depending on the profile, chosen with a command-line argument. I used that to switch between FG 3.4 and FG from Git next, but now I mostly use it to switch between a “normal” build from Git next and a debug build that would be too slow for flying. But you can have as many profiles as you want.

If that would work for you, I could plan it once I've finished with the current things (aircrafts/airports “use count”, and maybe a slightly smarter aircraft search). Of course, if you really need completely separate FFGo configs, it would be very easy to add a command-line option making FFGo use whatever directory you want instead of ~/.ffgo, but I suspect this would be suboptimal.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sat Feb 06, 2016 7:01 pm

I have pushed to the Git repo the first step towards the “aircraft use count” feature: the aircraft chooser(*) logic is now all located in an AircraftChooser class derived from the same base class (IncrementalChooser) as the AirportChooser class. This means that the aircraft list has gained the following properties:
  • smarter automatic selection of an aircraft when the search query is changed, based on the new search query and the previous selection (see below);
  • better handling of navigation keys (up and down arrows, Page Up and Page Down, Home and End; most notably, holding down one of the first four of these, and pressing one of the last two should have the expected effect);
  • ability to display several proper columns of data and to sort by clicking on a column header (there is currently only one visible column: the aircraft name; a second column displaying the “aircraft use count” will be added soon);
  • short delay before starting to search after the search query is modified, in order to allow smooth typing with good visual feedback in the search field, even if updating the list can't follow the pace at which the search query is changed.
Apart from maintainability obviously, these are the basic things we gained from using the same base class as for the airport chooser.

I also customized the AircraftChooser class a bit more on top of this to offer approximate matching of aircraft names. Basically, you don't have to remember that the 'f-14b' aircraft has a hyphen in its name, as well as the 'EC-137D', but not the 'ec130b4' nor the 'ec135p2'. Characters such as hyphen, underscore, period, colon, semicolon... even space are simply ignored during the first phase (filtering) of an aircraft search. This means that an aircraft search query can find an aircraft even if it has hyphens, underscores, etc. missing or in excess compared to the actual aircraft name.

This is for the first phase of an aircraft search (after each effective change to the search field): updating the displayed list to contain only the aircrafts that match the search query. The second phase, almost identical to what happens in the airport chooser, is the automatic selection of the “best match” among the matching aircrafts. This phase doesn't use approximate matching, but case-insensitive exact matching. I'll explain this with a little example here. For a more formal explanation, see the relevant commit log.

So, let's say the currently-selected aircraft is 'c172p' and I type “alouette” in the aircraft search field of FFGo's main window. The list is automatically filtered to display the following aircrafts (on my system):
Code: Select all
Alouette-III_sc
alouette2
alouette2
alouette2-easy
alouette2-pro
alouette2F
alouette2F-easy

(I have two 'alouette2' aircrafts: one from FGAddon and the other from an external hangar)
The selected aircraft becomes 'Alouette-III_sc' (first matching aircraft) because:
  • the search query “alouette” is an exact (case-insensitive) match of none of the listed aircrafts, and;
  • the previously-selected aircraft, 'c172p' (assuming I typed the search query “alouette” fast enough so that the aircraft list updating wasn't triggerred before the search query was fully entered) is not among the matching aircrafts.
Now, let's click on the header of the Aircraft name column. The list of matches gets reversed, yielding this:
Code: Select all
alouette2F-easy
alouette2F
alouette2-pro
alouette2-easy
alouette2
alouette2
Alouette-III_sc

This didn't change the selected aircraft, which is still 'Alouette-III_sc'. Now, if we just append “2” to the search query (making it “alouette2” instead of “alouette”), then 'Alouette-III_sc' gets removed from the list and we now have two exact matches with the same name ('alouette2'). The first one is automatically selected. This means you generally don't have to click when you type the exact aircraft name, disregarding the case (I used “generally” here, because in the case of several identically-named aircrafts, as we have here for 'alouette2', the search query is not sufficient to distinguish between them—you have to check the aircraft tooltip to make an informed choice).

If, instead of changing the search query from “alouette” to “alouette2”, we had made the following change: “alouette” -> “alouette-2”, then 'Alouette-III_sc' would have been removed just as well from the list, but in the absence of any exact match, the automatic selection would have chosen the first approximate match: 'alouette2F-easy'. And of course, removing the hyphen in the search query to make it “alouette2” would then cause the first 'alouette2' exact match to be selected.

This may sound a bit complicated when explained in textual form, but should be very convenient and intuitive when you give it a try. At least, that's what I hope. :wink:

(*) Treeview widget for the list + Entry widget for the search field + “Clear” Button
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Mon Feb 08, 2016 3:31 pm

I just want to report, that your site seems to be down (no response). Also I can't "apt update" anymore...
Last edited by chris_blues on Tue Feb 09, 2016 3:28 pm, edited 1 time in total.
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Feb 09, 2016 9:35 am

Yes, I have seen that... It seems to be back up again. I hope this server will be more reliable in the future...

The apt repository is on the same server (people.via.ecp.fr), so no wonder both the home page and apt repository were down at the same time. If someone has a server with rsync access, I can add a line to my upload script to synchronize a mirror...
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Feb 11, 2016 3:14 pm

I have pushed the “aircrafts and airports use counts” feature to FFGo's Git repo. I am going to make the four periods configurable from the Settings dialog (see below) and change the default sort order for the airport and aircraft lists, but apart from these minor things, the feature should be complete as it is.

For native English speakers: I have a hard time finding a correct formulation for this kind of thing (these ones being tooltip texts):
Number of days for which the aircraft has been used at least once during the “aircraft stats show period” (cf. Preferences dialog)

Number of days for which the airport has been visited at least once during the “airport stats show period” (cf. Preferences dialog)

(ah, maybe “in which” would be better than “for which”, for a start---but that's what is in the Git repo for now) I have also considered:
The aircraft has been used at least once a day for that many days during the “aircraft stats show period” (cf. Preferences dialog)
(and similar formulation for airports) but I am not sure it is really better. Do you have better suggestions?

Because there are interesting use cases that require different periods over which to compute the number of days an aircraft (resp. airport) has been used (resp. visited), I made all four periods configurable (excerpt from my ~/.ffgo/config file):
Code: Select all
AIRCRAFT_STATS_EXPIRY_PERIOD=3652
AIRCRAFT_STATS_SHOW_PERIOD=365
AIRPORT_STATS_EXPIRY_PERIOD=3652
AIRPORT_STATS_SHOW_PERIOD=365
(these are the default values for these parameters)
As you can guess, this means that FFGo will keep the dates where you used each aircraft (resp. visited each airport) for 10 years (3652 days), and compute the “use/visit count” for each aircraft/airport over the last year only (365 days). For now, these values can only be changed via the config file, but they should be soon accessible from the Preferences dialog.

It was necessary to at least make the {AIRCRAFT,AIRPORT}_STATS_SHOW_PERIOD values configurable, because in order to easily see the aircrafts you currently use most, you would need a short period for counting (say, 3 months to 1 year), whereas if you want to easily see the aircrafts you have never used, or the airports you have never visited, a longer period is necessary (a period of 36525 days, which is approx. 100 years, should be enough for such a use case). As these two periods were being made user-configurable, I decided to make the expiry periods user-configurable too.

As promised, the aircraft and airport “use counts” are displayed in new columns of the aircraft and airport lists, respectively. Clicking on the appropriate column header is enough to sort a list according to these values. Clicking a second time on the same column header reverses the sort order.

For the curious, the data is stored in $USER_DATA_DIR/Stats/airports.json.gz and $USER_DATA_DIR/Stats/aircrafts.json.gz, where $USER_DATA_DIR is of course ~/.ffgo everywhere except on Windows, where it is %APPDATA%/FFGo (i.e., it is the folder where FFGo's main config file is located). If you delete these files, they will be automatically recreated.

If you start FFGo with an aircraft or airport list that doesn't contain an entry for each element of the corresponding .json.gz file, the elements that can't be used by FFGo will be kept in memory and saved back to the .json.gz file when FFGo is quit or its config reloaded. So, there shouldn't be any risk of losing aircraft or airport “use/visit dates” just by removing/changing aircraft paths, or using an apt.dat.gz file that doesn't have all airports you previously had. Of course, if aircraft (name, path) pairs, or airport ICAO codes don't match, the resulting use counts won't be visible in FFGo's interface, but they will remain in the .json.gz files. Therefore, in case of a permanent change in, e.g., an aircraft path and/or name, for which you want to keep your use dates, you can do the renaming yourself in the $USER_DATA_DIR/Stats/aircrafts.json.gz file.

Which leads me to how the data is actually stored (sample airports.json.gz file):
Code: Select all
{"format version":1,"airports":{"LFLS":[735998,736003],"EDDH":[735999,736001,736003,736004],"LFPO":[736003,736004,736005],"EDDF":[736004],"LOWI":[736003,736005],"EDDS":[736004],"EDDG":[736004],"LFOH":[736004],"LFML":[736005],"LSZS":[736003]}}

Hardly readable, eh? But this should be very fast to read for the computer. Fortunately, for you poor human being, it is possible to call FFGo with the --save-stats-in-pretty-form option; then, either quit FFGo or reload its config file (aka “reset” in FGo!-speak), and $USER_DATA_DIR/Stats/airports.json.gz will be written this way instead:
Code: Select all
{
    "airports": {
        "EDDF": [
            736004
        ],
        "EDDG": [
            736004
        ],
        "EDDH": [
            735999,
            736001,
            736003,
            736004
        ],
        "EDDS": [
            736004
        ],
        "LFLS": [
            735998,
            736003
        ],
        "LFML": [
            736005
        ],
        "LFOH": [
            736004
        ],
        "LFPO": [
            736003,
            736004,
            736005
        ],
        "LOWI": [
            736003,
            736005
        ],
        "LSZS": [
            736003
        ]
    },
    "format version": 1
}

Looks better, doesn't it? But what are those funny numbers? Well, they are called proleptic Gregorian ordinals and should be the fastest format IMHO to compute the use counts from the saved dates, for the chosen period (for instance, at FFGo startup). It is pretty simple, actually: January 1 of year 1 corresponds to the integer 1, January 2 of year 1 to the integer 2, and so on. If you run:
Code: Select all
import datetime
print(datetime.date.today().toordinal())

in Python 3, you will find that today is number 736005. So, yesterday was 736004. You got it.

$USER_DATA_DIR/Stats/aircrafts.json.gz is in almost the same format. Here is an example obtained with the --save-stats-in-pretty-form option:
Code: Select all
{
    "aircrafts": {
        "707\u0000/mm/flightgear-data/fgaddon/Aircraft/707": [
            736004,
            736005
        ],
        "777-200ER\u0000/mm/flightgear-data/fgaddon/Aircraft/777": [
            736003
        ],
        "Citation-II\u0000/mm/flightgear-data/fgaddon/Aircraft/Citation": [
            736004,
            736005
        ],
        "SenecaII\u0000/mm/flightgear-data/aircrafts-misc/SenecaII": [
            736004
        ],
        "ZLT-NT\u0000/mm/flightgear-data/fgaddon/Aircraft/ZLT-NT": [
            736004
        ]
    },
    "format version": 1
}

As you can see, the general idea is the same, but in order to save the (aircraft name, aircraft directory) pairs as simple strings(*), I decided to separate the aircraft name and directory with the NUL character (\u0000) for maximum robustness. Thus, even aircraft names could contain spaces (or newlines or whatever) if FlightGear supported that...

Because of the expiry period, there is no risk of the lists getting bigger and bigger, eventually slowing down the FFGo startup. “Use dates” older than AIRCRAFT_STATS_EXPIRY_PERIOD days in the case of aircrafts (AIRPORT_STATS_EXPIRY_PERIOD in the case of airports) are automatically removed whenever FFGo is quit or its configuration reloaded. So, if you're an addict flyer and FFGo's startup seems to have gotten slower because of a huge number of entries (though I doubt it could be noticeable for any realistic use), just reduce the expiry periods, start and quit FFGo, and everything should be fine on the next startup.

The use counts are computed (from the dates) when FFGo is started, when its config is reloaded and when FlightGear is started from FFGo at the given airport, or with the given aircraft.

(*) This is the only type of key the JSON format supports in its “objects”---similiar to Python dictionaries.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby wkitty42 » Thu Feb 11, 2016 11:37 pm

rominet wrote in Thu Feb 11, 2016 3:14 pm:For native English speakers: I have a hard time finding a correct formulation for this kind of thing (these ones being tooltip texts):

make it easy on yourself... don't get too wordy... KIS principle...

Number of days for which the aircraft has been used at least once during the “aircraft stats show period” (cf. Preferences dialog)

Code: Select all
Number of days the craft was used during the selected period


Number of days for which the airport has been visited at least once during the “airport stats show period” (cf. Preferences dialog)

Code: Select all
Number of days the airport was visited during the selected period


(ah, maybe “in which” would be better than “for which”, for a start---but that's what is in the Git repo for now) I have also considered:

that extra verbiage is what makes it too wordy and convoluted... Keep It Simple ;)

The aircraft has been used at least once a day for that many days during the “aircraft stats show period” (cf. Preferences dialog)

Code: Select all
The number of days the craft has been used during the selected period


(and similar formulation for airports) but I am not sure it is really better. Do you have better suggestions?

dunno if the above helps but there it is...
"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: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Feb 12, 2016 2:58 pm

wkitty42 wrote in Thu Feb 11, 2016 11:37 pm:dunno if the above helps but there it is...

Yes, it does, thank you!

Screenshot of FFGo's main window using the new feature---here, sorting airports and aircrafts by their use/visit counts:
Image

The four periods can now be configured from the new Statistics tab of the Preferences dialog. The layout in there is not very nice yet, but I have to switch to whole dialog to the "grid" layout manager (instead of "pack") to fix this properly. So, we now have:
Number of days the aircraft was used during the selected period (cf. “Aircrafts statistics show period” in the Preferences dialog)

for the aircraft “Use count” column header tooltip in FFGo's main window, and:
The “use count” for each aircraft is the number of days it was used during the last n days, where n is the number entered here.

for the first Spinbox tooltip in the Preferences dialog, followed by:
FFGo automatically forgets about dates you used a given aircraft when they get older than this number of days.

for the second Spinbox tooltip, then:
The “visit count” for each airport is the number of days it was visited during the last n days, where n is the number entered here.

etc.

Does that sound correct?
(I'm always uncomfortable putting the “s” in “Aircrafts” in phrases such as “Aircrafts statistics show period”...)

Thank you!
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby wkitty42 » Fri Feb 12, 2016 9:19 pm

yeah, aircraft is both singular and plural... does one hunt deer or deers? ;)

if it is a possessive (eg: the aircraft's number of hours flown) then an apostrophe and an 's' are used... eg: “Aircraft's statistics show period”

on the last one, the visit count, it is just the number of days or the number of times the airport was visited in the last N days?
"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: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Feb 12, 2016 10:02 pm

Yes, I know the apostrophe rule, but it was a different thing. Anyway, this is not an English grammar forum :wink:, so, to answer your last question: it is the number of days---not times---the airport was visited during the last n days. For instance, assuming your airports statistics show period is 10 days and you visited VQPR 6 days during the last 10 days (maybe several times per day), it doesn't matter how many times you visited it before: the visit count for VQPR will be 6.

Edit: replace "6 times" with "6 days" and add the "(maybe several times per day)" for more clarity...

I chose this metric because it seemed for representative to me (if FG crashes, or you have setup troubles [customizing joystick bindings, etc.] and you restart several times at the same airport just because of that, it doesn't necessarily mean you like the airport that much compared to others). But this is subjective, and I'm open to modify it if this turns out not to be the best metric.
Last edited by rominet on Fri Feb 12, 2016 11:18 pm, edited 1 time in total.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby Hooray » Fri Feb 12, 2016 10:15 pm

Announcing FFGo: a new FlightGear launcher
rominet wrote:You have to choose one method and follow it until the end, asking at every step you don't understand.


Regarding all those installation instructions, you may want to consider moving them to the wiki, so that you don't have to deal with dozens of users separately :D
Besides, depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly: http://wiki.flightgear.org/FGPythonSys

http://wiki.flightgear.org/Python_in_FlightGear

Obviously, that would mean that FFGo's dependencies would need to be moved to the corresponding FFGo directory, because they would almost certainly not be available in a system-wide fashion.
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: Announcing FFGo: a new FlightGear launcher

Postby wkitty42 » Fri Feb 12, 2016 10:26 pm

rominet wrote in Fri Feb 12, 2016 10:02 pm:so, to answer your last question: it is the number of days---not times---the airport was visited during the last n days. For instance, assuming your airports statistics show period is 10 days and you visited VQPR 6 times during the last 10 days, it doesn't matter how many times you visited it before: the visit count for VQPR will be 6.

ok... i was trying to clarify between visiting VQPR more than once a day in that period... the wording seemed to indicate that more than one visit per day would count as "one day" in that period for that stat...
"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: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Feb 12, 2016 11:16 pm

wkitty42 wrote in Fri Feb 12, 2016 10:26 pm:ok... i was trying to clarify between visiting VQPR more than once a day in that period... the wording seemed to indicate that more than one visit per day would count as "one day" in that period for that stat...

... and this is the case. Sorry, the last example I gave (the one with VQPR) wasn't worded very well. It is not “assuming your airports statistics show period is 10 days and you visited VQPR 6 times during the last 10 days (...)”, but rather “assuming your airports statistics show period is 10 days and you visited VQPR 6 days during the last 10 days (...)”. So, your previous understanding was correct. Several visits per day at the same airport only count as one (and the thing that matters to determine if several visits are on the same day is the date: whether we are on Feb 12th or Feb 11th, etc.).

Frankly, I "designed" this for aircrafts, because IMO, it doesn't matter if you flew for instance the 707 once for a 3 hours flight on a given day, or 5 times during 30 minutes each time on the same day: you flew the 707 on that day, and the program will record this as 1 use count for the 707.

The principle of calculus is currently the same for airports, though maybe the rationale isn't so clear-cut in this case. One positive point is: if you start FG many times at the same place because of setup troubles, software crashes, etc. all this will be counted only once assuming it all happened on the same day. OTOH, for airports with challenging approaches, starting FG 5 times in a row at the same place because you enjoy practicing pattern flights there does mean something, and maybe should count more than just starting from the airport once and landing somewhere else. As said, it is not completely clear-cut for airports. :wink:
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sat Feb 13, 2016 1:20 am

Hooray wrote in Fri Feb 12, 2016 10:15 pm:Regarding all those installation instructions, you may want to consider moving them to the wiki, so that you don't have to deal with dozens of users separately :D

Hooray, thank you sooooooo much for volunteering to maintain FFGo's wiki page. :mrgreen:

More seriously, yes, I have thought about taking these instructions to turn them into some "quick guide" or similar. I am not quite sure the wiki is the right place, because in general installation instructions may depend on the particular version of the software to install (FFGo in this case). So, either the wiki instructions would have to be inaccurate, or they would have to be carefully written not to be confusing... For these reasons, the official installation guide is the docs/INSTALL/INSTALL_en text file that is shipped with every tarball/zip file, and all the rest is just sugar to help people get on track...

BTW, I haven't seen the dozen users you are mentioning yet... But I wrote the guide very carefully (for your delight, of course, and) to avoid having to do too much user support for the installation. And also because I hate people who pretend things are simpler than they actually are and “teach” you crap. For instance, I could make the instructions much simpler by just telling to run "python3 setup.py install" as root for FFGo and CondConfigParser. No need for pip, no need to learn what a virtual environment is, etc. That would probably work in most cases, but it is very ugly IMHO: there would be no simple way to uninstall or upgrade, and there would be a risk of mistakenly overwriting a system installation (of CondConfigParser, for instance). Many installation instructions are of this kind and just rely on users' knowledge to take the appropriate steps to be able to uninstall or upgrade, but I don't like that. pip allows one to do these things cleanly and easily if properly used, but as with most good tools (and despite current IT marketing trends), one has to learn a little bit to make good use of it.

Unfortunately, I have the impression FlightGear users don't have the patience (or will) to read detailed installation instructions. Probably one thing that would work better would be system-specific installation instructions, because these can be written in a less abstract and more straightforward way (no need to distinguish between so many cases...). This is a bit what I did in the messages you were referring to, because apparently chris is using Debian (and everything can be easily transposed to other linux distros if one knows how to use one's particular package manager). But such system-specific installation instructions don't sound very appealing to maintain (that would obviously be easier with a responsible “expert” for each concerned platform...).

(and the package could be in Debian, too; I had an upload offer from Markus Wanner, the FG maintainer... from there, it would probably flow to other distros such as Ubuntu)

Hooray wrote in Fri Feb 12, 2016 10:15 pm:Besides, depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly: http://wiki.flightgear.org/FGPythonSys

If properly done, this would certainly make installation easier. I haven't commented on bugman's work because I have no experience with embedding Python in another app, but certainly I like the idea of being able to use Python directly in FG. As many others, I have a bad intuition concerning the security implications if this were open to general aircraft scripting (even though I would love using Python instead of Nasal for that), but I haven't had the time to investigate this area as bugman apparently did, so no comment from me on this. However, it seems clear to me that, if this FGPythonSys were integrated into FG, doing things in Python that are directly committed to the core (properly reviewed---well, as the C++ code) as opposed to coming from various uncontrolled external places would certainly be pretty interesting, and in principle no more risky than doing them in C++ (bye bye to many buffer overflows, for one!).

The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&4 under Python 2&3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures).

(and I have tried other toolkits before Qt and Tk, namely GTK+ 1.2 and wxWidgets [around 2003] Bottom line: for me, Qt is the best)

One interesting thing that FGPythonSys could probably bring to FFGo would be, I think, FG-compliant parsing of aircraft data. For now, I haven't done that because I found that the interesting metadata (e.g., aircraft radius) is not necessarily in the -set file, but may be included from a different one. And maybe a correct parser for these things must also handle conditions in the XML data, etc. So, despite knowing the declared radius of parking positions, I haven't provided any hint yet in comparison to the selected aircraft's radius for these reasons (and lack of time).

Hooray wrote in Fri Feb 12, 2016 10:15 pm:Obviously, that would mean that FFGo's dependencies would need to be moved to the corresponding FFGo directory, because they would almost certainly not be available in a system-wide fashion.

Yup...

Thanks for your comments!
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Feb 14, 2016 10:37 pm

Hello,

I have uploaded FFGo 1.10.0rc1, which should be identical to the soon-to-be-released version 1.10.0, except for translations. It has all that I mentioned above, plus a few things. Most notably:
I'll write a more detailed description of the main changes when version 1.10.0 is released. In the mean time, you can always read the history on the Git repo. No Debian packages yet, will probably wait for the 1.10.0 release.

Since it is not a formally stable release, you have to pass the --pre option to pip in order to upgrade to this release. For instance, with a virtual environment located in directory <venv-dir>:
Code: Select all
<venv-dir>/bin/pip install --upgrade --pre ffgo

In some cases, such as Windows in typical configurations, without any virtual environment, the command can be reduced to:
Code: Select all
pip install --upgrade --pre ffgo
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Tue Feb 16, 2016 8:44 pm

Hello,

I am pleased to announce the release of FFGo 1.10.1 (shortly after version 1.10.0, because the new aircraft thumbnail handling code for non-standard sizes was using attributes only available in recent Pillow versions). The main changes since version 1.9.1 are listed below. The two major new features have already been described here, so feel free to skip the corresponding items. There it is:
  • Rebase widgets.AirportChooser on a generic, abstract class: widgets.IncrementalChooser.
  • Reimplement the aircraft chooser using widgets.IncrementalChooser. This improves its behavior in several respects:
    • smarter automatic selection of an aircraft when the search query is changed, based on the new search query and the previous selection;
    • better handling of navigation keys (up and down arrows, Page Up and Page Down, Home and End; most notably, holding down one of the first four of these, and pressing one of the last two should have the expected effect);
    • ability to display several proper columns of data and sort by clicking on a column header;
    • short delay before starting to search after the search query is modified, in order to allow smooth typing in the search field.
  • Aircraft chooser: approximate matching of aircraft names (feature already described in this message, which has a concrete, detailed example)
    • With this commit, you don't have to remember that the 'f-14b' aircraft has a hyphen, the 'EC-137D' also, but not the 'ec130b4' nor the 'ec135p2'. Characters in the following string are simply ignored during the first phase (filtering) of an aircraft search: ' -_.,;:!?' (the list starts with a space). This means that an aircraft search query can find an aircraft even if it has hyphens, underscores, etc. missing or in excess compared to the actual aircraft name.
    • Note that this only concerns the aircraft list filtering. Given a set of aircrafts that match the search query, one of them may be automatically selected after the aircraft list is filtered if:
      • it is either an exact (case-insensitive) match of the search query (and for this purpose, characters such as hyphens and underscores are not ignored: autoselection requires an exact match);
      • or it is the previously-selected aircraft (option only taken if the first one couldn't be satisfied, and of course if the previously-selected aircraft is in the just-updated, filtered list).
    • As said, both types of matching are case-insensitive:
      1. the approximate matching process used to determine which aircrafts will be displayed in the aircraft list after a change to the search field;
      2. the exact matching process used to autoselect the “best” among the matches found in 1), falling back to the first one if none of these fulfills any of the two conditions given in the previous paragraph.
  • Airport and aircraft statistics (“use counts” / “visit counts” for customizable periods)
    • New classes AirportStatsManager and AircraftStatsManager that are used to maintain lists of dates when each airport was visited (resp. each aircraft used).
    • Old data is automatically expired (new config file parameters AIRPORT_STATS_EXPIRY_PERIOD and AIRCRAFT_STATS_EXPIRY_PERIOD). Counts of how many days in a chosen period (new parameters AIRPORT_STATS_SHOW_PERIOD and AIRCRAFT_STATS_SHOW_PERIOD) each airport has been visited or each aircraft used are stored in memory and maintained by the AirportStatsManager and AircraftStatsManager classes. These counts are obtained from the dates of visit/use of each airport/aircraft by counting the dates selected with AIRPORT_STATS_SHOW_PERIOD and AIRCRAFT_STATS_SHOW_PERIOD.
    • AIRPORT_STATS_EXPIRY_PERIOD and AIRCRAFT_STATS_EXPIRY_PERIOD default to 3652 days (ten years). AIRPORT_STATS_SHOW_PERIOD and AIRCRAFT_STATS_SHOW_PERIOD default to 365 days (one year).
    • The Preferences dialog has a new Statistics tab allowing to configure these four parameters.
    • All the aircrafts use dates (resp. airports visit dates) are loaded from $USER_DATA_DIR/Stats/aircrafts.json.gz (resp. $USER_DATA_DIR/Stats/airports.json.gz) when FFGo is started(*), and saved to the same files when it is quit. It is also saved just before the airports/aircrafts set is possibly changed and reloaded afterwards in order to avoid losing data stored in the .json.gz files if it can't be applied to the current airports/aircrafts set.
    • Add a new column to the aircraft list showing how many days each aircraft has been used at least once (“use count”) during the period defined by AIRCRAFT_STATS_SHOW_PERIOD (which is interpreted as a number of days). Similarly, add a column to the airport list showing how many days each airport has been visited at least once during the period defined by AIRPORT_STATS_SHOW_PERIOD (again, number of days). The use (resp. visit) count for an aircraft (resp. airport) is incremented whenever FlightGear is started from FFGo with this aircraft (resp. at that airport). This is only done in memory until $USER_DATA_DIR/Stats/airports.json.gz and $USER_DATA_DIR/Stats/aircrafts.json.gz are saved, as mentioned above.
    • By default, these two .json.gz files are stored in the most possible compact format (no space or newline to separate syntactical elements in the uncompressed data stream). For users who would like to examine or even modify these files (for instance, in order to keep aircrafts use counts despite having changed one's aircraft paths), FFGo supports a new command-line option: --save-stats-in-pretty-form (pretty long, but I surmise it should not be needed often). Start FFGo with this option, then either do a reset (i.e., click on the “Reload config file” button) or quit FFGo; at this point, both .json.gz files should be in human-readable form.
    • This feature was presented in this message on the forum (which may have better/different explanations...).
  • Change the initial sorting of the aircraft and airport lists. These two lists in FFGo's main window are now initially sorted:
    • primarily, by decreasing use/visit count;
    • secondarily, by aircraft or airport name for aircrafts/airports having the same use/visit count.
    (it is still possible to click on a column header to change the sort order)
  • Fix loading of aircraft thumbnails:
    • fix a long-standing little bug (present in FGo!): aircraft thumbnails that don't have 171×128 dimensions are now displayed correctly (appropriately scaled to fit in the 171×128 space reserved for that). For maximum performance, this is bypassed for aircraft thumbnails that already have the desired dimensions. An aircraft for which the difference is very visible is the 707.
    • replace the catch-all “except:” clause with a more specific “except OSError:” one. If another type of error is raised in that place, it should be fixed where the actual problem belongs, instead of sweeping the whole thing under the rug.
  • Fix detection of the FlightGear version: debug builds of FlightGear have a different 'fgfs --version' output than normal builds, and that extended output wasn't properly recognized by FFGo.
  • Pass --fg-root when running 'fgfs --version' to avoid the new popup. FlightGear 2016.1.0 (from February 2016) can spawn an annoying popup dialog (if built with Qt support, I believe) when 'fgfs --version' is run, which is very confusing for FFGo users and broke FFGo's detection of the FlightGear version (this popup is apparently meant to let the user graphically choose the FG_ROOT path to use in the built-in Qt launcher). Pass the --fg-root option as well to work around this new behavior of 'fgfs --version' (assuming FFGo's FG_ROOT setting is non-empty, otherwise FlightGear version detection is not attempted).
  • Run 'fgfs --fg-root=... --version' in the directory defined by FG_WORKING_DIR (which can be configured from the Settings dialog). This is a good idea, as FlightGear has a nasty tendency to leave core files around, even when just trying to print the version...
  • Preferences dialog: use a Ttk Notebook widget instead of the home-made one. This will be better for maintainability, and hopefully is also an improvement regarding ergonomy and appearance on various OSes.
  • Preferences dialog: reimplement the whole dialog layout using the grid() layout manager instead of pack(). This allows to have proper horizontal and vertical alignments in the new Statistics tab. This should also make it easier to add things or make changes to the dialog in the future. Also replace Tk widgets with Ttk ones whenever there is a Ttk equivalent, and get rid of the 'from tkinter import *' wildcard import.
  • Enable automatic line wrapping in the About box. Otherwise, the box can get very large depending on the text we display inside...
  • Update the translated template config files ffgo/data/config/config_<language-code>.
    • Remove the --multiplay option from all templates: nowadays, most people should connect using the in-sim menu when they are ready (not on a runway, not on someone else's aircraft, and ready to answer to an eventual ATC operator, for a start). Other people can find the option on the FlightGear wiki or forum, as well as in the output of 'fgfs --help --verbose' anyway.
    • Update the French and German templates; both should now be up-to-date.
  • Update the German translation (thanks to chris_blues)

As usual, you can get this release from FFGo's home page. Debian packages for jessie and unstable are available from there, along with the distribution-agnostic tarballs and zip files.

(*) $USER_DATA_DIR is the '~/.ffgo' folder everywhere except on Windows, where it is '%APPDATA%/FFGo'.
rominet
 
Posts: 605
Joined: Sat Nov 01, 2014 2:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 8 guests