search

CryoByte33 / steam-deck-utilities

A utility to improve performance and help manage storage on Steam Deck.
GNU General Public License v3.0
3.23k stars 80 forks source link

XDG compliance #45

Open TiZ-HugLife opened 1 year ago

TiZ-HugLife commented 1 year ago

Hi there! Great utility you've got here. It was great when it was just a Zenity script, and it's still great now. I appreciate all the work you've done!

I'm submitting this issue to get ahead of something I've noticed with folks developing specifically for Deck; lack of adherence to established standards. Specifically, the XDG Base Directory Specification, which pertains to where applications should store their files.

Granted, ~/.cryo_utilities is not a bad directory at all. It's hidden, and self-contained. It is better than some other offenders, one of which dumps configuration directly into ~/Documents! We can be better here though, and I think it's worthwhile to establish good habits for standards adherence. This may sound like a nitpicky request to make, but I think it's important.

I would start by simply wholesale moving the ~/.cryo_utilities folder to $XDG_DATA_HOME/cryo_utilities:

$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

CryoUtilities does not store any configuration, nor does it store any state. Log files don't really count as configuration. All of this is "data": the binary, launcher script, icon, and log file.

There are actually better places to put some of these things. For example, I would put the binary--or at least a symlink to it--in $HOME/.local/bin. There's no official environment variable for this; many projects do use $XDG_BIN_HOME, but only ~/.local/bin is in the spec. This way, it's easier to invoke the utility from the command line.

Normally, I would say that the icon should be installed using xdg-icon-resource, but it's not one of the standard sizes. It's 150x150. If you make it 128px or 256px instead, you can install it with xdg-icon-resource if you'd like. You'd use the same utility in the uninstaller, too.

If you do decide to do those additional things, that is more stuff the uninstaller will have to do, and more things a user would have to take care of if uninstalling manually. Self-containment would be a totally fair argument for just keeping everything in one directory, but I do think it's important for that directory to be in a standards-compliant location.

Thanks for your time. :)

CryoByte33 commented 1 year ago

Thank you so much for the detailed report! Let me address these things 1-by-1:

$XDG_DATA_HOME/cryo_utilities This was in the initial version I tested, pre-beta. The problem was that for some reason, updates seemed to break the utilitiy while in ~/.local/share, I have no idea why. I was able to replicate it going from 3.4 stable to preview, back, to alpha, etc.

As soon as I moved to a hidden folder in $HOME, the issue disappeared. I know that it goes against all reason, but I'd love to implement this if possible, as was the original intent.

$XDG_BIN_HOME I actually didn't know about this, I'll comment a bit more on it below.

xdg-icon-resource This one is on me, I just did a quick Google since I'm not used to KDE and used the first result. I'll have to investigate more before deciding whether to implement it or not.

Thoughts on install/uninstall: This was my primary concern when making the utility. The initial version had many complaints for installation/removal, so I prioritized ease of those 2 features. Can you foresee anything that a user would have to do if I update to use the proper path and perhaps the better icon format?

As a note, regardless of implementation, I'll need to symlink back to ~/.cryo_utilities until I make a new video showcasing it. The video drastically complicates what I can just "change" at-will 😅

TiZ-HugLife commented 1 year ago

This was in the initial version I tested, pre-beta. The problem was that for some reason, updates seemed to break the utilitiy while in ~/.local/share, I have no idea why. I was able to replicate it going from 3.4 stable to preview, back, to alpha, etc.

As soon as I moved to a hidden folder in $HOME, the issue disappeared. I know that it goes against all reason, but I'd love to implement this if possible, as was the original intent.

This explains why you weren't using the standard; you're clearly knowledgeable enough to be aware of it. Man, computers are weird sometimes! I've encountered my fair share of those types of issues. What specifically was breaking anytime you did updates with the tool in that location? Is there a specific commit where you changed it that I can look at to see if I can find anything off?

Thoughts on install/uninstall: This was my primary concern when making the utility. The initial version had many complaints for installation/removal, so I prioritized ease of those 2 features. Can you foresee anything that a user would have to do if I update to use the proper path and perhaps the better icon format?

I think the only users who might do a manual uninstall would be power users, and I think they are gonna find their way into ~/.config and ~/.local anyways, since other tools utilize those paths. I think relocating the self-contained directory there won't make it harder for users to uninstall, but will rather help enforce expectations they should have anyways.

If ease of manual uninstallation is a priority to you, I would skip formal icon installation. I think symlinking into ~/.local/bin is fine though, because if the target of the symlink doesn't exist, it won't be considered a command.

CryoByte33 commented 1 year ago

This explains why you weren't using the standard; you're clearly knowledgeable enough to be aware of it. Man, computers are weird sometimes! I've encountered my fair share of those types of issues. What specifically was breaking anytime you did updates with the tool in that location? Is there a specific commit where you changed it that I can look at to see if I can find anything off?

The code was completely written in another temporary repo, which I deleted when I copied the code here so unfortunately no commit history.

I can say that it was install.sh lines 19, 23, and 27. All 3 went to $XDG_DATA_HOME/cryo_utilities at the time.

As for what actually happened, when swapping OS versions, the binary became corrupt. It started throwing an exec format error every time, and even persisted through a wipe of my entire SSD.

I think the only users who might do a manual uninstall would be power users, and I think they are gonna find their way into ~/.config and ~/.local anyways, since other tools utilize those paths. I think relocating the self-contained directory there won't make it harder for users to uninstall, but will rather help enforce expectations they should have anyways.

That's definitely fair enough. I'll see about doing that if we can figure out why I had errors before!