Installing it on Windows should create an ffgo-noconsole.exe executable (typically in C:\PythonXX\Scripts) that doesn't open any terminal window (“console”) when run. Does it work for you? Of course, in the hopefully rare cases where FFGo wouldn't start, you would have to look at the log file, and in case it couldn't even be written, run ffgo.exe to see the terminal output.

This version also has a Test stuff entry in the Tools menu. When you select it, you should see a window displaying messages containing Unicode characters, some of which are not in the CP-1252 character set you reported yesterday. I think this should work because it is printed in a non-console window. Of course you need to have fonts installed that can display these characters (Simplified Chinese and a few mathematical characters).

Unfortunately, this doesn't really go through the normal translation process, because the output you posted yesterday seems to indicate that gettext.py doesn't consider your en_GB.cp1252 locale to be compatible with the English UTF-8 “translation”. In your case, English is used as a fallback, not because your locale starts with "en"... So, I don't think it would work for someone using a non-English locale in this encoding (they would get English). But CP-1252 is a legacy Windows thing, so...

I am pleased to announce the release of FFGo 1.9.0. The main changes in this release are:

Use the new airport chooser (widgets.AirportChooser) for the airport list in the main window. The airport list in the main window used to be a simple list; replace it with a real multicolumn widget (Ttk Treeview), reusing the logic already implemented in widgets.AirportChooser. This fixes small alignment problems in the previous implementation (due to the ICAO codes not having the same display width), allows one to sort the airport list by ICAO code or airport name, in ascending or descending order, with a simple click on the relevant column header, and brings the nice logic from widgets.AirportChooser to the main window airport list (such as preferring an exact match on ICAO code when there are also substring matches on airport names for a given search string).

