XDG base directory spec

[antenore]

Added full support for XDG_DATA_DIRS and XDG_CONFIG_DIRS as requested by #818

To test you can move away your ~/.remmina, or ~/.config/remmina and ~/.local/share/remmina directories.

You can (manually at the moment), populate your $XDG_CONFIG_DIRS/remmina (it should be /etc/xdg/remmina) with your ~/.config/remmina/remmina.pref (and move away the ~/.config/remmina directory). Same for the .remmina files you have under ~/.local/share/remmina, that you can copy into $XDG_DATA_DIRS (normally /usr/share/remmina or /usr/local/share/remmina), again, removing the ~/.local/share/remmina directory.

As a last improvements I was thinking to add by default some template profiles to show up some different Remmina configurations in the XDG system directories.

I think there is still a big issue, but I don't get how should be the good behaviour.

If there are files in the system directories and the user data and config directories don't exists yet, remmina will try to save new profiles under the system directories.

This is quite normally as per my logic and comprehension of the spec.

I can write a script to migrate profiles if you like.

[antenore]

@giox069 @nastasi @Vladimir-csp @larchunix @weberhofer (and whoever in the Remmina cloud) I'd like your opinion if you have time.

[Vladimir-csp]

OK, tested.
Issue one: remmina does not merge data dirs. If there are connections in higher priority dir of ${DG_DATA_HOME}:${XDG_DATA_DIRS}, or even just an empty dir exists, then connections from lower priority dirs are not shown.
Issue two: remmina does not write config to $XDG_CONFIG_HOME, always reads from $XDG_CONFIG_DIRS. [edit] it also does not save connections to $XDG_DATA_HOME.
Issue three (off-topic): can those damned GNOME CSD's be turned off? Either at build time or if running not in GNOME? Sorry.

[antenore]

OK, tested.

Thank you.

Issue one: remmina does not merge data dirs. If there are connections in higher priority dir of ${DG_DATA_HOME}:${XDG_DATA_DIRS}, or even just an empty dir exists, then connections from lower priority dirs are not shown.
I'm not sure is how it should work as per the freedesktop XDG spec.
All the software I use, for what I remember the use the first directory found starting form the higher priority.

Probably the best is to provide scripts to migrate and merge profiles and configuration files? This should fix also the second issue.

Issue two: remmina does not write config to $XDG_CONFIG_HOME, always reads from $XDG_CONFIG_DIRS. [edit] it also does not save connections to $XDG_DATA_HOME.

If Remmina will try to write inside /etc or /usr/ it's normal because your user doesn't have the right to write there.

Issue three (off-topic): can those damned GNOME CSD's be turned off? Either at build time or if running not in GNOME? Sorry.

What are those "GNOME CDS's"?

[Vladimir-csp]

By XDG hierarchy logic, remmina should show all connections that exist in ${XDG_DATA_HOME}:${XDG_DATA_DIRS}. When file names collide, use the highest priority file. Write only to ${XDG_DATA_HOME} (obviously). I.e. when editing connection that came from ${XDG_DATA_DIRS}, create new file in ${XDG_DATA_HOME} overriding it.
Same logic basically applies to config hierarchy.
Right now remmina seems to choose highest priority dir existing, ignoring all other, and tries to use it exclusively for reading and writing, which is pointless.

CSD's - client side decorations, when application tries to do window manager's job. Looks out of place outside GNOME.

[antenore]

Ok, I'll read more carefully later.

CSD's - client side decorations, when application tries to do window manager's job. Looks out of place outside GNOME.

This must be reported as a new request. Provide also some examples. I use i3wm so I don't see any difference usually. I'll do my best. Thanks

[antenore]

By XDG hierarchy logic, remmina should show all connections that exist in ${XDG_DATA_HOME}:${XDG_DATA_DIRS}. When file names collide, use the highest priority file. Write only to ${XDG_DATA_HOME} (obviously). I.e. when editing connection that came from ${XDG_DATA_DIRS}, create new file in ${XDG_DATA_HOME} overriding it.
Same logic basically applies to config hierarchy.
Right now remmina seems to choose highest priority dir and tries to use it exclusively for reading and writing, which is pointless.

