dat files location: leverage XDG_DATA_HOME if defined

[macmpi]

To ease desktop integration as per https://github.com/macmpi/x11-calc-flatpak/issues/1#issuecomment-1922527504

[mike632t]

Thanks - having thought about it in order to make this a non breaking change I think what I'll do is check to see if $HOME is defined if a config file already exists there use that, but then check to see if $XDG_DATA_HOME is defined and save the config there is it is or in $HOME if it isn't.

I'm rather busy at the moment so it may take a few days or so to push an update

[mike632t]

Are you sure this will actually help? Despite what the standard says while testing some possible changes to the code I found that $XDG_DATA_HOME does not appear to be defined when using KDE (Debian 10), UNITY (Ubuntu 20), or MATE (Debian).

(Or is it only defined when using Flatpak?)

[macmpi]

Yes Flatpak sets this by default in the "containered" environment. Snap does not seem quite there by default, though many apps add XDG environment variables in their packaging. AppImage seems to have provision for it too. Interesting hints/overview here.

Overall, avoiding cluttering $HOME with dat file & moving them to $HOME/.local/share might be a worthwhile common default, which also happen to be the recommended $XDG_DATA_HOME default when set (export XDG_DATA_HOME=${XDG_DATA_HOME:="$HOME/.local/share"}).

[mike632t]

avoiding cluttering $HOME with dat file & moving them to $HOME/.local/share might be a worthwhile common default

That seems like a good plan...

[mike632t]

Just pushed an updated version to the 'unstable' branch - let me know if it does what you want. Note if the dat file exists in $HOME it will be used in preference to anything in the $HOME/.local/share/ directory. (I didn't use $XDG_DATA_HOME as it doesn't seem to be defined in many cases where the directory exists).

[macmpi]

Thanks. Can't test for a few days, but will report here. Leveraging $XDG_DATA_HOME if defined would be beneficial for Flatpak, but will see how it plays-out without.

[macmpi]

The logic works well for backward compatibility, but it does not fundamentally change the flatpak side of things, as sandbox needs to be granted specific access rights to work .dat file in that location, unless it is located into $XDG_DATA_HOME. However it would be probably cleaner indeed for non XDG compliant scenario use to have it in .local/share/: however, I guess it would rather be in .local/share/x11-calc/ and file won't need to be a hidden dot file there (in general apps have a dedicated directory: having one single for the whole family would make sense).

With that compliance can be finally achieved by just checking if $XDG_DATA_HOME is set beforehand, and use .local/share/x11-calc/ if not (like on KDE) .

[mike632t]

it does not fundamentally change the flatpak side of things, as sandbox needs to be granted specific access rights to work .dat file in that location, unless it is located into $XDG_DATA_HOME.

So is what you are saying is that when using Flatpak $XDG_DATA_HOME isn't located in $HOME\.local\share ?

Update - I've created a short test program here that will attempt to list some of the environment variables we are interested in and I'd be very interested in knowing if $XDG_DATA_HOMEis actually defined...

[macmpi]

So is what you are saying is that when using Flatpak $XDG_DATA_HOME isn't located in $HOME\.local\share ?

yes, under flatpak conventions, $XDG_DATA_HOME is set as ~/.var/app/<app-id>/data

[mike632t]

OK - Now I understand the problem a bit better!! I'll have a bit of a think and push an update in the next couple of days.

[mike632t]

OK I think I've cracked it, I have pushed my changes to the unstable branch so you can test it.

If the data file exists in the $HOME directory that will be used every time to maintain backward compatibility, otherwise if $XDG_DATA_HOME is defined the data file will be saved there if it exists, but if it is not defined or does not exist then the program will attempt to use $HOME\.local\share before reverting to $HOME if $HOME\.local\share doesn't exist.

Thanks for the suggesting the change, let me know if the changes work for you!

[macmpi]

OK I think I've cracked it, I have pushed my changes to the unstable branch so you can test it.

Yes is working perfect, thanks indeed! (You may want to have your own x11-calc subdir in the case of $HOME\.local\share use as other apps seem to be doing: I don't see files outside of app subdirs on my setup).

Happy to share my basic 128x128 icon file to further ease eventual desktop integration. Should you provide another preferred one, I'll leverage it instead. Having a unique launcher script/app (with assorted conf file to pick the desired calc) also greatly help with .desktop file integration (avoids app menu is filled with all individual apps): feel free to reuse if it has any value in your case.

[mike632t]

I've just added an icon file (in the src folder) - I hadn't realised that I hadn't included it already!! It goes back quite some time and predates the current emulator by a few years (details of my original simulator which was written in Visual Basic are here). It isn't very artistic but it does the job and works well enough on screen. I suppose that really ought to get the application to display this icon title bar now as well.

I did think about creating a separate data folder, but wanted to get something you could test out as quickly as possible so you cold tell me if it worked. I expect I will add the code to create a sub folder before I merge these changes to the stable branch (I really have to do it now or it will be a breaking change later) so watch this space..

With regard to the model selection you probably won't be surprised that I have a corner of my desktop full of calculator icons with 'shortcuts' to all my favourite models!

[macmpi]

Great, thanks!

I've just added an icon file (in the src folder)

Could you provide it in PNG format instead/in addition (and eventually a bit higher res)? It is more widely used these days (and lighter), and would avoid ad-hoc conversions (i.e. flatpak/snap only supports PNG/SVG, AppImage PNG only).

[mike632t]

I've just pushed what I hope is a .PNG image file to the stable branch, (I have renamed both it and the .ICO file to reflect the fact that they are 32x32 pixel images).

I did manage to dig out the original file but unfortunately it is the same size, however it goes back even further than I thought, the date time stamp on the file was 9 Sep 1998 !!

I'll sort out the data file location and then see if I can create a set of larger icons. I assume you want something like 48x48, 64x64, and possibly 128x128 or would an SVG file be better. I have created them by hand using a text editor in the past and this one doesn't look too complex, as basically it is just a bunch of rectangles...

Drawing using SVG

[macmpi]

Thanks: tried the 32x32 PNG successfully. On the flatpak side of things, requirement is 128x128 PNG or SVG (unsure this may preclude a flathub submission though). Should you only provide one, it seems PNG would satisfy most of packaging flavors.

EDIT: took a first stab at it, trying to retain your design principle, derived on 34c: If interested can provide original SVG file editable with inkscape.

[mike632t]

OK I think I've cracked the application folder path issue, and just pushed some changes to unstable. (I now create an x11-calc folder in $XDG_DATA_HOME or $HOME/.local/share if it doesn't exist).

