Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect XDG base directory specification #407

Open
GreenLunar opened this issue Dec 11, 2015 · 18 comments

Comments

Projects
None yet
6 participants
@GreenLunar
Copy link
Contributor

commented Dec 11, 2015

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/

@SanKro

This comment has been minimized.

Copy link

commented Feb 21, 2016

seems many apps have this problem...

someone on #telegram github site said this

IIRC, Qt will respect those when using the qt settings backend (at least it did on my mobile phone some years ago when I last used Qt).

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Feb 21, 2016

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.

@SanKro

This comment has been minimized.

Copy link

commented Feb 22, 2016

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.

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..
you really should consider to switch over with a Qt5 release(?) in later future

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Feb 28, 2016

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.

@mixedCase

This comment has been minimized.

Copy link

commented Oct 13, 2016

@MaartenBaert Any news on this?

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Oct 13, 2016

I don't have much time to work on SSR anymore so this hasn't happened yet. I don't consider this a priority.

mixedCase added a commit to mixedCase/ssr that referenced this issue Oct 14, 2016

@mixedCase mixedCase referenced a pull request that will close this issue Oct 14, 2016

Open

Implement XDG Base Directory Specification support #499

@mixedCase

This comment has been minimized.

Copy link

commented Oct 14, 2016

@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.

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Oct 14, 2016

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.

@mixedCase

This comment has been minimized.

Copy link

commented Oct 14, 2016

There's migration code in the patch that kicks in automatically on first run to deal with backwards compatibility.

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Oct 14, 2016

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.

@mixedCase

This comment has been minimized.

Copy link

commented Oct 15, 2016

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 $XDG_CONFIG_HOME/ssr, which is ~/.config/ssr by default. Other data files such as logs, go to $XDG_DATA_HOME/ssr, ~/.local/share/ssr by default; and that's consistent. Users expect Linux applications to respect those conventions, so that's what they go for. The patch is ready, and even if you do end up switching file formats, no code would break as long as you call the right functions GetApplicationConfigDir and GetApplicationDataDir (with the existing calls to the removed GetApplicationDataDir already replaced in the patch), the migration code and those functions take care of everything.

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Oct 15, 2016

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.

@mixedCase

This comment has been minimized.

Copy link

commented Oct 15, 2016

@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.

@GreenLunar

This comment has been minimized.

Copy link
Contributor Author

commented Oct 15, 2016

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 /home/username/.product for marketing reasons, so perhaps users would take screenshots of their file managers (or consoles), featuring Mozilla products, accidentally, and some might think that Mozilla is still popular.

Mozilla is only good for documentations, IMHO.

@AndydeCleyre

This comment has been minimized.

Copy link

commented Nov 23, 2016

I know a lot of discussion here has drifted off topic, but I'm curious @MaartenBaert -- did you consider yaml vs json for the config format? As was mentioned, json's real advantage is as an exchange format (truncated segments are clearly invalid), and yaml is much more human-readable and -editable.

@MaartenBaert

This comment has been minimized.

Copy link
Owner

commented Nov 23, 2016

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.

@AndydeCleyre

This comment has been minimized.

Copy link

commented Nov 23, 2016

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 ssr user anyway.

@brianonn

This comment has been minimized.

Copy link

commented May 7, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.