|
From: James T. <zak...@ma...> - 2017-01-06 12:42:44
|
> On 5 Jan 2017, at 07:59, Torsten Dreyer <To...@t3...> wrote: > > Please Florent, don't feel disappointed. Working in that area of code usually does not get you much applause. > And well - yes: sometimes some smart ideas don't work out as expected. Been there and done that, too :-) I would also say - if you /do/ continue working on a resource system, it would solve a number of issues, since there is a bunch of data we could then rely upon, at least in a fallback sense. The following files I would suggest could all be compiled in, and either ‘locked’ (always used the compiled version) or we check FGData and use the compiled version as a fallback: - translations - preferences.xml - gui/menubar.xml - the first splash screen - the default GUI font - core Nasal directories - Models/glider.ac This would ensure that the simulator cannot get totally broken by a dumb installation, and that we can offer useful GUI feedback in those cases. We could then decide if it’s a feature or a bug that the user can edit Nasal/ files in a build - if we agree for a given release, Nasal/ should be ‘locked’, we would make the resource-based files take precedence, if we agree user overrides are better we do the opposite. I can image this helping Nasal security (io.nas is no longer trivially modifiable), for example. (And we could set different policies for Nightly vs Release builds, so people can still hack the core nasal files without recompiling) Kind regards, James |