Slava just added application settings to MMS Logger on OpenRepos, available from the Settings application like Jolla's own applications. As far as I can see, there is nothing which prevents other applications which are hosted on OpenRepos from reusing this code as it's BSD licensed. I would encourage any Sailfish application developer to take a look.

I would encourage anyone using that abomination to come to their senses and move application settings where they belong - in the application itself!

No! It makes so much more sense to keep all settings in one place. This stays true to multitasking: you can change settings while the application is running without going back and forth between menus to see the changes in action. More importantly, you can also change settings without needing the application to be running, which is particularly useful for heavy things like Stellarium, a web browser, a navigation application, and so on. They won't consume any memory, processing or battery power, and they won't automatically load pages/tiles which you don't need at that moment.

The API isn't final, afaik, even after almost three years of SailfishOS. Because of it, it is a mess. Harbour apps cannot use it, so if you want to publish your app in Harbour, this method will not be accepted anyway. I wonder if Jolla still believes this is the way forward.

And frankly I agree with pichlo, to change a simple setting all the way via the settiings app, scroll all the way to the bottom, then find the app again in the grid, is way too cumbersome.

The process could certainly be improved. For one, applications without settings (or without settings in Settings) should be hidden.

(everyone has an opinion)

I would prefer all applications to have a common place (as originally thought by Jolla) and the settings option in the application to be able to open this panel. That is, have the same settings panel accessible from both places with the application running or not.

Most important, the settings should be backed up by the standard backup. (In Maemo you could define in the design which settings to be backed-up)

I see this as yet another developer and user public relations fail. Uncertainty is bad - they should have long ago decided and either:

Announced that the interface will never be officially available for third party apps & label it accordingly (System apps in options, etc.).

Or say that it will bee officially available (eventually...) and possibly even actually implement that.

This is pretty much the same thing I wanted to write - let's do it both ways! Both ways have their pluses and minuses, so lets combine them! There shouldn't be a big overhead as long as this is done properly. It also makes the apps more portable - they would still work on platforms without a central per-app config location.

Also one one argument (possibly already heard) for keeping the central app settings location: headless apps.
There might be applications that provide some non-app (no app icon) functionality and need a way to be configured. You could always do a app-icon and fake app - basically just a configuration screen, but a config screen accessible from unified settings just seems more elegant.

That should be perfectly possible & it was one of the arguments for the XDG-based & quite strict app folder hierarchy enforced for Harbor apps. It would be nice if it could actually be used for it's purpose.

I think its basically just missing functionality in the backup tool - any idea how much open source is it ? Just the backend and not the UI, as usual ?

https://github.com/sailfish-sdk/sdk-...idator/pull/79

Does it?

When I am in my upstairs bedroom and want to switch the light off, I do not expect to have to go down to the garage where all the light switches are. I expect the light switch to be present in the room.

I do not mind having the switches in both places as per Saturn's and MartinK's idea but the primary place should be where they are most immediately needed.

It's more like these 'smart' houses where you can switch off the lights from wherever you are in the house, as you can open Settings from wherever you are as well.

One other reason for the central settings location is that no two applications put their settings in the same place. One links to them in the pulley menu of the main view, another has them on a subpage, another has them hidden behind a button on a sidescrolling bar, or you have to open the application twice, or you have to go to the pulley menu on a specific page, and so on. No one remembers all this. With central settings, you don't have to look for anything because everything is right there.