Let me know how you get on - I've tested it with $HOME/.local/share with but I've not been able to test with $XDG_DATA_HOME, if the application sub-directory can't be created for any reason (a file with the same name already exists) then the data file location will default to the $HOME directory.

For flatpak I'd go with a SVG icon, but have you thought about how your icon will look when it is resized to 32x32 pixels?

The reason I took two rows of buttons out was to stop the gaps between then disappearing when the icon was made smaller, and coincidentally it also makes the graphic more square which is a better fit for an icon's aspect ratio. However, it is always going to be a bit of a compromise.

Style wise the very rounded corners do have a modern feel but the result looks rather more line a pioneer series than the woodstock or spice series. I tried to use the black border on my icon to emphasise the difference between the keyboard which is slightly recessed and the case which is also a darker colour on the spice series as I'm slightly biased!

Your version will fit in very nicely into a GNOME or Budgie desktop though!

I'll have a play later!

[macmpi]

Last change broke the $XDG_DATA_HOME case unfortunately:

x11-calc-34c : Unable to open '/home/toto/.local/share/x11-calc/.x11-calc-34c.dat'.
Saving '/home/toto/.local/share/x11-calc/.x11-calc-34c.dat'.

whereas $XDG_DATA_HOME translate into /home/toto/.var/app/io.github.mike632t.x11_calc/data/ on flatpak. In that context no need for a subfolder either, as app container is already specific to app.

On icon: feel free to customize as you wish if the provided inkscape file helps. Here is conversion as 32x32 PNG (exported from SVG with inkscape).

[mike632t]

My initial attempt at an SVG icon with the aim of replicating the existing bitmap (warts and all - and there are a lot of warts)

I think it shows why I didn't highlight the function key - it looks too big highlighted (updated version checked in without the highlight)

[macmpi]

Yes, flatpak build with that SVG icon works: very nineties indeed :wink:

Wish you can fix again $XDG_DATA_HOME.

[mike632t]

OK - I've reproduced the $XDG_DATA_HOME problem, should have a fix shortly!!

[mike632t]

Just pushed a fix

[macmpi]

fine, thanks:

Loading '/home/toto/.var/app/io.github.mike632t.x11_calc/data/x11-calc/.x11-calc-34c.dat'.
Saving '/home/toto/.var/app/io.github.mike632t.x11_calc/data/x11-calc/.x11-calc-34c.dat'.

[mike632t]

No problem (it was a silly bug).

If after you have had a chance to test the latest version for a bit you haven't found any issues do you want to close the issue? I'll then merge the changes into stable.

Thanks.

[macmpi]

If you are OK, I may try to submit to flathub after your next release, unless you prefer to do it (will update my repo). Should you tag releases with a version number, I'll follow them in metainfo file.

[macmpi]

Before closing: just pondering on the extra x11-calc sub-folder in flatpak case, as does not make much sense. However it probably has some merits on other $XDG_DATA_HOME cases. Unsure if I just live with that, or try to find a trick to avoid it...

[mike632t]

Merged changes into stable

[mike632t]

The XDG Base Directory Specification says :

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

If $XDG_DATA_HOME is defined in environments other then Flatpak then it looks like this intended to be a shared directory so applications should use separate sub-directories, in the same way as applications that use '$HOME/.local/share' do.

It may look like overkill at the moment, but it the current solution would allow me to use a separate data directory for each model in the future if necessary.

[macmpi]

Yes: have looked at other flatpak apps, and I'm going to stick with x11-calc subdir...and for consistency, I will also use it for expected default .rom file locations.

Last bit on this: having .dat files as hidden dot files makes sense in legacy $HOME location to lower clutter. However, it's probably better to have them not hidden in the newer default locations, as they will be inside an already hidden dot directory: once inspecting such hidden directories (for maintenance/debug/al.), it's quite common to have only visible files.

[mike632t]

Agree that not using hidden files is probably a smart move if using a separate directory for the application files. Won't take long to fix! LOL - May take a little longer then I thought to keep things tidy!

[mike632t]

You could also put any saved program files in $XDG_DATA_HOME. Basically having keyed in a program you exit and copy the saved state to a separate file, specifying this from the command line causes this file to be loaded instead of the default. (I've just pushed some examples to the prg directory). Using the application folder to store them makes sense..

[mike632t]

Just updated the unstable branch, hidden files are no longer used if saving the state in a sub-directory of $HOME/.local/share or $XDG_DATA_HOME...