GNOME Bugzilla – Bug 636317
statusMenu: Force the overview mode of the settings
Last modified: 2010-12-03 16:00:13 UTC
As requested by Florian
Created attachment 175728 [details] [review] statusMenu: Force the overview mode of the settings When launching gnome-control-center, request it to show the overview rather than just presenting the current window.
Review of attachment 175728 [details] [review]: Unfortunately, this is going to make the "System Settings" do nothing at all for someone testing the shell with older GNOME. <owen> can someone with gnome-2 check what 'gnome-control-center -o' does? Does it start with a warning or not start at all? <fcrozat> owen: unknown option <fcrozat> doesn't start <fcrozat> (on 2.30.1) That isn't a priority problem - the only version of GNOME that GNOME Shell is supposed to work with is GNOME 3, but is there anything obvious to do here? Doesn't seem that gnome-control-center (at least the new version) supports --version and if it did, adding code to parse the output would be unpleasant. We actually include gnome-control-center in the gnome-shell moduleset, so maybe the right thing to do is to just force running gnome-control-center from the same path. (I don't know if we build a fully working gnome-control-center but it should at least come up.) Hmm, but that would be easiest to handle when the config.js.in addition in the bluetooth code lands. So, why don't we go ahead and land this patch, and then when someone complains, we can add a workaround to run $prefix/bin/gnome-control-center.
(In reply to comment #2) > Review of attachment 175728 [details] [review]: > > Unfortunately, this is going to make the "System Settings" do nothing at all > for someone testing the shell with older GNOME. > > <owen> can someone with gnome-2 check what 'gnome-control-center -o' does? Does > it start with a warning or not start at all? > <fcrozat> owen: unknown option > <fcrozat> doesn't start > <fcrozat> (on 2.30.1) > > That isn't a priority problem - the only version of GNOME that GNOME Shell is > supposed to work with is GNOME 3, but is there anything obvious to do here? > Doesn't seem that gnome-control-center (at least the new version) supports > --version It most certainly does, I added it at the same time as "-o". > and if it did, adding code to parse the output would be unpleasant. > > We actually include gnome-control-center in the gnome-shell moduleset, so maybe > the right thing to do is to just force running gnome-control-center from the > same path. (I don't know if we build a fully working gnome-control-center but > it should at least come up.) > > Hmm, but that would be easiest to handle when the config.js.in addition in the > bluetooth code lands. So, why don't we go ahead and land this patch, and then > when someone complains, we can add a workaround to run > $prefix/bin/gnome-control-center. I would think that it's a case for distributions fixing their dependencies, rather than for us to try and work around problems like that.
Attachment 175728 [details] pushed as b40cc2c - statusMenu: Force the overview mode of the settings
(In reply to comment #2) > Review of attachment 175728 [details] [review]: > > Unfortunately, this is going to make the "System Settings" do nothing at all > for someone testing the shell with older GNOME. At least for now, gnome-control-center 3 is part of the moduleset, so it should take preference over the system version anyway.
(In reply to comment #5) > (In reply to comment #2) > > Review of attachment 175728 [details] [review] [details]: > > > > Unfortunately, this is going to make the "System Settings" do nothing at all > > for someone testing the shell with older GNOME. > > At least for now, gnome-control-center 3 is part of the moduleset, so it should > take preference over the system version anyway. We don't set $PATH in the gnome-shell wrapper script. (and not sure we should)
(In reply to comment #3) > > Hmm, but that would be easiest to handle when the config.js.in addition in the > > bluetooth code lands. So, why don't we go ahead and land this patch, and then > > when someone complains, we can add a workaround to run > > $prefix/bin/gnome-control-center. > > I would think that it's a case for distributions fixing their dependencies, > rather than for us to try and work around problems like that. Not concerned about distros, more concerned about people using the gnome-shell jhbuild on older distros (which, as Florian says does build gnome-control-center. I'm not completely sure it builds a *working* control center, and it won't be on $PATH)