After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650699 - add a way to hide panels
add a way to hide panels
Status: RESOLVED INCOMPLETE
Product: gnome-control-center
Classification: Core
Component: shell
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
touch 3.10
: 659617 661097 689201 689202 690657 (view as bug list)
Depends on:
Blocks: 681762 682205
 
 
Reported: 2011-05-20 22:40 UTC by Matthias Clasen
Modified: 2018-04-17 15:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (9.34 KB, patch)
2011-05-20 22:40 UTC, Matthias Clasen
none Details | Review
Shell: check OnlyShowIn from desktop file to determine if we whould display icons. (1.21 KB, patch)
2013-04-29 12:20 UTC, darkxst
rejected Details | Review
shell: Add _get_visibility() vfunc to hide panels (11.14 KB, patch)
2018-01-12 07:21 UTC, Jonathan Kang
none Details | Review
shell: Add CcPanelVisibility enum (1.17 KB, patch)
2018-01-18 09:52 UTC, Jonathan Kang
reviewed Details | Review
shell: Add _get_visibility() vfunc to hide panels (2.02 KB, patch)
2018-01-18 09:53 UTC, Jonathan Kang
reviewed Details | Review
shell: hide panels when control center starts (8.90 KB, patch)
2018-01-29 09:07 UTC, Jonathan Kang
none Details | Review
shell: show/hide bluetooth panel when needed (3.09 KB, patch)
2018-02-05 07:41 UTC, Jonathan Kang
none Details | Review

Description Matthias Clasen 2011-05-20 22:40:38 UTC
Created attachment 188256 [details] [review]
patch

This might be necessary for panels that are only good for specific types of hw.

