@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
