Respect XDG base directory specification #407
Comments
|
seems many apps have this problem... someone on #telegram github site said this
|
|
I chose not to do this to avoid constant questions about where SSR stores its data. I constantly have to point people to the config file and the logs, and it's much easier to say 'look in the ~/.ssr' folder. AFAIK what SSR does has pretty much been the norm for years. Looking at my own home folder and .config folder, it seems to be a 50/50 split. In any case, the confusion that I would create by moving the location at this point just isn't worth it IMHO. However I have some plans to change the config file format at some point in the future (the current format is too restrictive), so when I do that I could change the location as well. |
yep because the new standard doesnt exist that long. Even the KDE wasnt using it with the 4.x series. Now with Framework5 / Qt5 everything is in the right spot. so are the most Qt5 Apps, Unity3D Games, Google App stuff, gnome and gtk3 things.. |
|
Qt5 is still slightly buggy, so I keep Qt4 as the default for now. Anyway, I'm not going to use the Qt settings system anymore, I plan to switch to JSON. I will try to move the location when I change the file format. |
|
@MaartenBaert Any news on this? |
|
I don't have much time to work on SSR anymore so this hasn't happened yet. I don't consider this a priority. |
|
@MaartenBaert I took the liberty to create a patch for this issue at #499. Please let me know if it needs any fixing before merging over there. |
|
I can't do that, it will break backwards compatibility. Like I explained, I don't consider this important enough to move user settings files around and create sources of confusion. I often ask people to send me their config file when they report a bug, I don't want to explain to them that the file can be in two different locations depending on the version. So I'm not going to do this until I've completed the transition to the new JSON format which is going to break backwards compatibility anyway. |
|
There's migration code in the patch that kicks in automatically on first run to deal with backwards compatibility. |
|
I know, the JSON format contains similar code, except that it also does a format conversion. I don't want to deal with breaking things twice, that's the issue. It's already going to be ugly enough since I will need to maintain support for the old settings file format in order to do the conversion. I don't want to also search for those files in two different places. Please realize that these XDG specs are just a convention, they have no effect at all on how users will perceive the software. They won't care, and there's still plenty of other highly popular software in the home directory (e.g. firefox), so I don't want to create additional work for myself for no reason. If you really want the .ssr folder in ~/.config, you can just symlink it there, SSR won't care. |
|
It's not really breaking things when you have a straight migration path. I could take a look at a JSON branch and port the patch over there. Although I do find it weird that you would switch the settings to a JSON format, INI files are perfectly fine for storing settings and JSON only presents benefits over it as an exchange format. With that said, adding a migration path to JSON right after the migration code added by this patch will save you from having to maintain either the old paths or the old format. XDG specs are a widely-used convention and in fact because of it, it does have an effect on how users perceive the software. See bug reports for: Thunderbird, Cargo, Firefox, IntelliJ IDEA, Telegram, Visual Studio Code, node-gyp, PlayOnLinux... I could go on. Many users simply don't like seeing their Home folders polluted with a folder for every application, and for every one of those that don't follow the spec there's a need for a special case in any configuration backup script. By fixing this bug you wouldn't add any work for yourself because that's what the spec is made to solve. Configuration files go to |
|
You don't know that I now spend a lot more time supporting SSR than developing it. It's frustrating but that's how it is. So anything that makes troubleshooting more difficult does cost me a lot of time. And moving around config files is one of those things. You can keep repeating it but I still don't believe that the benefit of having the SSR files in the correct place will outweigh the extra time it will cost me to explain to confused users where they can find their files, and why the instructions they are finding on random forums/blogs/github issues/... are no longer valid. And then there's the future maintenance cost of the transition code. No code is maintenance-free, especially code that interfaces with changing external things like config files. If you don't believe this will confuse users, let me tell you this: I repeatedly get emails from people asking me why their files are or are not being split into segments. Even though the 'separate file per segment' checkbox is clearly marked and right there below the file name. Which should be the most obvious place to look for when dealing with something related to saving files, and yet many people apparently completely miss it and start emailing to to ask why this is happening. And I know that half of these people have clicked that checkbox at least once because they changed it from the default. People are really good at getting confused apparently, and also really good at emailing me when it happens, but not so good at figuring it out for themselves ;). The JSON branch is actually the 'record-schedule' branch which is currently in a badly broken state. Basically I tried to do too many things at once, ran out of time before I could complete the work and was forced to continue development on the main branch to fix various more urgent issues. Now the record-schedule branch is horribly behind. The switch to JSON happened because INI files have no decent support for lists, which I needed for schedules. I don't find it acceptable to use keys with incrementing numbers like KDE does, that's just ugly. Also I wanted to move away from Qt for this because settings files are a backend thing and the backend isn't supposed to mix so heavily with Qt. So I switched to JSON. Then I decided that if I was going to switch, I should immediately make the format such that it would allow multiple video and audio inputs in the future, as well as a few other things like CLI. I also wanted to move the code that handles settings files out of the GUI so it would be accessible for CLI support without depending on the GUI at all. This then forced me to make big changes to how recording settings are processed and also move all the recording logic out of PageRecord and into new classes. Somewhere around there I got stuck - the changes were too drastic and I lost track of what was happening where, and didn't have time to fix it. So I abandoned it. Now I've been meaning to pull useable pieces from it, such as the JSON support, and merge it into the main branch one by one, since that's the only realistic path. So please, don't try to pull JSON support from that branch, it's horribly broken and I need to come up with a decent plan first before I do this transition. Otherwise there's no point in doing it at all. |
|
@MaartenBaert Well, as far as user support goes, I can only suggest you to have a template whenever you're contacted by e-mail for support that directs the user to GitHub to open an issue marked as "support", or even avoid GitHub and point to a Linux forum, and let them know not to bother you personally. You're the main dev of a rather popular project, you should concern yourself with code more than community :). As for your worries of outdated info, I don't think there is enough overlap in people that a) fiddles with SSR config files b) doesn't know about the XDG dir spec and c) they would contact you for a solution to their troubles, for it to be a burden bigger than just following this conversation, even if you add all of them together... and in the end if SSR is switching to JSON files... you're going to have a "luser" problem one way or another. On the other matter that surfaced, that being the separation of concerns... I think at that point you're talking of a rewrite. As you know Qt4 is deeply intertwined to most facets of the application. You'd have to rewrite a shitload of stuff to define clear-cut interfaces and substitute Qt types with std types just to glue it again on the GUI... and so on... At that point, everything is up for consideration and efforts could be better directed at extending libobs from OBS Studio and writing a simpler, more opinionated frontend for it which is SSR's forte. Anyway, if you don't want to have SSR follow the XDG conventions feel free to close my PR and, I suppose, this issue. Nice talking to you :) Have a good one. |
|
P.S. Mozilla products are not good examples. I am not surprised to realize that this for-profit-driven (not free-access-driven) group, which has enough resources to adopt to XDG from now to the next hour, has not done anything in this concern, in over 10 years. I guess, Mozilla prefers to have its products remain under Mozilla is only good for documentations, IMHO. |
|
I know a lot of discussion here has drifted off topic, but I'm curious @MaartenBaert -- did you consider |
|
Readability is very subjective. For me JSON is far more intuitive, since I'm used to writing C++ and Python code. The syntax is almost identical. If I have to write YAML data, I have to look up the rules. JSON also fits better with the type systems I'm used to. |
|
Nearly all json is also valid yaml, and as far as I know all json types are also valid yaml types. I personally find comments to be very helpful in configuration files, and json does not support comments (another reflection of the exchange-oriented, not human-oriented design). But don't mind me, I actually ended up here by accident and am not an |
|
I am an ssr user for several years and I've never had a need to hand-edit a config file. So if that will still be the case in any updated GUI or future implementation, then as a user I don't care if the config is json or yaml. I do agree that yaml is a better config file format. However, I've recently learned of HOCON, and it seems like it has some nice features for configuration files that are intended to be human readable and hand editable. It's originally a Java library, but the cpp implementation is called cpp-hocon. So you might want to take a look at that too, if you haven't already considered it. |
|
I've now implemented a compromise: if the |
|
That's a good step forward, thanks! Unfortunately, it still does not affect fresh installations, so it's effectively not very useful by default. |
|
I agree with @ratijas, ideally it should default to |
|
Ideally it should have been like that from the start, the problem is that if I change it now, I will have to tell everyone in all future support emails that they should send me the logs which are located either in |
I don't see how that is a problem. Just, you know, make a template email, and use/copy it as a base answer. And tell folks to use the latest version, always (yeah, I know, that might be problematic with ancient distros). |
|
@MaartenBaert, does doron-cohen/antidot@9c0bbff not remediate this problem? |
|
Create the dir in .config; During installation ask if someone wants a symlink to .ssr/ in their home dir; default it to NO and that'll be great. |
Absolute overconfigurability. How any normal user should care or even know about that? I don't get it, how this issue is still a problem in 2022? |
Data should be under
~/.local/share/SimpleScreenRecorder/(e.g. input-profiles and output-profiles).Configuration should be under
~/.config/SimpleScreenRecorder/.Cache should be under
~/.cache/SimpleScreenRecorder/(e.g. logs).See
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
https://ploum.net/207-modify-your-application-to-use-xdg-folders/
The text was updated successfully, but these errors were encountered: