Ugly, non-removable shadow around menus and dialog boxe

Bug #1407880 reported by luke
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Cairo-Dock Core
Fix Committed
Undecided
Matthieu Baerts

Bug Description

On Cairo-dock 3.4.0 under Ubuntu Vivid, I've noticed ugly shadows around the true window borders of the menu and most dialog boxes. The "calender and tasks" popup from the clock and the 3ed party calender applet do not have this problem, their bubbles look truly separate from the dock the way menus and dialogs do in gnome-shell or in Cinnamon. The rest have an ugly dark shadow at the edge of the window creating the impression of ugly, poorly done pseudo-transparency.

This shadow appears in Compiz, in Marco (compositing enabled), and in Metacity(compositing enabled). Disabling window decoration outright in Compiz removes similar shadows from all windows except the cairo-dock popups. I cannot remove this by any configuration option in cairo-dock, nor in any window manager it seems.

Shutting down compiz and running with NO window manager may have revealed the reason the calender is different: when rendered with no window manager and no compositing, all the other popup dialogs are rendered in black boxes just as the dock is without compositing. The calender, however, renders in a window that at first is black, then appears truly transparent (probably good pseudotransparency) and reveals the calender looking much as it does in a compositing window manager.

I am running cairo-dock rendered over a MATE panel for the menu and tray applets. The goal is a look and feel much like Cinnamon with the better performance of MATE. CPU use is much less and all animation much smoother, but those ugly shadows need to go.

Revision history for this message
luke (lukefromdc) wrote :
Revision history for this message
luke (lukefromdc) wrote :

One more point: Running cairo-dock with -c or -o has no effect on the shadows.

Revision history for this message
luke (lukefromdc) wrote :

Launching cairo-dock with -W (workarounds) will remove the shadow in cairo-dock is initially started with marco as the window manager, but it then cannot be made to render above the mate-panel, even after switching back to compiz. If no panel is under it, launching with -W under marco, then switching to compiz removes the shadows from the menu but they return on the right-side dock's applets except for the calender and volume control, which never have them.

Launching cairo-dock with compiz running always produces the shadows, even with the -W option. In both window managers I always get this warning (using Ubuntu's build cairo-dock_3.4.0-0ubuntu1_amd64.deb):

warning : (/build/buildd/cairo-dock-3.4.0/src/implementations/cairo-dock-egl.c:gldi_register_egl_backend:232)
  Cairo-Dock was not built with EGL support
warning : (/build/buildd/cairo-dock-3.4.0/src/implementations/cairo-dock-glx.c:_initialize_opengl_backend:129)
  couldn't find an appropriate visual, trying to get one without Stencil buffer
(it may cause some little deterioration in the rendering) ...

Revision history for this message
luke (lukefromdc) wrote :

WORKAROUND: This shadow turned out to be caused by the GTK3 theme.

Any GTK3 theme setting a shadow for

.window-frame

will cause whatever shadow the theme specifies to appear on most cairo-dock dialog box bubbles and on the application-menu bubble. For some reason it was possible when starting under metacity with -W to remove support for this shadow, even though the GTK theme was the cause of the problem.

The theme css files can be edited to remove all references to a shadow affecting .window-frame, and the border between the now transparent window and the desktop becomes invisible. Since I use a custom GTK3 theme I just needed to find this and modify it.

If any other GTK3 theme generates this shadow, either change themes or modify it as a workaround. I do not know if it is possible to fix this in cairo-dock itself so no GTK theme can make the invisible window boundary around a bubble show a shadow. The code I used bringing in this buq came from the "E17" GTK3 theme, which was the base from which I built my refactored "UbuntuStudio_Legacy" GTK3 theme.

E17 is at

 http://gnome-look.org/content/show.php/?content=163472

I suspect this is not the only theme setting a window shadow

Revision history for this message
luke (lukefromdc) wrote :

Fix should be in menu.css file added to ~/.config/cairo-dock/current_theme

.window-frame {
 border-radius: 7px;
 border-width: 0px;
 margin: 10px;
 box-shadow: 0 0px 0px 0px alpha(black, 0.0);
}

Removing shadows from GtkWindow ( .window.frame ) in GTK theme makes borders of
client side decorated programs invisible on white backgrounds, thus all GTK 3 themes
must use these shadows. Remove them from cairo-dock with the above file

This menu.css file should probably be included by default in cairo-dock, because this shadow
bug is NOT likely to be fixed in GTK3 by GNOME. Using this file removes the shadows from around
cairo-dock dialogs and menus while allowing them to be kept for all other GTK windows

Revision history for this message
Matthieu Baerts (matttbe) wrote :

Hello and thank you for this bug report!

Thank you for this workaround/fix, I will have a look to it ASAP ;-)

Changed in cairo-dock-core:
assignee: nobody → Matthieu Baerts (matttbe)
Revision history for this message
Matthieu Baerts (matttbe) wrote :

Hello and sorry for the lack of answer,

This bug should be fixed now (due to some changes in GTK3 I think). Do you still have this bug?

Changed in cairo-dock-core:
status: New → Incomplete
Revision history for this message
luke (lukefromdc) wrote :

If the menu.css workaround is not used, the shadows still appear, assuming shadows are used in the gtk theme at all. This is true even with gtk3.17. Getting them off dock windows requires explicit retheming.

I just reinstalled cairo-dock to test this, checked it both with and without my menu.css file. Shadows without it, none with it. This is a gtk issue where dock windows are not a shadow exception, I also run into it with my current DE, a hacked version of MATE built with gtk3 and supporting custom panel themes. There too I had to explicitly remove shadows. In that case it required gtk widget names not only for the menus being themed but also the top level windows containing them, just so shadows could be removed in the panel theme. Not as ugly when the menus directly abut the panel but still garish at round corners.

Newest cairo-dock version from Debian Unstable is damned nice, menus rendered larger than before, possibly respecting a previously ignored theme element.

Revision history for this message
Matthieu Baerts (matttbe) wrote :

Is it ok if we just add these CSS rules?

   .window-frame {
    border-width: 0px;
    box-shadow: none;
   }

Revision history for this message
luke (lukefromdc) wrote :

.window-frame {
    box-shadow: none;
   }

Should be enough, I switched to using exactly that to solve the same problem with my hacked mate menus and gtk recognizes it just fine. The border-width has nothing to to with this, it is entirely the shadows. I didn't keep cairo-dock installed after today's tests but I see no reason this should not work the same for cairo-dock as it does for any other window. The key is to use it in the cairo-dock theme (or in my case panel theme), not the global gtk3 theme. This way the fix works no matter what gtk theme a user might select, and does not affect shadows on things like application menus.

Revision history for this message
luke (lukefromdc) wrote :

Just reinstalled again to test and using

.window-frame {
    box-shadow: none;
   }

in menu.css works just fine

Revision history for this message
Matthieu Baerts (matttbe) wrote :

Thank you for these tests and explanations!

This bug should be now fixed: https://github.com/Cairo-Dock/cairo-dock-core/commit/3784a3d28a57087b6bcbf1b4c0e9f73583bec45d

Changed in cairo-dock-core:
status: Incomplete → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.