Re: [Flightgear-devel] Hard coded fg-root path in flightgearstartup?

[Geoff M. <ub...@ge...>]

On 06/01/17 00:30, Alan Teeder wrote:

Hi Alan, geneb,

Thank you for speaking out, even though this
is probably **not** the correct 'title' for this
discussion...

But as I suggest, we, in Windows, suffer from
what the mac/unix core devs think is **good**
from their mac/unix experience... and what they
read, hear, sometimes briefly discuss, and decide...

I am sure you understand where to 'install'
s/w in windows is a bit of a **mixed** bag...

We could use `C:\Program Files\...`, or
`C:\Program Files (x86)\...`, if in a 64-bit
runtime, and installing a 32-bit app, but in
my experience, these are both **BAD**, since
they require user to use 'Administrator' mode
to access, and change anything...

Perhaps not really a problem, but as indicated,
thankfully, the windows installer allows you to
choose anywhere in your file system...

But it is the `default` cmake install location,
if you do not offer an alternative... but as
earlier suggested, I think `fgfs.exe` should
run from where-ever it is built, or copied
to... it should have no built-in, hard-coded,
idea of the file/folder structure around it...

So, for instance, my most recent fgfs.exe install
is in x:\install\msvc140-64\flightgear\bin\...

Somewhere along the line, the `core` decided
persistent data should be stored in -
C:\users\<user>\AppData\Roaming\flightgear.org\

As the sort of equivalent of `$HOME/.fgfs`,
and unfortunately, with no core windows devs
around, or maybe that was even chose by one of
them at the time, but that was chosen, and
implemented...

And as you point out Alan, that `Appdata`
folder is marked `hidden` in a GUI file
view... which of course can be over-ridden...
but requires more user knowledge...

And yet, when there is a problem, a bug,
Windows users are expected to find, and share
C:\users\<user>\AppData\Roaming\flightgear.org\fgfs.log

And that is where the ...\FlightGear\FlightGear.ini
is also stored... not that that is a very user
friendly ini...

And where the autosave_*.xml, and navdata_*.cache
live...

So that is where we are at present...

How can this be addressed? Wow, I do not know,
with no windows `trusted` core dev to help...

I guess we just have to live the best we can
with this mess ;=))

Since I have many fgfs.exe builds, it is possible
to deal with most of this, except the recent,
now reverted, hard-coded help data...

And I have learned, to get a fresh, clean start,
to trash, or rename that persistent data location...
even have a batch file to do this...

And I have chosen to put all 'fgaddon' and 'fg-scenery'
on an external USB 2 TB drive, in G:\D\fgaddon, and
G:\S, resp, now very cheap and efficient...

Regards, Geoff.