Decide where to have the data folder once we release setup packages

[gcarreno]

Hey Werner(@wp-xyz),

You've never answered me on this comment, so I'm now making it an issue on it's own for Milestone 1.1(Mapping).

I suggest:

var
  DataFolder: String;
begin
{$IFDEF WINDOWS}
  DataFolder:= GetUserDir+'CoronaData';
{$ELSE}
  DataFolder:= GetUserDir+'.coronadata';
{$ENDIF}
end;

What do you think? This still leaves the corona.cfg under Linux:.config/corona.cfg and Windows:%%APPDATA%%\corona.cfg or is it %%USER%%\corona.cfg? Only sure of linux placement. Well what ever GetAppConfigDir() / GetAppConfigFile() returns in Windows.

Cheers, Gus

[wp-xyz]

Applied your code but left the option the store data in application directory for a "portable application".

I like this idea to have everything at one place. By default, data now are written in the user folder as you suggest, but when PortableInstallation is true (e.g. by opening the exe with command line argument "-portable") data will go to the application folder.

[gcarreno]

Hi Werner(@wp-xyz),

Thanks for accepting my suggestion!!

I only take care of the place in order to configure InnoSetup. I'm quite sure of your abilities to determine the context the app is being ran and find the data, you're rather good at this programming thing, yeah know :stuck_out_tongue_closed_eyes: </sarcasm> And I'm also quite glad that you've put portable under consideration. I get a bit too involved in the Linux side that I forget the Windows culture. Thanks for reminding me! .oO( That's another package I'll have to learn how to build! )

My intention with this issue was to have it recorded in a way that none of us, two, could forget :smile:

Would it be asking too much if you could look for data in many places, like some app look for config in linux? Most have a fallback, waterfall style, like first /etc/app, then $HOME/.app, then something else, etc...

You could have these and you decide the fallback sequence:

• ExtractFilePath(ExpandFilename(ParamStr(0))), app folder for short and good for -portable
• GetUserDir()+[.c|C]orona[d|D]ata, current decision
• Some other place you or I may decide.

Dunno, I'm spitballing a bit here and if you think it's a crap idea, just drop it.

Cheers, Gus

[wp-xyz]

I only take care of the place in order to configure InnoSetup.

Applications distributed by InnoSetup usually install into "c:\program files". This installation will not be portable in any case.

If the user wants a portable installation he should either get a zip with exe and required dlls which he zips to an arbitrary directory. And he should start the application with the parameter "-portable". This is a problem of course. Is it possible that the InnoSetup script can be configured to allow an option for "portable installation"? In this case the desktop link should be created to provide the "-portable" argument (and the installer should check that the app is not installed to c:\program files). Alternatively we could deliver another binary "corona_portable" which simply starts corona.exe with parameter "-portable"

Would it be asking too much if you could look for data in many places, like some app look for config in linux?

I don't want to put too much work into this feature because fresh data are always available after a simple click.

[gcarreno]

Hey Werner(@wp-xyz),

Applications distributed by InnoSetup usually install into "c:\program files".

Yes it does, but it also allow you to include files under the many user and global related folders, like %%USER%% and %%APPDATA%% and the likes. It also allows you to define if you want a Global Install, a User Install, or let the installer choose. It's rather flexible and all encompassing. And corona will always place data locally for the user, so even if a global install, that's solved.

Is it possible that the InnoSetup script can be configured to allow an option for "portable installation"?

InnoSetup is quite versatile and I'm sure we can force the app to be called with params. But wouldn't be better to distribute a portable package as in Portable Apps? Portable Apps containerizes it's own file system/registry per app, so it can try and get the data from whateves.

I don't want to put too much work into this feature because fresh data are always available after a simple click.

I don't understand this statement. When a Linux app does this, it does this once at startup only.

Cheers, Gus

[gcarreno]

Hi Werner(@wp-xyz),

Forget about Portable Apps and the containerised file system/registry. I think there's a bit more for me to study on that.

After a diagonal look at their docs, I'm confused about the containerization. Need to better investigate.

In the mean time, we can work with the -portable option. No probs!

But please do give a look at the Portable Apps stuff, it has auto-update if we publish to their central data thingamajig.

Cheers Gus

[wp-xyz]

No no, it should not become something like the "official" portable apps. Just an option for some people to have everything at one place.

[gcarreno]

Hey Werner(@wp-xyz),

No no, it should not become something like the "official" portable apps.

Okydokes, no probs. I think we can think of something that can be triggered by the build script. What do you think about a Build Mode called Release_Portable, where you have a define PORTABLE and have IFDEFs for it?

Cheers, Gus

[wp-xyz]

I think we can think of something that can be triggered by the build script.

Why? In my mind, "portable" and "non-portable" are the same binaries. "Portable" only is called by the user in a special way (by adding "-portable" to the params of the application).

[gcarreno]

Hey Werner(@wp-xyz),

In order to have 2 distinct distribution packages(produced via bash scripting), it's easier to have a build mode instead of a command line switch.

The binary will be exactly the same, with the slight difference that it will pick the data folder via build mode instead of via command line switch.

This way I can build a package named corona-v1.0-[i386,x86_64,arm]-[linux,win32,win64].[zip,tar.gz] with the data folder being under the user's data folder. And build a package named corona-v1.0-[i386,x86_64,arm]-[linux,win32,win64]-portable.[zip,tar.gz] with the data folder in the same place as the executable.

After you get mapping merged into master, we will then begin releasing corona-v1.1-setup_32b_64b.exe and corona-v1.1-[i386,x86_64,arm]-[linux,win32,win64]-portable.[zip,tar.gz].

I hope this clears out my intentions about the build mode vs command line switch. When I asked you to consider this, it was only to help me better distribute your work, not put in doubt your ideas.

Cheers, Gus

PS: And yes, I've tested it and I can now cross-compile for RaspberryPi's Raspbian Linux also YAY :raised_hands: