What to do with the registry file?

[knghtbrd]

I've got code loading the various bmp files out of the directory the linapple binary is installed to (no matter where you run it from) and in iKarith/linapple it now loads them all only once (which eliminates an error), but I'm still not doing anything with the registry file in particular beyond the odd merge of @ghedger and @cpressey's trees.

We can write the file out of SDL_GetPrefPath(). What's desired behavior here?

[knghtbrd]

Nobody has offered opinions on this, so I opted for what I discussed on Facebook.

I have a working prototype of this code now, which parses proper INI files. Most such parsers either want you to pass them a file, key, and section, and they'll give you a value. A few have a function that lets you provide a file and will walk through them calling your chosen callback with section, key, and value, but that's the exception, not the rule. Basically I'd written mine by the time I discovered the exceptions. :) But even where exceptions are found, the code is pretty nasty-looking because they are usually designed for low memory usage and few dependencies. Text processing in C-based languages is a brutal, often ugly affair without some pretty heavy-duty high-level text processing interfaces on top of the base language. (And those are just as brutal under the hood.)

This code is direct and brute-force, but it's readable, not TOO ugly, and commented well, so I see no reason to abandon it for one of those monsters now.

Today (well, I guess it's now tomorrow, but before I go to bed) I'll finish testing for all the illegal inputs this thing is supposed to reject, drop the code in. I'll probably commit it after I've had some sleep along with a new linapple.conf converted to a more proper INI format. Then I'll finish off #11 and reach a decision on #8.

That'll pretty much finish the merge.

[cpressey]

Sorry I drifted away from this - I feel a bit responsible because I was the one with the oddball use case that makes this an issue in the first place (or, more of an issue than it would otherwise be.)

From what I remember, my last thoughts on it (which may no longer be relevant - I haven't checked thoroughly) were these:

First, it's important to realize there are two kinds of files under consideration here:

• resource files that the program uses (e.g. the font bmp)
• configuration files that the user might edit (i.e. linapple.conf)

This issue, and #11, are phrased in terms of the latter, but my concerns are maybe more with the former. I'll go over both.

Resource files

The main point I wanted to impart is that resource files should not normally be installed under the user's home directory, because the user isn't expected to edit them.

Conventionally, when resource files are installed on a Unix-like system, they go somewhere like /usr/local/share/.

When autotools are used, the configure script usually has an option --prefix= that lets you change the /usr/local/ part to whatever you want. This lets you avoid installing things globally, and lets you install them in a local, user-owned directory (and in fact this is exactly what I do, in my oddball use case, for such packages, so if linapple eventually uses autotools for its build, this becomes basically a non-issue for me.)

My cheapo solution was to simply let the build process know, by setting environment variables, where the resource files can be found; then it hard-codes those paths into the executable.

It sounds like the current state of things is to assume the resource files reside in the same directory where linapple is installed - i.e., the directory where the linapple executable resides? A purist might object to storing non-executable resource files in a directory intended for executables - but I'm not that much of a purist. It sounds fine enough, I'll need to try it out.

Configuration files

Configuration files, by contrast, are expected to go in the user's home dir. My only preferences are:

• It shouldn't be strictly required to have a configuration file in your home dir (and it shouldn't automatically create a default one for you there if there isn't one. It isn't the end of the world if it does, it's just kind of untidy.)
• It's nice when there's a way to specify the location of the configuration file on the command line, and when this is given, it shouldn't have to look in the home dir at all.
• Some emulators look for the configuration file in the current directory first, then if it's not found, look in the user's home. This is fine, can be convenient, but is also not necessary when you have a command line option, because you can just say --config=./linapple.conf or whatever instead.
• Ideally, if there is a supplied configuration file that contains all the defaults, it should be called linapple.conf.sample or whatever, and it should have all the settings initially commented out, with instructions to rename it to linapple.conf and uncomment and change any parts you might need to change. This is what many webservers, etc. do and it seems like a convenient approach. (Linapple was installing a file called linapple.installed.conf but I don't think it worked that way.)

So, not sure if that makes anything clearer, but those were my thoughts.

[maxolasersquad]

These are my thoughts exactly. On an Ubuntu system, these bitmap images would typically find their way in /usr/share/pixmaps and the user configuration in either ~/.config/ or ~/.local/share/. I believe autotools takes care of that for you.

[knghtbrd]

I’d like to apologize for dropping off the planet for a bit—I wound up with some pretty seriously painful medical problems which needed surgery. I’m on the mend from that (a week out now) and barring any complications from that I should be back to it soon.

SDL 2 gives us two functions. One provides the location of the executable. This is the location Windows programs tend to store their resources. The other gives us a subdir under ~/.local/share, the XDG data directory. Not a subdir of ~/.config unfortunately, though we could write that function if we want it.

What I’ve got going on is an ASSET_DIR which the Makefile defines as $(PREFIX)/share/$(PACKAGE), but will failsafe to a definition of “.” If that’s missing for some reason. If the asset isn’t found there, it looks in the EXE directory if it can (again failsafe to “.” if it can’t).

Doing something similar for SYSCONF_DIR being /etc or the EXE dir or “.”, and ultimately a user config as well, which will be writable.

When we write out the user config file, it’ll contain settings that were set/changed after the system config in /etc was loaded. That way the user config doesn’t just automatically contain all settings after the first run and the config in /etc remains useful (assuming there is one.)

Hope that makes sense?

Joseph Sent via mobile

On Jul 25, 2018, at 08:58, David Baucum notifications@github.com wrote:

These are my thoughts exactly. On an Ubuntu system, these bitmap images would typically find their way in /usr/share/pixmaps and the user configuration in either ~/.config/ or ~/.local/share/. I believe autotools takes care of that for you.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[cpressey]

Hi @iKarith, that's good news if I follow you, because I think overriding ASSET_DIR during build should do what I want (or at least get me 90% of the way there).

However, in trying out the latest version (master branch as of today) for the purpose of getting back into it and testing that theory, I find I'm unable to boot from any disk - I just get a screenful of garbage and a * (monitor) prompt. Is that expected for the current state of the code? If not, I'll either try to figure out what I'm doing wrong, or file a bug report, depending on what behaviour other people are seeing.

[knghtbrd]

Yeah I saw that. And, I haven’t gotten back to finishing what I was working on either. Surgery recovery has not gone as well as I’d like and sitting for long periods has only just started to be something I can do.

Joseph Sent via mobile

On Aug 25, 2018, at 14:01, Chris Pressey notifications@github.com wrote:

Hi @iKarith, that's good news if I follow you, because I think overriding ASSET_DIR during build should do what I want (or at least get me 90% of the way there).

However, in trying out the latest version (master branch as of today) for the purpose of getting back into it and testing that theory, I find I'm unable to boot from any disk - I just get a screenful of garbage and a * (monitor) prompt. Is that expected for the current state of the code? If not, I'll either try to figure out what I'm doing wrong, or file a bug report, depending on what behaviour other people are seeing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cpressey]

After fiddling with it for a while, I think I see what's happening. If you don't have a $HOME/linapple directory, linapple will create one. But it needs a properly-populated /etc/linapple directory to do so. If you don't have that, it will create a linapple directory containing zero-size files, which will fail like this when you try to boot a disk.

I got disks booting again with:

rm -rf $HOME/linapple
sudo ln -s /path/to/linapple/res /etc/linapple
linapple

[maxolasersquad]

@iKarith how is your recovery coming along? A hope everything is going well for you.

[ghedger]

Sorry I've been a non-participant to this point -- summer and fall projects got to me.

Diving into the latest and greatest now...

@iKarith I do hope you will be feeling better soon! :(

@cpressey Excellent semantic disambiguation between internal non-modifiable files (e.g. font.bmp) and configuration.

Let me see if I can get this beast compiling (also had to upgrade to Ubuntu 18 over the summer and haven't built linapple since then)...

[ghedger]

Looks good.

Audio gets choppy after awhile -- test is to try any game with Mockingboard music. I will handle these problems for now. Any suggestions/consensus on the configuration paths issue?

[rhaleblian]

See my note in #44 for a mitigation re the image resources; linapple.conf and Master.dsk are still external files. Riffing on the above, how about $HOME/.config/linapple/conf.ini /usr/local/share/linapple/master.dsk

Lacking a Windows registry, using INI would be a good change. I was getting some impression that upstream was using YAML for something...