No, sorry but this by me it's wrong, or I get it wrong.
Reading the specification and man file-hierarchy, applications should not mix-up data and configuration files but read the one with the highest priority.

Now, and here I'm fighting with myself to find a good logic, if I open and modify a file that is inside XDG_DATA_DIRS (I don't even have a ${XDG_DATA_HOME} ), should I save it back to the XDG_DATA_DIRS or the ${XDG_DATA_HOME} one?
In my mind I should try to save it in the XDG_DATA_DIRS at first, and than, as a fallback if the remmina instance does not have writing rights in the ${XDG_DATA_DIRS} , save it in the ${XDG_DATA_HOME}. (same for the config)

Showing/merging both files it's not something any other applications do as far as I know.
ON the other hand I saw application (like i3wm) that provides scripts/tools to migrate, import generate files starting from the default ones.

[Vladimir-csp]

${XDG_DATA_DIRS} (usually /usr/local/share:/usr/share) and ${XDG_CONFIG_DIRS} (usually /etc/xdg) are system-level dirs, user has only read permissions on them, so there is no point in trying to write there, only read.

Writing of user data and configuration should be performed to ${XDG_DATA_HOME} (usually $HOME/.local/share) and ${XDG_CONFIG_HOME} (usually $HOME/.config) accordingly.

When reading data or configuration, any particular file in higher priority dir wins, not the whole dir wins. I.e. If you have /etc/xdg/remmina/remmina.pref and empty $HOME/.config/remmina/, you read /etc/xdg/remmina/remmina.pref. When you change configuration, you write to $HOME/.config/remmina/remmina.pref and use it from now on because it exists now and $HOME/.config/remmina/ has higher priority.

If you have connection files:

• /usr/share/remmina/connection1.remmina
• /usr/local/share/remmina/connection3.remmina
• $HOME/.local/share/remmina/connection1.remmina
• $HOME/.local/share/remmina/connection2.remmina

client should produce a list:

• connection1
• connection2
• connection3

where connection1 was read from $HOME/.local/share/ as it has higher priority than /usr/share/
If you edit connection3, it would be written to $HOME/.local/share/

[antenore]

For the preferences files we cannot do anything at the moment because remmina write the whole file in one shot. We should write to the file for each setting, using your workflow.

Nobody has the time now to rewrite this part as there are other more important.

Regarding the data file I'll see how much I can improve it. Even if some months ago I've removed a lot of spaghetti here and there, there is still a lot of work to do.

I'll improve this PR a little bit and than we will see.

[Vladimir-csp]

For the preferences files we cannot do anything at the moment because remmina write the whole file in one shot. We should write to the file for each setting, using your workflow.

No, described workflow does not require merging/overriding configuration per setting (although it would be cool :)). Write in one shot. Merging/overriding is done per file, file is atomic.

...I.e. If you have /etc/xdg/remmina/remmina.pref and empty $HOME/.config/remmina/...

By empty here I meant dir, not file. Just an example.

[antenore]

@Vladimir-csp May I ask you one more validation please?

[Vladimir-csp]

Config: it still does not save user config, but reads system-level config successfully.
Data: It copies connections from system-level dirs to user-level dirs on launch. This is sort of OK, but screws with use case of admin tweaking default connections deployed on the workstations. It would be better to write connection file on user-level only when editing, but until then read directly from system-level dir. So if a connection is not yet overridden by user, any changes to system-level file would be accessible to user.

[antenore]

Thanks for the test.

Config: it still does not save user config, but reads system-level config successfully.

Weird, it shouldn't, I'll check

Data: It copies connections from system-level dirs to user-level dirs on launch. This is sort of OK, but screws with use case of admin tweaking default connections deployed on the workstations. It would be better to write connection file on user-level only when editing, but until then read directly from system-level dir. So if a connection is not yet overridden by user, any changes to system-level file would be accessible to user.

Remmina file names are composed by a random generated number like 123456789 and the extension .remmina.

If you have the same file (so, the same file name) in the XDG_DATA_DIRS and XDG_USER_DATA_DIR, the one in the XDG_USER_DATA_DIR will be used. If, on the other way around, that files does not exists, remmina will copy it on the XDG_USER_DATA_DIR.

I think your issue is that you have files that have a different naming convention and this, at the moment, cannot be changed easily.

