switchboard-gnome-control-center-override needs switchboard2 port [$105]

[Cody Garver]

Install switchboard-gnome-control-center-override in Isis and observe that indicator Settings links (like Bluetooth) launch Switchboard but don't activate the desired plug.

"Power Settings..." launches gnome control center.

[Corentin Noël (tintou)]

FYI: The --open-plug values have changed since the new switchboard-2.0, it now uses code-names instead of path.

[Avi Romanoff (aroman)]

We're just upstreaming patches to the actual indicators themselves (or shipping our patched versions), so this is no longer needed.

See: https://plus.google.com/+AviRomanoff/posts/NyWP8vaV7EA

[Sergey "Shnatsel" Davidoff (shnatsel)]

There are things like Chromium and hyenas-know-what out there, we can't just drop the runtime compatibility layer.
It should be trivial to adapt for Switchboard 2.0, I'm just waiting on bug #1305345 to be fixed.

[Lewis Goddard (lewisgoddard)]

This bug now has a $50 bounty. https://www.bountysource.com/issues/1441534-switchboard-gnome-control-center-override-needs-switchboard2-port

[Sergey "Shnatsel" Davidoff (shnatsel)]

I've actually made a stab at this back in the day and my resolution was that Switchboard itself needs improvements for this to fly - or for Switchboard to be usable, actually.

You see, gnome-control-center has plug invocations like "gnome-control-center sound". Switchboard in Luna had "switchboard -o sound". But Switchboard 2 has things like "switchboard -o hardware-gcc-sound" for plugs imported from G-C-C and "switchboard -o system-pantheon-about" for native plugs.

This is very problematic to translate to from just "sound", and furthermore, applications calling Switchboard directly should NEVER be concerned with whether the plug is native to Pantheon or not. But with this system the *app* has to know whether it's a native plug or not and call either -gcc- or -pantheon- depending on that. Do we want to break every single native app when we replace a G-C-C plug with a native plug? Hell no!

Same goes for the "hardware-" and such category prefixes. We've moved plugs between categories before and we will probably continue to do so. Apps are not concerned what category a plugs belongs to, and moving plugs between categories or adding/removing categories should not break any apps.

I've honestly tried looking up all the plugs in BASH which turned out to be waaaay more complicated than it should have been and then translating things like "sound" to these full-blown invocations. This logic really should be built into Switchboard itself, either in Vala, or as a script wrapper. I could even write that wrapper if implementing that in Vala proves overly tedious, but I'll need info about where o where the plug names are stored and how to list them without terrible haxxx.

[Cody Garver (codygarver)]

Script updated, built and verified working in iso build 20140708