Use xdg-user-dir to respect user-defined XDG directories

[Metalhearf]

Use xdg-user-dir to respect user-defined XDG directories

Description

This pull request addresses an issue with HyDE's handling of user-defined XDG directories, i.e. the directory for pictures (XDG_PICTURES_DIR). Previously, the configuration used hardcoded paths (like $HOME/Pictures), which ignored user customizations that may have been defined in the ~/.config/user-dirs.dirs file.

The Problem with a custom "/home/user/Images" Directory

The issue I faced was that I had customized my XDG_PICTURES_DIR to point to /home/user/Images instead of the default Pictures directory. This was done by editing the ~/.config/user-dirs.dirs file, which is where users can define custom locations for various directories (Documents, Pictures, Music, etc.).

However, in the previous version of HyDE, the path to the pictures directory was hardcoded as $HOME/Pictures in the Configs/.zshenv file. Because of this, even though I had set XDG_PICTURES_DIR to /home/user/Images in my user-dirs.dirs file, the system would still reference $HOME/Pictures, which was not the directory I wanted to use. This caused a mismatch and the pictures were not being stored in the intended location. (I've found this issue while using the screenshot tool, which kept sending images to $HOME/Pictures/Screenshots).

Motivation for the Change

To address this, I modified the configuration so that HyDE would respect the user's custom directory settings. This solution uses the xdg-user-dir command, which automatically fetches the user-defined directory paths, ensuring that the correct directories are used based on what is configured in ~/.config/user-dirs.dirs.

By making this change, my issue went away. Now, HyDE correctly uses the customized directories like XDG_PICTURES_DIR, regardless of whether they are set to the default or custom values, such as my /home/user/Images.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

Please put an x in the boxes that apply:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My commit message follows the commit guidelines.
• I have tested my code locally and it works as expected.

Additional context

This change ensures compatibility with users who have customized their directory structure. It dynamically fetches directories like XDG_PICTURES_DIR from the user’s environment configuration, making it flexible for any user setup.

[kRHYME7]

is xdg-user-dir native to fresh arch install?

[Metalhearf]

Oh, you're right... I think that the xdg-user-dir package is not installed by default on a fresh Arch Linux installation sadly.

(It’s available in the official Arch repositories via: sudo pacman -S xdg-user-dirs, see Arch Wiki).

The purpose of xdg-user-dir is to handle user-specific directories like "Documents", "Downloads", and "Pictures", and it also takes localization into account. If you're using a non-English locale, xdg-user-dir can automatically adjust the directory names to match the system's language settings (for example, "Documents" might become "Dokumente" in German).

To make the this work, it might be helpful to check whether xdg-user-dir is installed before using it? Honestly I'm not sure what to do here. :D

[kRHYME7]

I don't mind adding it as default. But do debian have xdg-user-dirs as an official package?

@Senshi111 Will this break debian ?

@richen604 How about in nix?

This should add another "safe" layer on xdg stuff so I would like to add it upstream.

@Metalhearf If both distros approved this add the package in Scripts/pkg_core.lst

[Senshi111]

Debian have

[richen604]

@richen604 How about in nix?

yes, although hydenix/nix configs xdg separately (i dont use.zshenv for xdg)

in general i like this, @Metalhearf you should also include fish's config in case fish users delete .zshenv

[Metalhearf]

Thanks for the feedback!

I’ve updated the configuration to include the necessary fish environment setup in case fish users delete their .zshenv : 0669a03

Also added xdg-user-dir to pgk_core.lst : 56360cb

Let me know if you need any further adjustments or if there's anything else I missed. :)

[kRHYME7]

@Metalhearf Add check if the package is installed. It might return an error message into the variable.

[kRHYME7]

Ops I have a major concern. I realized we will do a multiple subshell calls. Are we sure to add this into the init of phase of the shell?

[Metalhearf]

I admit I’m not sure what the full implications of this are.

1. The xdg-user-dir calls are efficient, typically requiring only a read operation on the ~/.config/user-dirs.dirs file (around 1KB in size). For example, my xdg-user-dir PICTURES runs in under 2ms, as shown by the following timing:

   $ time xdg-user-dir PICTURES
   /home/user/Images
   xdg-user-dir PICTURES  0,00s user 0,00s system 80% cpu 0,002 total

2. xdg-user-dir calls are only made once when the shell initializes if I'm not mistaken? This should mean the impact is limited to the startup time.

3. The way the fallback is written with :- ensures that xdg-user-dir is only called when the variable is unset or empty. This optimizes performance a bit by avoiding unnecessary calls to xdg-user-dir when the variable has already been defined, reducing the overhead during shell initialization.

[kRHYME7]

@Metalhearf Then we might want to do this format XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-"$(xdg-user-dir CONFIG)"}"

The overall latency is around 3.2 ms with xdg-user-dir. Even though it's ms it should still be noticeable because we added a lot of variables. This can be fixed by the above proposal.

Though when we adapt UWSM soon this will setup the xdg env var so xdg-user-dir will act as a redundancy which sounds good for me.