If it's not this the issue please provide me some real example.

Another thing I cannot do easily is the scenario where the user already have a profile named 12345.remmina and the admin wants to update it on a system-level. It'd complicate too much things I think.

@joakim-tjernlund can you give also your feedback please?

[Vladimir-csp]

If you have the same file (so, the same file name) in the XDG_DATA_DIRS and XDG_USER_DATA_DIR, the one in the XDG_USER_DATA_DIR will be used. If, on the other way around, that files does not exists, remmina will copy it on the XDG_USER_DATA_DIR.

Another thing I cannot do easily is the scenario where the user already have a profile named 12345.remmina and the admin wants to update it on a system-level. It'd complicate too much things I think.

If user has an override, there is nothing to be done. The problem is that remmina creates this override by itself on launch. It should be created only when it is required (when user edits connection or config).

1. Just read directly from topmost priority file without copying anything.
2. If user edits connection or config, write the file that changed to user-level dir.
3. go to 1

Naming convention does not matter, as long as file name is the same.

[antenore]

I don't see how can I do it without rewriting a quite big part of Remmina and I've an hard time understanding your scenario (my bad)

[Vladimir-csp]

Read what exists, write when necessary, repeat. If user does not edit anything, nothing gets written. If user edits something, affected files are written to user-level dir and get priority.
Do you have any questions about this algorithm left? I hope there is no more misunderstanding.

From what I am able to see from the outside without knowledge of remmina's internals, it can already find topmost priority data and config files in the hierarchy. So it is a matter of repeating this step when something gets edited. And write only on edit.

[antenore]

Thanks for the test.

Config: it still does not save user config, but reads system-level config successfully.

Weird, it shouldn't, I'll check

It works on my side.

[Vladimir-csp]

It works on my side.

Rebuilt current xdg branch, now user-level config is copied from system level on launch.
System-level connections are not listed.

[antenore]

I've created a new user and I had a remmina.pref file under /usr/local/etc/xdg/remmina and a profile under /usr/local/share/remmina.

Starting Remmina with this user have created the directories .config/remmina and .local/share/remmina and copied the profile and the remmina.pref file with the default settings.

Then I've created a new profile and modified the existing one (the one that was under /usr/local/share/remmina) and everything is fine...

Are you sure you setup everything correctly as described by the spec?

[Vladimir-csp]

Fairly typical XDG setup:

$ env | grep 'XDG_DATA\|XDG_CONFIG'
XDG_CONFIG_DIRS=/etc/xdg
XDG_CONFIG_HOME=/home/user/.config
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_DATA_HOME=/home/user/.local/share

A bit more extensive testing... system-level connections:
/usr/local/share/remmina/conn_A.remmina correctly selected, used (copied to user-level)
/usr/share/remmina/conn_A.remmina # correctly ignored
/usr/share/remmina/conn_B.remmina # incorrectly ignored, not listed.

[antenore]

Ok, I think I got it, I've a break in the loop that I should remove, sorry.

[antenore]

ok... Hope it's the good one

[Vladimir-csp]

Looks good! Correct files are being chosen. (at least for data, I haven't tested multiple $XDG_CONFIG_DIRS. If it uses the same algorithm, then it should be fine).

So the only thing left to do is to make copying on-demand, rather than on start. This would probably require defaulting option "remember last view for each connection" to false and making "save settings when starting connection" to only write when something was actually changed in connection.
Low priority on this is perfectly fine by me, now that XDG basics work.

...some other minor thing: Deleting connection from the list. If connection file exists in system-level dirs, user can not actually remove it. There are two ways of dealing with this:

• replace "Delete" with "Reset" (remove user-level connection file, read from system-level again).
• replace "Delete" with "Hide" (similar to desktop entries in XDG autostart: write some parameter like 'hidden=true' to connection file to hide this connection)

[antenore]

So the only thing left to do is to make copying on-demand, rather than on start. This would probably require defaulting option "remember last view for each connection" to false and making "save settings when starting connection" to only write when something was actually changed in connection.
Low priority on this is perfectly fine by me, now that XDG basics work.

Ok, so I'm going to merge this and close your initial request. Open a new one when this code will be released please.

Thanks a lot again for your support.