I can't reproduce this report. All seems to work as intended with the menus 
translucency.

-- 
Cristian Tibirna .. tibirna@sympatico.ca
PhD student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna
KDE developer .. tibirna@kde.org .. www.kde.org

On Tuesday 26 March 2002 11:16 Hendrik vom Lehn wrote:
> Package: kstyle
> Version: 3.0.0 (KDE_3_0_RELEASE)
>
> When cycling through the window-menus you can see the old menu as
> background image of the new menu.
> I think the problem is that a screenshot is made every time you open a
> menu and the old menu isn't hidden before.
>
> Hendrik vom Lehn

This bug still exists in current HEAD. See
http://homepages.uni-regensburg.de/~auv20213/kde/keramik_overlap.png
for a screenshot. I marked the right side of the ghost menu with an arrow. I 
am using keramik with program-side coloring and transparency set to 50 %.

Volker

Thank you for your bug report.
This bug/feature request has already been reported and this report will
be marked as a duplicate.

Have the same bug here with recent CVS (updated 2 days ago). I am using  
qt-copy.  
  
Greetings,  
eva  

*** Bug 49895 has been marked as a duplicate of this bug. ***

*** Bug 49736 has been marked as a duplicate of this bug. ***

It would be nice to know the bug number that this report have been declared 
dublicate of. My menus behave as reported in this report too (kde-3.1.1 SuSE-8.1 
RPMs).  
 
I think I can explain this in Qt-programmer terms: I believe the problem relies in the 
QMenuBar of the Qt library, in QMenuBar::setActiveItem() the repainted area is 
optimised to not contain more than necessary, further each of the rectangles for the 
menuitems are repainted WiTHOUT erasing the areas first. Erasing the areas would 
not help alone, only get away with the ghost-menus. Further down the 
QMenuBar::setActiveItem() there is an invoke on openActPopup(), but we have not 
yet undone the painting of the previous active item. This is normally not necessary, 
but in translucency situation we would need the widget behind to repaint before 
painting the new menu item. 
 
Further remarks, when using translucency it is further necessary to make the 
transclucent widgets aware of the graphical changes behind the widget (as if it were 
not there at all). To make my point clear, try to start a Konsole and issue a 
ping-command (to some valid ip-address), drop down a translucent menu, and 
notice now that the ping information does not update behind the translucent menu, it 
only uses a snapshot image of what's behind the menu item when it was droped 
down initially. 
 
Jarl 

*** Bug 50311 has been marked as a duplicate of this bug. ***

*** Bug 59148 has been marked as a duplicate of this bug. ***

*** Bug 53626 has been marked as a duplicate of this bug. ***

*** Bug 67096 has been marked as a duplicate of this bug. ***

*** Bug 74885 has been marked as a duplicate of this bug. ***

Just changing title... Sorry, can't do much w/o X support, but may be kdrive would be widely accessible soon

Now that there's X support, is this under consideration again?

In KDE 3.4.x:
Control center -> Appearance & Themes -> Style -> Effect tab

Select "Make translucent" for "Menu effect". In "Menu translucency type" at the bottom now select "XRender blend".

Together with kompmgr translucency and drop shadows it will make your menu's nicely transparent and live updated. You can enable kompmgr here:
Control center -> Desktop -> Window behaviour -> Translucency (checking the box will put up a nice warning, this all is experimental.)
Disable the translucency for "Inactive windows" so you can actually get some work done in multi window programs.

Be aware that this _will_ crash your X server from time to time. And you might need to restart kompmgr every hour or so because it kicks X into CPU eating mode for some reason or another. This stuff is all kind of experimental. This report is not "Closed", but it is getting close ;-)

YMMV.

--
Command to stop/start kompmgr:
dcop kwin KWinInterface stopKompmgr
dcop kwin KWinInterface startKompmgr

Wait a couple of seconds before restarting it, this improves the likelyhood that X will not die... Did I already say this is experimental? Maybe I should do now.. ;-)

> ------- Additional Comment #15 From Henk Poley 2005-03-25 14:02 -------  
> In KDE 3.4.x: 
> Control center -> Appearance & Themes -> Style -> Effect tab 
> 
> Select "Make translucent" for "Menu effect". In "Menu translucency type" at
> the bottom now select "XRender blend". 
> 
> Together with kompmgr translucency and drop shadows it will make your menu's
> nicely transparent and live updated. You can enable kompmgr here: 
> Control center -> Desktop -> Window behaviour -> Translucency (checking the
> box will put up a nice warning, this all is experimental.)

"XRender blend" is a feature has been around since KDE 3.1, I believe. It's not
related to the Composite extension, but rather just uses render to draw menu
background pixmaps faster than plain software blending (see the
TransparencyHandler class). It's still fake translucency.
 

I can confirm that even after turning on X Composite support, enabling kompmgr, and setting menu translucency to XRender blend, this does NOT work: menus still use fake transparency.  Real transparency is working in other applications.

Can confirm this bug; problem is exacerbated when using slow fade-in/out with kompmgr.

*** Bug 121325 has been marked as a duplicate of this bug. ***

i think the menu-transluceny as it is by now was introduced before alpha-blending was on a more hardware-near level such as the composite extensions and modern graphics-adapters. The same effect can be seen with the OSD-Display of Amarok or Kicker itself, when set to translucent.

I think i've recently read a comment at kde-apps.org where there is a mindmapping of features for KDE4, one of them was true alpha-blending using "real" alpha-colors together with X.

As the techniques exist nowadays and are widely implemented in X and have got a good suuport it should be a high priority, regarding KDE4 (!), to fix this and to implement such a "true alpha-blending" in whole KDE and by doing this also improving the color-dialog.

in other words: i can confirm this bug, and i think most of the commentators here who say they cannot confirm this bug do not really know what is meant here. sorry.

This is a CANTFIX for 3.x, irrelevant for 4.x (since the composite effects should be used instead)