Here is a patch that makes this possible, by letting the panels implement a should_be_visible() vfunc.
Comment 1 Richard Hughes 2011-05-20 22:55:29 UTC
I like this idea a lot, although doesn't a vfunc mean that we have to load all the plugin deps at startup rather than lazy load them? Maybe we do this already...
Comment 2 Bastien Nocera 2011-05-20 23:18:51 UTC
We already load all those plugins, we just don't activate them. What I don't really like is the sync functions. What devices would this be used for, apart from tablets?
Comment 3 Matthias Clasen 2011-05-21 15:01:57 UTC
Don't really know of examples, that's why I decided to park this patch here until it becomes relevant...
Comment 4 Matthias Clasen 2011-07-15 12:13:34 UTC
wacom tablets come to mind as an example
Comment 5 Bastien Nocera 2011-07-15 12:22:21 UTC
(In reply to comment #4)
> wacom tablets come to mind as an example

comment 2 says "apart from tablets". It's not a good example as tablets can be Bluetooth ones (eg. configured but not connected) and we'd need the visibility of the panel to be instantaneous.
Comment 6 Jakub Steiner 2011-09-20 16:32:09 UTC
*** Bug 659617 has been marked as a duplicate of this bug. ***
Comment 7 Bastien Nocera 2011-10-06 15:46:50 UTC
*** Bug 661097 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Clasen 2011-10-06 17:51:18 UTC
Another example that was brought up is

- bluetooth, if your system doesn't have a bt adapter

- keyboard and mouse, if this is a tablet without those
Comment 9 Matthias Clasen 2011-10-06 21:46:33 UTC
A small idea: we could arrange things so that panels still show up in the search results, even when they are 'hidden'. Then a search for 'wacom' would still get you to the tablet panel
Comment 10 Jakub Steiner 2011-10-07 11:55:38 UTC
(In reply to comment #9)

That was my proposal. I would still indicate them not being detected/available using 50% opacity on the icon.
Comment 11 Bastien Nocera 2012-09-18 21:58:37 UTC
I don't think that we should be hiding the Bluetooth panel. Maybe we should give a way for system administrators, or system integrators to hide it, but the fact is that there's barely any (laptop) machines without Bluetooth right now. There's also the fact that it's hard to query for it quickly, without blocking the UI. I would always show it.

Keyboard and mouse could be hidden, Wacom certainly, we would also hide either the "User Accounts", or the "User Account" panel (bug 681762) based on a lockdown value.

In Matthias' patch, we should have 3 different returns for cc_panel_class_should_be_visible():
- show
- hide, but show in the search results
- always hide

We might also want the value to change based on hotplug, so having that return value as a property would make it easier to hook up to the models we use.
Comment 12 Bastien Nocera 2012-11-28 10:07:02 UTC
*** Bug 689202 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2012-11-28 10:07:26 UTC
*** Bug 689201 has been marked as a duplicate of this bug. ***
Comment 14 Bastien Nocera 2013-01-07 15:02:21 UTC
*** Bug 690657 has been marked as a duplicate of this bug. ***
Comment 15 darkxst 2013-04-29 12:20:02 UTC
Created attachment 242792 [details] [review]
Shell: check OnlyShowIn from desktop file to determine if we whould display icons.

This is essentially our solution to bug 690657, but that was marked a dupe of this
so will post here. It does however provide a nice easy way for distro's to hide
irrellevant panels based on desktop, which was the previous behaviour before the
gmenu code was removed.
Comment 16 Bastien Nocera 2013-04-29 12:30:52 UTC
Comment on attachment 242792 [details] [review]
Shell: check OnlyShowIn from desktop file to determine if we whould display icons.

That's really not what this bug is about.

Furthermore, if somebody is patching the control-center to add new panels, they can also do this in their own code.
Comment 17 Allan Day 2017-10-04 10:55:00 UTC
Since the control center shell changed to use a sidebar, it seems like we should revisit this bug. I'd always imagined that one of the objectives of the sidebar design was to make it easier to hide some settings panels when they're not relevant. Possibilities include:

 * Wi-Fi
 * Bluetooth
 * Keyboard
 * Mouse & Touchpad
 * Wacom Tablet
Comment 18 Felipe Borges 2017-10-09 09:59:51 UTC
If we decide to go for this feature, we should at least offer a gsetting for "show-all-panels", for use-cases where this behavior is unwanted.
Comment 19 Bastien Nocera 2017-10-09 11:09:40 UTC
(In reply to Felipe Borges from comment #18)
> If we decide to go for this feature, we should at least offer a gsetting for
> "show-all-panels", for use-cases where this behavior is unwanted.

No need. The search (both in the control-center shell and in gnome-shell) would still show the panels.
Comment 20 Paul Smith 2017-10-31 15:42:08 UTC
Today's experience for people on desktops or other systems without wifi is pretty sub-optimal: you start the control center and it chooses the first item on the list which happens to be... Wi-Fi!

So you get a default screen with a big question mark in it, saying "No Wi-Fi Adapter Found".  I also have no Bluetooth adapter.

And adding insult to injury, important stuff is not visible in the menu without scrolling (bug #789372 and bug #786810) to make room for these.

It could be that I would plug in a USB wifi or bluetooth adapter so I guess the hardware could come into existence sometime in the future.
Comment 21 Jonathan Kang 2017-11-01 07:13:37 UTC
(In reply to Allan Day from comment #17)
> Since the control center shell changed to use a sidebar, it seems like we
> should revisit this bug. I'd always imagined that one of the objectives of
> the sidebar design was to make it easier to hide some settings panels when
> they're not relevant. Possibilities include:
> 
>  * Wi-Fi
>  * Bluetooth
>  * Keyboard
>  * Mouse & Touchpad
>  * Wacom Tablet

Maybe Network panel as well when NetworkManager is not running(e.g. someone uses
wicked to manage their netowrk).
Comment 22 Jonathan Kang 2018-01-04 09:58:26 UTC
(In reply to Bastien Nocera from comment #2)
> We already load all those plugins, we just don't activate them. 

I'm trying to implement this feature recently, and find out that it seems that
this is not true anymore with commit 0139f684162a10dfa159313552ff96b08f359cd5.
So adding a should_be_visible() vfunc won't work.

Correct me if I'm wrong.
Comment 23 Bastien Nocera 2018-01-10 15:18:23 UTC
(In reply to Jonathan Kang from comment #22)
> (In reply to Bastien Nocera from comment #2)
> > We already load all those plugins, we just don't activate them. 
> 
> I'm trying to implement this feature recently, and find out that it seems
> that
> this is not true anymore with commit
> 0139f684162a10dfa159313552ff96b08f359cd5.
> So adding a should_be_visible() vfunc won't work.
> 
> Correct me if I'm wrong.

It still works as it did then. The vfunc should be on the class, not the instance, as the instance is only created when the panel is loaded.
Comment 24 Jonathan Kang 2018-01-12 07:21:46 UTC
Created attachment 366702 [details] [review]
shell: Add _get_visibility() vfunc to hide panels

_get_visibility() vfunc is added to CcPanelClass to enable the ability 
to hide panels if necessary.
Comment 25 Bastien Nocera 2018-01-12 13:32:36 UTC
Review of attachment 366702 [details] [review]:

That doesn't seem to allow panels to appear as services/devices become available, just checked once at startup.

I think the class member should probably be for a class signal (I'm not sure whether GObject supports those though.

It would also be good to:
- split off the enum declaration in a separate patch
- split off the API addition for panels from the use of that API in the shell itself

And, in a separate patch, implementation for at least one panel. For example, whether or not to show the Wi-Fi panel, and making sure that the panel appears when unblocking hardware rfkill on it, or plugging in a Wi-Fi dongle if the machine you're testing this on doesn't have a Wi-Fi adapter. Or showing/hiding the Wacom panel, which might be easier to implement.

::: shell/cc-panel.h
@@ +57,3 @@
+ * @CC_PANEL_VISIBILITY_HIDE:
+ *
+ * Visibility of panels, to devide whether a panel should be visible or not.

divide? decide?
Comment 26 Jonathan Kang 2018-01-15 09:58:56 UTC
(In reply to Bastien Nocera from comment #25)
> Review of attachment 366702 [details] [review] [review]:
> 
> That doesn't seem to allow panels to appear as services/devices become
> available, just checked once at startup.
> 
> I think the class member should probably be for a class signal (I'm not sure
> whether GObject supports those though.

We can use signals(show/hide that panel) emitted by each panel, and maybe connect
to some callbacks in cc-panel-list.c where we can add/remove panels from the
list. I'm not quite sure if this is doable. But I'll spend some time on it.
> 
> It would also be good to:
> - split off the enum declaration in a separate patch
> - split off the API addition for panels from the use of that API in the
> shell itself

Sure.
> 
> And, in a separate patch, implementation for at least one panel. For
> example, whether or not to show the Wi-Fi panel, and making sure that the
> panel appears when unblocking hardware rfkill on it, or plugging in a Wi-Fi
> dongle if the machine you're testing this on doesn't have a Wi-Fi adapter.
> Or showing/hiding the Wacom panel, which might be easier to implement.

Bluetooth works for me as I have a PC without bluetooth adapter and a USB
bluetooth adapter. So I'll try to implement this.
> 
> ::: shell/cc-panel.h
> @@ +57,3 @@
> + * @CC_PANEL_VISIBILITY_HIDE:
> + *
> + * Visibility of panels, to devide whether a panel should be visible or not.
> 
> divide? decide?

decide. It was a typo. Sorry about that.
Comment 27 Jonathan Kang 2018-01-18 09:52:13 UTC
Created attachment 367002 [details] [review]
shell: Add CcPanelVisibility enum
Comment 28 Jonathan Kang 2018-01-18 09:53:09 UTC
Created attachment 367003 [details] [review]
shell: Add _get_visibility() vfunc to hide panels
Comment 29 Jonathan Kang 2018-01-18 09:58:23 UTC
I attached the first two patches here for review. The implementation in the shell
part is still ongoing. I'll attach it when it's finished.
Comment 30 Georges Basile Stavracas Neto 2018-01-26 01:19:05 UTC
Review of attachment 367002 [details] [review]:

It's simple enough, but I'll wait to have a more in depth look when the whole patchset is ready.
Comment 31 Georges Basile Stavracas Neto 2018-01-26 01:19:48 UTC
Review of attachment 367003 [details] [review]:

Same as the first one
Comment 32 Jonathan Kang 2018-01-29 09:07:30 UTC
Created attachment 367561 [details] [review]
shell: hide panels when control center starts

Sorry for being this long since last two patches. I'm having trouble implementing
this feature that showing/hiding panels when related service/device goes up/down.

This patch just hides panels when control center starts.

Basically the problem I met is not knowing a way to connect
signals(service/device goes up/down) from various panels to callbacks in
CcPanelList where we can show/hide that panel from the list.

For example, if users haven't clicked the Bluetooth panel yet, no instance
of CcBluetoothPanel will be created. So when users plug/unplug a bluetooth
dongle, no instance is able to emit such a signal for more actions that need
to be done.

Maybe we can use some utility functions/codes for such a thing? What do you
think of this idea? I want raise this issue here for some discussions.

Thanks
Comment 33 Bastien Nocera 2018-01-29 12:50:07 UTC
(In reply to Jonathan Kang from comment #32)
> Created attachment 367561 [details] [review] [review]
> shell: hide panels when control center starts
> 
> Sorry for being this long since last two patches. I'm having trouble
> implementing
> this feature that showing/hiding panels when related service/device goes
> up/down.
> 
> This patch just hides panels when control center starts.
> 
> Basically the problem I met is not knowing a way to connect
> signals(service/device goes up/down) from various panels to callbacks in
> CcPanelList where we can show/hide that panel from the list.
> 
> For example, if users haven't clicked the Bluetooth panel yet, no instance
> of CcBluetoothPanel will be created. So when users plug/unplug a bluetooth
> dongle, no instance is able to emit such a signal for more actions that need
> to be done.
> 
> Maybe we can use some utility functions/codes for such a thing? What do you
> think of this idea? I want raise this issue here for some discussions.

You need to implement this at the class-level, not at the instance level. Either that, or come up with a companion object for each panel to implement this.
Comment 34 Jonathan Kang 2018-02-05 07:41:57 UTC
Created attachment 367893 [details] [review]
shell: show/hide bluetooth panel when needed

Hi, this is still a WIP patch. I'm attaching this to show the way I want to
implement this:

1. Add needed object to emit signals when devices/services go up/down. In this
patch, add "GDBusProxy *bluetooth_rfkill;" in _CcPanelList to indicate when
bluetooth device is available/unavailable.
2. Connect related signal to a callback function in cc-panel-list.c to show/hide
the bluetooth panel.

Comments are welcome.
Comment 35 Bastien Nocera 2018-04-17 15:00:24 UTC
The discussion can continue here, where an implementation is already available:
https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/29