@Thomas:
> Parsing out the panel name from the complete URL passed to settings app is 
> not a big deal, in fact it's just one line of code using 
> QUrl::path()

right, it wouldn't be a big deal also to call "system-settings <name>"
which is already supported. The fact that it's little code doesn't make
a convenient argument on why that syntax is better than the one we are
currently using and which is working...

> Why does it have to pass the whole string? The settings://system/ part
> is only interesting to the URL dispatcher so it can find out what to
> launch. It'd make the application code nicer if we only had to take the
> information which is interesting to us - the name of the panel.

One advantage of supporting the full url scheme is that you could click
on "system://..." urls in e.g an email or your web browser and have it
working through the standard url handler mechanism (that takes the
default app and give it the url as a parameter). Not sure that's a
feature we want though, I'm not sure I want to make easy for spammer to
bring users to system settings with a click for example...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1227690

Title:
  should support settings://system/<...> urls

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-system-settings/+bug/1227690/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to