please put config directories under .config

[kavol]

Hi.

After installing the extension and running it, in default config it pollutes the home directory with OOoLilyPond-Language and OOoLilyPond-Templates subdirectories. As these are to store configuration files, I believe the more proper default path would be under ~/.config/oolilypond which gets created anyways.

And while at it, I think it would be better not to even create and populate the directories with files that are part of the package. But rather it would be better to create them on demand, once the user wants to modify the files or add own files.

[KlausBlum]

Hi kavol,

oops - that's a bug. Thanks for your report.

Seven months ago, we've changed the default location for the config file to the XDG-compliant path ~/.config/ooolilypond/ but I wasn't aware that I didn't change the default locations for the "Templates" and "Language" folders as well. (I'm not an everyday Linux user, so I don't have any experience in its typical folder structures.)

You can manually move the "Templates" and "Language" folders and tell OLy the new locations in the config dialogue: https://github.com/openlilylib/LO-ly/wiki/Config#paths-executables-etc I will care about an XDG-compliant default setting for Linux.

As for the need of those two folders, I think it would make the use and configuration of OLy more complicated to deal with on-demand creation etc. IMO at least the template folder is essential. Sooner or later you will be at the point where you don't want to be limited to the built-in templates.

So I'd prefer to leave that part untouched. But if they are located inside a dedicated config folder they should no more be disturbing as they are now. And they never will contain large files, so they only might consume a small amount of disk space.

Cheers, Klaus

[kavol]

I will care about an XDG-compliant default setting for Linux.

Cool, thanks for quick reaction!

As for the need of those two folders, I think it would make the use and configuration of OLy more complicated to deal with on-demand creation etc.

I don't know the internals, what it'd take ... but from my packager's experience, generally, it is easier to use packaged versions of configfiles, where you can apply the fixes and updates, and say something like "hey, user, if you've created your own copy that overrides the defaults then you're responsible for the updates" then to copy the default config for each user and then, after update, apply fixes to those user files when the program doesn't know whether the user config is just a copy of the default which can be safely updated without breaking anything, or whether the user config is carefully handcrafted and any change in it would cause doom. (And not updating the files at all will often cause doom too ...)

On system level, many distributions have tools to deal with configfiles updates, but once you work with user home it's a mess.

(Well, to be honest, I find it pretty sad that I have to install the extension by downloading a file from a random source then opening it in running LO instance for each user, instead of just choosing it in the package manager and installing it system-wide without having to run LO during installation. Then the updates are not part of regular system update run but each user has to check for updates from within running LO. Ouch, not nice. But I'm quite offtopic here - I just want to explain my thinking, to see the difference, if you're experience with Linux distributions is limited.)

Just my opinion ... as said, I don't known how LO extensions work, what is the best, or even what is achievable in this case.

[KlausBlum]

Well, that's true. You lack the luxury of having everything updated by the operating system itself. OTOH, not every Linux application is kept up-to-date by a package. For a Windows user, it is daily life to keep everything up-to-date by hand. (The only exception are the Windows 10 Apps, but honestly, most of that stuff cannot be taken seriously...)

At least, the installation and update process for LibreOffice extensions is exactly the same on Linux and on Windows.

Now back to business... ;-) As for the changes you proposed:

Instead of waiting for the next release, I've updated the default location for the "templates" and "language" folders in the current 1.0.0 release. I think this is the fastest way to have the changes available for new users. For existing users there would be no change, so there would be no reason to update an existing installation.