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 709413 - RFE: Header bar to support shaded windows
RFE: Header bar to support shaded windows
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
3.12.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
: 749681 780473 (view as bug list)
Depends on:
Blocks: CSD
 
 
Reported: 2013-10-04 07:37 UTC by junk
Modified: 2018-03-29 17:33 UTC
See Also:
GNOME target: ---
GNOME version: 3.9/3.10


Description junk 2013-10-04 07:37:36 UTC 
The header bar does not support shading of windows.


Possible arguments for are: This leads to inconsistancy when using other gtk apps which have the normal window manager title bar. 

A shaded window means that you can look at other windows without going into overview mode or minimising the window which takes it off screen.

Testing:
Using gnome-tweak-tool set doubleclick title bar to shaded. try double clicking some windows without the header bar, then double clicking gnome-files or gnome-tweak-tool
Comment 1 Matthew Miller 2013-10-30 11:44:17 UTC 
I would like to see this as well. Shading windows (a feature from the amazing-for-its-time Amiga OS UI) is a great replacement for minimization, with a natural answer it "where did that window go?", and preserving spacial memory.

So, it's not just consistency, but actually a very useful feature which fits well with the Gnome 3 UI.
Comment 2 Jasper St. Pierre (not reading bugmail) 2014-06-25 15:06:29 UTC 
There's certainly a design question about this if we add shaded windows. If we shade nautilus:

    http://build.gnome.org/continuous/buildmaster/builds/2014/03/10/5/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png

Then do we still show the pathbar? What happens if the user starts clicking buttons in the pathbar? Do we automatically unshade the window?

I don't really think shading makes a great deal of sense with the new application designs that utilize CSD.
Comment 3 Matthew Miller 2014-06-25 17:06:23 UTC 
I can be happy with a design that goes either way, but removing the buttons on shade makes most sense to me.

I humbly disagree that it doesn't make sense. As above, I think it makes _even more sense_, in fact.
Comment 4 Matthias Clasen 2015-03-06 16:01:50 UTC 
I don't think this is going to happen
Comment 5 Emmanuele Bassi (:ebassi) 2015-05-21 13:50:34 UTC 
*** Bug 749681 has been marked as a duplicate of this bug. ***
Comment 6 Stuart Axon 2015-05-21 15:16:03 UTC 
Realise this is WONTFIX, but adding details since I just reported a dupe:


+1 for removing the buttons (except for close), at least in the interim - it's better than not having this feature at all and is the same as shading a non CSD window right now.

Being able to change what is displayed in shaded mode makes sense, Winamp one of the most widely used CSD apps on Windows used this to great effect with media control buttons and track info:

Screenshot:  http://imgur.com/NRShgR2
Comment 7 Florian Müllner 2017-03-24 16:49:30 UTC 
*** Bug 780473 has been marked as a duplicate of this bug. ***
Comment 8 Bill Hayden 2017-03-24 18:10:31 UTC 
As someone who used the windows shading feature extensively, I beg you, please reopen and consider this bug!