GNOME Bugzilla – Bug 142317
hiding gnome panel doen't allow me the use of the whole screen...
Last modified: 2015-03-24 13:00:49 UTC
...and if you can't use the space, what is the point in even having "hide" buttons Simply put, the hide buttons on the gnome panel will slide it back, leaving just the little tab a la MacOS. But the little tab behaves like the regular panel in that nothing can occupy the same space on the display. This means that applications that are maximized on the screen still leave vacant the space that the panel normally occupies. I was originally going to list this as an "enhancement" bug, but since it effectively moots the "hide buttons" feature, I thought it might merit a bit more attention. I would suggest that perhaps the panel should be always on top, but allow other windows to maximize under it, like a normal top window. Along the same lines (thinking back to the MacOS 9 interface), it would be a nice enhancement to be able to have panel(s) of arbitrary width, attached to the side(s) of the screen that could be hidden leaving an always-on-top tab.
Probably should remove the strut hint when hidden ..
Created attachment 27799 [details] [review] Proposed patch Followed mark's suggestion to change strut hint when the panel is hidden.
Upping pri because we have a patch now.
There's a lot of unnecessary whitespace changes in there. Not that it really matters much in a patch of this size, but leaving that out is a good rule of thumb to make patches as easy to review as possible.
Hmm, I think what I really meant to say was that we should the window type to _NET_WM_WINDOW_TYPE_NORMAL instead of _NET_WM_WINDOW_TYPE_DOCK when its hidden. Note we should *not* do this when its autohidden.
Created attachment 28284 [details] [review] Proposed patch Mark: I have added what u suggested to what I had done earlier. Is this correct or should I submit a patch containing only the changes you mentioned in comment #5 (That does not give intended behavior)? BTW what was wrong with the earlier patch.. just wondering.
*** Bug 145148 has been marked as a duplicate of this bug. ***
ping : can someone apply this patch ?
Comments on the patch: - drop spurious whitespace changes - when removing the if () tests in panel-xutils.c also reduce indentation of the code block that used to be under the test?
Sagar : can you provide an updated version of the patch ? Thanks !
Created attachment 32435 [details] [review] Proposed patch MAde the requested changes.
I'd do this more like: 1) add a panel_struts_unset_window_hint() void panel_struts_unset_window_hint (PanelToplevel *toplevel) { if (!GTK_WIDGET_REALIZED (toplevel)) return; panel_xutils_set_strut (GTK_WIDGET (toplevel)->window, 0, 0, 0, 0); } 2) Update panel_struts_set_window_hint() to use unset_window_hint() when there's no strut 3) Update panel_toplevel_update_struts() to have something like: if (toplevel->priv->state == PANEL_STATE_NORMAL || toplevel->priv->state == PANEL_STATE_AUTO_HIDDEN) panel_struts_set_window_hint (toplevel); else panel_struts_unset_window_hint (toplevel);
Could you update the patch according to Mark's comments?
Sorry for the spam. Mass-marking some bugs to the 2.10.x milestone. Filter on "VINCENT WANTS THIS FOR 2.10" to ignore.
> Hmm, I think what I really meant to say was that we should the window type to > _NET_WM_WINDOW_TYPE_NORMAL instead of _NET_WM_WINDOW_TYPE_DOCK when its hidden. Mark: I don't understand this. The toplevel is still a panel and having the button always on top is a good thing. Why would you want to have _NET_WM_WINDOW_TYPE_NORMAL?
Created attachment 36743 [details] [review] Proposed patch Here's my attempt. It seems to be working well.
I'm convinced my patch is right ajnd we don't need to set the panel type to _NET_WM_WINDOW_TYPE_NORMAL so I went ahead.