Preference Opening Specification

[Corentin Noël]

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'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer

[Jasper St. Pierre]

I'm not against this, but what's the goal for applications to be able
to launch the System Settings? Some entries like "Privacy" seem fairly
opaque -- anything in there I could also imagine being in other places
in other DEs. If the goal is to be able to direct users to a certain
setting, these categories seem too coarse for anything out of the
ordinary.

If I have a screen sharing app, and I want to direct users to be able
to enable it, is that under "Privacy", "Security", or "Network
Sharing"? What about file sharing?

On Fri, Jan 15, 2016 at 3:28 PM, Corentin Noël

Post by Corentin Noël
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.
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Corentin Noël]

Post by Jasper St. Pierre
I'm not against this, but what's the goal for applications to be able
to launch the System Settings? Some entries like "Privacy" seem fairly
opaque -- anything in there I could also imagine being in other places
in other DEs. If the goal is to be able to direct users to a certain
setting, these categories seem too coarse for anything out of the
ordinary.

That's where the freedesktop group is useful, let me know the categories
that would make sense in most distributions.
About the use, not just apps but other parts of the desktop environment
would be using it too.

Post by Jasper St. Pierre
If I have a screen sharing app, and I want to direct users to be able
to enable it, is that under "Privacy", "Security", or "Network
Sharing"? What about file sharing?

Well you're already covering the corner cases, but I think it's the same
issue as asking how as a user would I find X setting in the setting app. So
here I have no answer for you yet as I've never seen screen sharing on the
desktop.

Post by Jasper St. Pierre
On Fri, Jan 15, 2016 at 3:28 PM, Corentin Noël

Post by Corentin Noël
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.

https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

Post by Jasper St. Pierre

Post by Corentin Noël
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Jasper

[Mattias Andrée]

Why would this be useful? And what about when none of
these are implemented, would that be a problem?

On Sat, 16 Jan 2016 00:28:37 +0100

Post by Corentin Noël
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.
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer

[Corentin Noël]

Post by Mattias Andrée
Why would this be useful? And what about when none of
these are implemented, would that be a problem?

It's then the same problem as clicking on an URL when you don't have any
web browser. Nothing will happen, your users will complain as "not
working", but it the same if you hardcode things for unity-control-center
and you only have gnome-control-center installed.

Post by Mattias Andrée
On Sat, 16 Jan 2016 00:28:37 +0100

Post by Corentin Noël
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.

https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

Post by Mattias Andrée

Post by Corentin Noël
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Mattias Andrée]

Okay, so it is not fatal. But why do you need it?
I think it is important not to introduce a bunch of
standards just for completeness's sake, only if they
are actually needed.

On Sat, 16 Jan 2016 00:57:36 +0100

Le 16 janv. 2016 12:53 AM, "Mattias Andrée"

Post by Mattias Andrée
Why would this be useful? And what about when none of
these are implemented, would that be a problem?

It's then the same problem as clicking on an URL when you
don't have any web browser. Nothing will happen, your
users will complain as "not working", but it the same if
you hardcode things for unity-control-center and you only
have gnome-control-center installed.

Post by Mattias Andrée
On Sat, 16 Jan 2016 00:28:37 +0100

Post by Corentin Noël
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.

https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

Post by Mattias Andrée

Post by Corentin Noël
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Corentin Noël]

Post by Mattias Andrée
Okay, so it is not fatal. But why do you need it?
I think it is important not to introduce a bunch of
standards just for completeness's sake, only if they
are actually needed.

I actually need it in several places in the OS, in our indicators we have
links to settings panel, in settings panels themselves we have crosslinks
to other panels and in some of our apps we tell the user to add an account
to the online accounts panel and give a button to open it. We also could
use it in our web browser to ask the user to check his connectivity...

Post by Mattias Andrée
On Sat, 16 Jan 2016 00:57:36 +0100

Le 16 janv. 2016 12:53 AM, "Mattias Andrée"

Post by Mattias Andrée
Why would this be useful? And what about when none of
these are implemented, would that be a problem?

It's then the same problem as clicking on an URL when you
don't have any web browser. Nothing will happen, your
users will complain as "not working", but it the same if
you hardcode things for unity-control-center and you only
have gnome-control-center installed.

Post by Mattias Andrée
On Sat, 16 Jan 2016 00:28:37 +0100

Post by Corentin Noël
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.

https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

Post by Mattias Andrée

Post by Mattias Andrée

Post by Corentin Noël
I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Vladimir Kudrya]

_______________________________________________
xdg mailing list
***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

[David Faure]

Post by Corentin Noël
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.
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 :-)