Preference Opening Specification

[David Faure]

On Saturday 16 January 2016 00:28:37 Corentin Noël wrote:
> Hi everyone,
> Many desktop environments have their own System Settings applications, 
> but there is no clear way for developers to call settings from within 
> their applications  without resorting to hardcoding in commands for 
> each and every Settings app.
> I propose a new specification that similar to other scheme handling in 
> Desktop files, through a new settings:// URI. With this, developers 
> could call on Settings applications, without resorting to hardcoding, 
> provided a desktop environment supports it. For example, an application 
> calling settings://bluetooth would open Bluetooth settings for a given 
> desktop environment.
> 
> Here is the specification I propose:
> https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

I like the idea overall, I see some usefulness for it indeed.

However this spec assumes that a single app (the one associated with  x-scheme-handler/settings
will be able to handle all this. Maybe this isn't the case. For instance in a KDE session, the
settings panel for changing the wallpaper will come from a systemsettings panel provided plasma,
while the firewall might be best handled by OpenSuSE's yast tool.

I think this rather calls for one "pseudo-mimetype" per type of panel, so that a different app
can be associated with each. No settings:// URL scheme needed then, this would simply use
a standard application desktop file for each panel, for instance
[Desktop Entry]
Exec=kcmshell5 randr
MimeType=x-settings/display

This way all the standard mechanism from the mimeapps.list spec can be used to
configure which implementation should be used in case there are multiple implementations
available, including showing the "Plasma wallpaper" panel in a plasma session and showing
the "Gnome wallpaper" panel in a gnome session. It doesn't really make sense otherwise :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5