GNOME Bugzilla – Bug 649374
Improve shadow rendering to aid usability
Last modified: 2011-10-30 18:51:06 UTC
Created attachment 187192 [details] [review] subtle shadows Attached is a patch that changes the way shadows are rendered. In particular: - Bigger contrast between focused and unfocused windows. The shadows help to easily locate focused window that takes input. - Menus are closer to the surface and have a defined outline — this is required for the changes coming to the gtk theme where menus will not have broders to work around the separator between a menu and the selected menubar item. - Improved perception of a bent attached modal dialogs - All shadows are more subtle, rather than up your face "we can do this now" bubblegum overdone.
Created attachment 187193 [details] screenshot demonstrating the intent for menus for GNOME 3.2 The focused window WM shading will need to provide more contrast for the menubar items, but other than that it is the best solution to the separation issue.
Review of attachment 187192 [details] [review]: I guess this one doesn't need more designer input ;-) "Improve shadow defaults" would be a slightly better subject IMO.
please apply, current shadows are really too much.
Review of attachment 187192 [details] [review]: ::: src/compositor/meta-shadow-factory.c @@ +126,3 @@ + { "utility", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 128 } }, + { "border", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 128 } }, + { "menu", { 2, 10, 0, 0, 255 }, { 1, 10, 0, 0, 128 } }, Are you sure this is what you think it is? This is a "torn off" or "pinned" menu - it doesnt make sense for me to have it have a reduced shadow or a top-fade. @@ +130,1 @@ + { "popup-menu", { 2, -1, 0, 1, 255 }, { 1, -1, 0, 1, 128 } }, This shouldn't have different focused and unfocused shadows. It's unpredictable whether a menu will be treated by Metacity as focused or not since it's an override-redirect menu, and it's better to use a single shadow that gives the result you want. @@ +132,1 @@ + { "dropdown-menu", { 2, 10, 0, 1, 255 }, { 1, 10, 0, 1, 128 } }, Same.
The fade on top of a regular menu is required to get rid of the shadow popping up without doing the Y shift. I would prefer to make the pinned/detached menus look a little odd on top rather than making the regular ones if we cannot special case these two.
(In reply to comment #5) > The fade on top of a regular menu is required to get rid of the shadow popping > up without doing the Y shift. I would prefer to make the pinned/detached menus > look a little odd on top rather than making the regular ones if we cannot > special case these two. Do you even have any menus that that are having the "menu" class applied? I'd be surprised.
Created attachment 187217 [details] [review] rewrote the patch to address the fact a menu is not menu class, but dropdown-menu
Review of attachment 187217 [details] [review]: ::: src/compositor/meta-shadow-factory.c @@ +123,3 @@ + { "normal", { 6, -1, 0, 3, 255 }, { 3, -1, 0, 3, 128 } }, + { "dialog", { 6, -1, 0, 3, 255 }, { 3, -1, 0, 3, 128 } }, + { "modal_dialog", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 128 } }, This would be an unattached modal dialog - like a modal dialog without a parent. It presumably should focus indication via shadow, and be like "dialog". @@ +126,3 @@ + { "utility", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 255 } }, + { "border", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 255 } }, + { "menu", { 3, -1, 0, 0, 255 }, { 3, -1, 0, 0, 255 } }, Example of one of these types of windows (a "utility" window I think), is the GIMP tool window - note that with this patch if you click on the GIMP tool window it gets focus but the shadow doesn't change. (indications of change are the title changing color and the changes t widgets within the window.) This might be OK, but just wanted to point that out the behavior to make sure that it was intentional.
Created attachment 187396 [details] [review] rewritten the patch Nope, that wasn't quite the intent. Sorry for wasting your time. I have misunderstood your previous comment. I kept border and menu shadows the same as normal. Maybe border windows should not have a shadow but I want to be on the safe side and keep it as it was this time. I made utility windows (GIMP's docks) slightly more subtle/flatter as they are usually "on top" of the parent window. Hope no screwups this time.
Review of attachment 187396 [details] [review]: ::: src/compositor/meta-shadow-factory.c @@ +124,3 @@ + { "dialog", { 6, -1, 0, 3, 255 }, { 3, -1, 0, 3, 128 } }, + { "modal_dialog", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 128 } }, + { "utility", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 1, 128 } }, This still makes modal_dialog and utility have no difference in shadow with (though a difference in shadow darkness) focused vs. unfocused. Intentional? @@ +132,1 @@ + { "dropdown-menu", { 1, 10, 0, 1, 128 }, { 1, 10, 0, 1, 128 } }, Why do popup menus and dropdown menus have different shadows thickness in addition to different top fade? Intentional?
When I had a tiny blur radius, mutter would leave trails when moving a window. Not that such a bug wouldn't be worth investigating, I just thought opacity alone is enough. popup-menu didn't have the fade before, so I just toned it down like everything else. If popup-menu and dropdown-menu are really the same thing, they weren't the same before either. My understanding was that popup-menus are the self-contained right-click menus that don't 'connect' to a menubar, thus don't need a fade. If I am wrong again and these two are really the same thing again, I will resubmit the patch.
(In reply to comment #11) > When I had a tiny blur radius, mutter would leave trails when moving a window. > Not that such a bug wouldn't be worth investigating, I just thought opacity > alone is enough. I'd like to investigate the bug, yes. So, you are saying that if a moveable window has a border radius less than 3 you get trails? (I don't have an opinion whether a tiny blur radius or reduced opacity is better, I was mostly wanting to check that it wasn't a mistake.) > popup-menu didn't have the fade before, so I just toned it down like everything > else. If popup-menu and dropdown-menu are really the same thing, they weren't > the same before either. My understanding was that popup-menus are the > self-contained right-click menus that don't 'connect' to a menubar, thus don't > need a fade. If I am wrong again and these two are really the same thing again, > I will resubmit the patch. That is correct - dropdown is attached, popup is unattached. What I was expecting was that a popup menu would look like a drop down menu at the bottom, but the shadow would extend all the way around. (No fade.) Your patch has a larger blur radius for a popup menu than a dropdown menu.
Created attachment 188997 [details] trailing "ghosts" of low blur shadows. This happens with very low blur radius: { "utility", { 1, -1, 0, 1, 255 }, { 1, -1, 0, 1, 128 } }, { "border", { 1, -1, 0, 3, 255 }, { 1, -1, 0, 3, 128 } }, { "menu", { 1, -1, 0, 3, 255 }, { 1, -1, 0, 0, 128 } }, This issue is not exposed with current values nor any of the attached patches.
Created attachment 189000 [details] [review] sync popup and dropdown shadows
Created attachment 191552 [details] [review] Fix typo when computing shadow bounds A x/y typo that was causing shadow bounds to be incorrectly computed and trails to be left in some circumstances. Behavior noted by Jakub Steiner.
Comment on attachment 191552 [details] [review] Fix typo when computing shadow bounds Attachment 191552 [details] pushed as be8df20 - Fix typo when computing shadow bounds
Review of attachment 189000 [details] [review]: ::: src/compositor/meta-shadow-factory.c @@ +123,3 @@ + { "normal", { 6, -1, 0, 3, 255 }, { 3, -1, 0, 3, 128 } }, + { "dialog", { 6, -1, 0, 3, 255 }, { 3, -1, 0, 3, 128 } }, + { "modal_dialog", { 3, -1, 0, 1, 255 }, { 3, -1, 0, 3, 128 } }, Still doesn't make sense to me to have dialog and modal dialog be different in focused shadow width: > This would be an unattached modal dialog - like a modal dialog without a > parent. It presumably should focus indication via shadow, and be like "dialog". But feel free to commit this as above (if intentional) or with a 6 rather than a 3 if not intentional. Sorry in being so slow in getting to this!
Pushed to master with 6 for modal dialogs.
*** Bug 640558 has been marked as a duplicate of this bug. ***