The airport chooser has also been modified to better handle navigation keys (Up and Down arrows, Page Up and Page Down, Home and End). Most notably, holding down one of the first four mentioned here should work as expected (this might need some tuning, because the thing is to delay the time-consuming task of updating everything that depends on the selected airport enough so that Tk has sufficient time between two consecutive “arrow-pressed” keyboard events to refresh the GUI---please report if that doesn't work for you in an airport list [the aircraft list still has this little problem when an arrow key is held down, I know]).

New GPS Tool dialog (cf. screenshot below) allowing one to find the distance, initial and final bearings for the shortest path between two given airports. This dialog should be more convenient than the Airport Finder dialog for the cases where you already know the start and destination airports you are interested in, and you just want to get the results for these airports. Or you want to check several pairs of airports, and you know precisely which ones you want the calculations to be done for.

The dialog also computes the flight duration for a given ground speed, and vice versa. It reuses the AirportChooser widget already used in FFGo's main window and in the Airport Finder dialog.

New setting: “Automatically scroll the Output Window”. Add a checkbox to the Miscellaneous tab of the Preferences dialog to control whether FFGo should automatically scroll the FlightGear Output Window to the end whenever new text is received from FlightGear's stdout or stderr stream. This corresponds to the config file parameter AUTOSCROLL_FG_OUTPUT. (feature request by pommesschranke/d-laser)

Add option to translate --parkpos into --lat, --lon and --heading. This option can be enabled using the “Fake the --parkpos option” checkbox found in the Miscellaneous tab of the Preferences dialog. It is useful when --parkpos is broken in FlightGear (which is currently the case in the 'next' branch of FlightGear's Git repository).

Fix bug preventing FFGo from starting when there was no translation file for the current locale (thanks to legoboyvdlp for the report).

Add missing 'tkinter.messagebox' import for 'showerror' in ffgo/fgdata/parking.py. The problematic code could only be reached when FFGo opens an erroneous groundnet file. Problem was: the error reporting could not be done properly.

Fix two options from the Preferences dialog whose lastest-updated values were used by FFGo even if the dialog was closed with Cancel. These are the 'Remember the main window position' and 'Automatically scroll the Output Window' options.

Airport Finder: display an explanatory error message when the user chooses an airport that is not present in FFGo's main window due to the fact that the “Show installed airports only” option (from the Settings menu) has been enabled.

Hide item-specific tooltips when the underlying List or Treeview is scrolled. Once a list or Treeview is scrolled, item-specific tooltips are likely not to match the item under the mouse pointer anymore. For this reason, hide the item-specific tooltip whenever each of the following Lists or Treeviews is scrolled: aircraft and airport lists in FFGo's main window; “reference airport” chooser and results table in the Airport Finder dialog (the GPS Tool dialog has never had this little problem AFAICT).

Main window: set the initial focus in the airport search entry. I think this is the most useful thing to do in general.

Add a colored, disabled (i.e., not clickable) and empty header to the carrier popup menu. This makes it more visible, visually similar to the runway and parking popup menus, and avoids it disappearing in a flash with the first entry being accidentally selected (i.e., 'carrier = None', return to airport mode) if the user just clicked without holding the left mouse button down.

Update the German translation (thanks to chris_blues)

Screenshot of the new GPS Tool dialog:For those who don't know, there is also a screenshots gallery on FFGo's home page.

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.

Good, thanks. There is still one minor thing that most likely doesn't work on Windows at the moment: it is the Open Log Directory button at the bottom right of FFGo's main window. In order to fix this little inconvenience, I need a working command line to do this. Can you please confirm that running:

in a terminal (obtained by running cmd.exe) opens the log directory? If not, maybe %APPDATA%/FFGo/Logs must be put inside double quotes. Or maybe one has to replace the slashes (/) with backslashes (\), but I don't think this one is necessary.

Hmm, I am very surprised by your results. %APPDATA% should be expanded in Windows “shells”, that is the syntax for variable expansions in this language as far as I know, and the Internet is full of examples of people doing just that, with screenshots. Moreover, I think you are confused by this (misleading) APPDATA: while the variable is supposed to expand to "C:\Documents and Settings\$USER\Application Data" on XP, on Vista and Win7 it is supposed to rather expand to "C:\Users\$USER\AppData\Roaming". Right, it is inside a folder named AppData (not "Application Data", BTW), but it is not a folder named AppData (cf. http://answers.microsoft.com/en-us/wind ... 8960423ce3 and http://superuser.com/questions/312136/h ... 952_312154 for instance).

Anyway, I uploaded version 1.9.1.dev2 which uses a different method (os.startfile()) that doesn't require to know the path to Explorer.exe and should not even start a new Explorer process if one already exists, according to what I read. I also added an OS X-specific code path that uses "open" instead of the "xdg-open" command used on other non-Windows systems, if someone wants to test there also.

I just decided, that I am too lazy and inexperienced with Python3 and pip and all that, so I'll switch to the debian repository. Now, all I'm missing is the key to verify the packages(key C785B90B5053A3A2). Apt is really annoyed! Where can I get it? Maybe a hint on the Homepage would be nice too...Many ppa's provide their keys in a keyring deb-package inside their repo.

[dependencies problem resolved - my mistake]

This is, because FFGo or Python3 or whatever refuses tu build/update my copy of FFGo. So I thought, maybe I did sth stupid to my copy (No idea what I possibly could have done. Never touched this dir...)

I see you have deleted some parts of your first message. But since I had already written the corresponding replies, and they contain many details that I hope may be helpful to you or other people, I'll include them and reply to them anyway. I hope you don't mind.

I just decided, that I am too lazy and inexperienced with Python3 and pip and all that, so I'll switch to the debian repository. Now, all I'm missing is the key to verify the packages(key C785B90B5053A3A2). Apt is really annoyed! Where can I get it? Maybe a hint on the Homepage would be nice too...

Right, I will add this info to the home page. Sorry. There are two main ways to get the key:

Normally, in the GnuPG model, you would get the fingerprint by a really secure channel (e.g., meeting me in person) or you would rely on the "web of trust" (trusting someone who trusts someone who... who trusts this key actually belongs to me. The chain verification is automated by gpg using digital signatures, done with each participant's key). Then, in order to have they key in a separate file '~/tmp/flo-key':

How do you ensure the authenticity of this keyring package if you don't yet have the GPG key used to sign the repo's Release file? There is a chicken and egg problem here. If you just download the .deb manually, with http or ftp, this is vulnerable to man-in-the-middle attacks (MITM). GPG does not suffer from such flaws, but it is not a tool that anyone can master in 5 minutes. Good security practice is never easy.

chris_blues wrote in Sun Jan 24, 2016 4:23 pm:Additionally, FFGo doesn't require FlightGear to work. There a lot of unnecessary dependencies in there. Maybe you'd like to change that, so only necessary packages are being pulled along.

--no-install-recommends Do not consider recommended packages as a dependency for installing. Configuration Item: APT::Install-Recommends.

FFGo is practically useless without FlightGear, therefore Debian policy says the 'ffgo' package should Depend on, or at least Recommend, 'flightgear'. The only things that could be useful without FlightGear (distance and bearing calculations...) require access to the airport list, and thus to apt.dat.gz, which, in Debian context, is only provided by FlightGear packages AFAIK.

If you don't believe me, have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806371. The absence of a dependency on dialog was reported as a grave bug (and Julien Cristau knows Debian pretty well) and fixed by adding a dependency on dialog. The situation is the same: one can very well compile dialog without installing the Debian package (and it is 10x easier than compiling FlightGear). But this is not how dependencies are used in Debian.

I understand your situation, though. Here, you are in the easy case because I have chosen Recommends. Otherwise, had I chosen to use a Depends relation, the normal way to solve your problem would be to create a dummy 'flightgear' package using 'equivs', like this.

Package: flightgearVersion: 2016.1.0+dummyMaintainer: Your Name <yourname@example.com>Description: dummy package pretending to be flightgear This package is empty. Install it if you want apt and dpkg to believe you have the flightgear Debian package installed. . Note that this package does *not* contain FlightGear!EOF% cd /tmp/tmp % equivs-build flightgear-control

your list will be reduced to 'libjs-sphinxdoc python3-condconfigparser'. python3-condconfigparser is required to parse the contents of the Options Window and libjs-sphinxdoc is required to properly make use of the FFGo conditional config documentation that is installed locally as part of the ffgo package for those who don't have Internet access. This documentation has a Search function that is implemented in JavaScript (not by me, but by Sphinx, which is the standard Python documentation system and which I used to write this doc).

chris_blues wrote in Sun Jan 24, 2016 4:23 pm:This is, because FFGo or Python3 or whatever refuses tu build/update my copy of FFGo. So I thought, maybe I did sth stupid to my copy (No idea what I possibly could have done. Never touched this dir...)

As I wrote in my mail, you have mixed up pip and Git in a strange way and used pip in a way I never advised. I'll include two sample install sessions at the end of this message, one using FFGo from Git, and the other using pip to install both FFGo and CondConfigParser.

(skipping the beginning and removing the commented out line)This is obviously messy. You are using bin/pip from FFGo's Git repo root directory, but this repository does *not* contain any such file! If you have bin/pip here, it probably means you have created a virtual environment in the same directory as FFGo's Git repository, this is absolutely not supported. Git must be complaining a lot about untracked files. pip used from there may overwrite files from FFGo or the other way around. You just can't expect things to work this way.

'pkg_resources' is only needed when running the ffgo executable created by 'pip install ffgo'. When using the ffgo-launcher.py script located at the root of every FFGo distribution tarball, zip file or Git repository, this module is not needed. But I never told anyone to use pip directly from a Linux distribution.

Unless using special options (--user) which don't work well in my experience, you shouldn't have the required permissions on Debian to do 'pip install something' unless you are root. But I have warned in bold in FFGo's README.rst file, which is rendered as HTML at https://pypi.python.org/pypi/FFGo as well as below the file listing on FFGo's GitHub page, to not run this command as the superuser (cf. the Installation section).

That is why I have spent days explaining virtual environments in docs/INSTALL/INSTALL_en, because short of using a Python interpreter that is clearly distinct from your system Python (= one shipped by your Linux distro)---for instance by compiling Python yourself in your home directory, or by using an OS such as Windows that has no system Python---virtual environments are the only way I know to use pip in a manner that doesn't lead to problems. I could tell you to install the Debian python3-pkg-resources, but that would be only adressing a symptom:

if you installed FFGo with a proper pip setup, as explained in great detail in INSTALL_en, then this pip, not /usr/bin/pip, must give the ffgo executable it created access to the 'pkg_resources' module, because this module is part of setuptools, and setuptools is a hard dependency of pip.

If you installed using any of the recommended ways of using pip in INSTALL_en, I don't think pkg_resources can be missing when invoking the ffgo executable installed by the proper pip (i.e., either in a virtual environment, or in a Python installation that is not shipped by your operating system tools [apt/dpkg/rpm/etc.]).

otherwise, you shouldn't have any ffgo executable (because it is created by the 'pip install' step), and the only supported way in this case is to use the ffgo-launcher.py script that comes with FFGo.

TypeError: 'encoding' is an invalid keyword argument for this function

This shows that this is run by Python 2.x, no wonder it doesn't work. You are using a pip executable that runs Python 2.x, presumably the one from Debian's python-pip package. This is not a supported configuration. Debian Python developers will tell you that you are on your own if this breaks your Python installation (which can't happen unless you do it with root privileges, which I very strongly advised against in the documentation). I already enumerated the supported pip setups:

pip executable from a non-system Python (not installed via your distro package manager); for instance, compiled Python in your home directory; or, Python installation on Windows---clearly not part of Windows;

pip executable from a Python virtual environment; to invoke such an executable, you have to either specify its path on the command line, or use an alias, or modify your PATH (or use the 'activate' trick which just modifies your PATH until you do 'deactivate'---as explained in INSTALL_en).

doesn't correspond to anything I have written. I never advised to use --force-reinstall, and I never advised to add the './' at the end. pip does not work like cp. You pass a list of packages to install, or a list of URLs to packages, but certainly not the destination directory simply as the last argument. Where did you get this idea? The destination directories are determined by the particular pip executable you use. i.e.

is going to install pkg1, pkg2, ... pkgn under /foo/bar/bin and /foo/bar/lib/python3.4/site-packages (assuming the venv in /foo/bar was created from a Python 3.4 installation). This is why using /usr/bin/pip as root is a recipe for disaster, since it should normally create or overwrite files under /usr/bin and /usr/lib/python3.4/site-packages, which is the realm of the package manager (dpkg on Debian). Debian developers were so afraid/annoyed by user reports because of this misuse of pip, that IIRC they have modified the Debian-shipped pip to print a big fat warning in such a case, maybe also install under /usr/local (it depends on which period you consider---there have been several discussions about that on the debian-python mailing list).

~ % mkdir ~/my-venvs~ % cd ~/my-venvs/# You may want to use '/usr/bin/pyvenv-3.4' or '/usr/bin/python3.4# -m venv' instead of '/usr/bin/pyvenv' to make sure which Python# version you are working with. It is *very* important that you are# clear about that. Of course, it must correspond to the packages# you installed above.~/my-venvs % /usr/bin/pyvenv-3.4 venv1~/my-venvs % ls my-venv1bin include lib lib64 pyvenv.cfg

[FFGo warning] Pillow library not found. Aircraft thumbnails won't bedisplayed.[FFGo notice] GeographicLib's Python binding not found. FFGo has fallbackstrategies, therefore you shouldn't see much of a difference. However, someparticular geodetic calculations can only be done with GeographicLib. You willbe notified when such a case is encountered.Detected FlightGear version: 2016.1.0

# FFGo works. It just told us about the two optional dependencies we# haven't installed. Let's install them. There is another way that# uses Debian packages (creating the venv with# --system-site-packages), this is explained in INSTALL_en, I can't# replicate all of its contents here.~/my-venvs % venv1/bin/pip install Pillow geographiclibDownloading/unpacking Pillow Downloading Pillow-3.1.0.tar.gz (9.9MB): 9.9MB downloaded

# This must be done whenever you work with FFGo's Git repo (unless# you know what you are doing), after 'git clone' and every 'git# pull' to have exisiting and up-to-date icons and translation (.mo)# files. This requires installing stuff indicated in# INSTALL_en's “Installation from the Git repository” section.~/src/ffgo.git % makemake -C share/iconsmake[1]: Entering directory '/home/flo/src/ffgo.git/share/icons'

[...]

make[1]: Leaving directory '/home/flo/src/ffgo.git/ffgo/data/locale'

# Since FFGo was not installed with pip in this case, no 'ffgo'# executable has been created. The recommended way to run FFGo in# such a case is via the ffgo-launcher.py script. The full path to# ffgo-launcher.py is not needed here since it is in the current# directory, however if you create an alias for this command, or if# you configure an icon in your menu bar/whatever to run it, you# will need the path (and maybe '/home/username' instead of '~'# too). The path to the Python interpreter, however# (~/my-venvs/venv2/bin/python), is crucial since it is for *this*# Python interpreter that we have installed CondConfigParser.~/src/ffgo.git % ~/my-venvs/venv2/bin/python ~/src/ffgo.git/ffgo-launcher.pyFFGo 1.9.0 startedUsing: - Python 3.4.4 - CondConfigParser 1.0.2 - MagneticField: GeographicLib version 1.45

[FFGo warning] Pillow library not found. Aircraft thumbnails won't bedisplayed.[FFGo notice] GeographicLib's Python binding not found. FFGo has fallbackstrategies, therefore you shouldn't see much of a difference. However, someparticular geodetic calculations can only be done with GeographicLib. You willbe notified when such a case is encountered.Detected FlightGear version: 2016.1.0~/src/ffgo.git %

# Again, FFGo works fine and just warns us about the two optional# dependencies it couldn't find. They can be installed in exactly# the same way as above by substituting 'venv2' for 'venv1'.

Now, how to update in each case:

First case: both FFGo and CondConfigParser were installed in the venvunder ~/my-venvs/venv1 using pip **_from this venv_**: