Little fixes + CP Guidelines

[Digitalone1]

• use trim start in parse spinbutton output ( -inf with leading spaces was not caught)
• adjust the return type of parse_spinbutton callbacks
• avoid parenthesis in preferences row titles and use subtitles

[github-actions]

Workflow failed, but the following artifacts are still available for this pull request:

• easyeffects-archlinux-merge-6fff01e78-into-248a12f3b-x86_64.zip
• easyeffects-flatpak-merge-6fff01e78-into-248a12f3b-x86_64.zip

[Digitalone1]

@wwmm I wrote the guidelines for Community Presets. Take a look at them, see if the place and the name of the file are correct. Then please link it inside the master README.md.

[vchernin]

I think this write up is quite good.

Although I do think it is strange to put this in a markdown file in the repo when virtually all other similar documentation is in the wiki. In addition to adding these guidelines, the presets wiki page intended for users will also need to be updated. To me it makes sense to keep everything in one place.

[Digitalone1]

Although I do think it is strange to put this in a markdown file in the repo when virtually all other similar documentation is in the wiki. In addition to adding these guidelines, the presets wiki page intended for users will also need to be updated. To me it makes sense to keep everything in one place.

I though that too. The problem is that the Wiki is modifiable by everyone and that's not good. I don't even know if all the changes to the wiki are checked. For this guidelines we need a document that has to be reviewed by the project maintainers only.

[vchernin]

I though that too. The problem is that the Wiki is modifiable by everyone and that's not good. I don't even know if all the changes to the wiki are checked. For this guidelines we need a document that has to be reviewed by the project maintainers only.

With the possible exception of the current community presets and package repositories pages I don’t think the wiki really needs to be publicly editable in the first place. Changes to the rest should really be reviewed first.

But if the wiki is collaborator editable only @wwmm will have to copy paste all suggested changes manually. Despite the github wiki being stored as a git repo there is no way to send a pr to my knowledge.

Instead we could just move all the wiki pages to markdown files into a wiki directory in master and stop using the github wiki feature altogether. Files in the repo might be less discoverable, but most people are probably following links from the readme to get there anyways. For "backwards compat" we could add a bunch of "this page is now moved into the wiki directory at wiki/file_name.md" redirects in the wiki.

However perhaps moving all the wiki pages is overkill given most wiki pages don’t need to be edited very often to begin with.

[Digitalone1]

@vchernin maybe @wwmm has a solution. I'd like to have these guidelines restricted to maintainers only.

Anyway the guidelines needs also instructions for the flatpak ID that the extensions should have in order for preset files to be mounted in the easyeffects flatpak filesystem. But I don't know very much on that point, Maybe you can add something with a PR (or changing the wiki).

Where is stored the easyeffects flatpak filesystem? Is it contained in one of the folders mentioned in the guidelines?

[wwmm]

I also think that the guidelines are well written.

maybe @wwmm has a solution. I'd like to have these guidelines restricted to maintainers only.

Not really. I am not aware of a way to achieve this. Personally I do not think that is worth to move everything to the repository. We did not have had cases of bizarre misuses of the public wiki. And there are some things there that may be useful for some people that I would never had taken the time to write them myself. Like the sections about headless operation or the one about third party extensions.

I admit that I am not comfortable with public access. But having one more thing to micromanage isn't great either.