Bug 59911 - rightclicking twice disables backgroundtransparency of context menu
Summary: rightclicking twice disables backgroundtransparency of context menu
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: kstyle (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Karol Szwed
URL:
Keywords:
: 53626 81706 84201 93141 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-06-16 23:09 UTC by Gunnar Johannesmeyer
Modified: 2009-05-02 01:34 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gunnar Johannesmeyer 2003-06-16 23:09:37 UTC
Version:           3.1.2 (using KDE KDE 3.1.2)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.2  
OS:          Linux

right-clicking the first time brings up an context menu with transparency.
right-clicking immediatly again brings up the same contextmenu, but without (or nearly without) transparency.

i dont know if this is really a bug or this is a feature...

-gunnar
Comment 1 Maksim Orlovich 2003-07-07 02:06:29 UTC
Does this happen everywhere, or only in some specific applications? 
 
Comment 2 Gunnar Johannesmeyer 2003-07-18 00:29:16 UTC
example konquorer: 
- right-clicking twice in the main window with the listet directories and files: the second 
contextmenu ist transparent 
- right-clicking twice at any other locations in the konquorer window: the second contextmenu 
is _not_ transparent 
- same effekt (no transparency) in other kde-applications and for the desktop (testet kwrite) 
 
-gunnar 
Comment 3 Gunnar Johannesmeyer 2003-08-13 14:07:16 UTC
bug still present in kde 3.1.3
Comment 4 Thiago Macieira 2003-08-13 14:33:03 UTC
That happens because the transparency is being taken of the menu that is being un-
displayed. The only way to take  the real transparency is to make the original contents be 
redisplayed, then the new menu be shown (which causes flicker). 
 
Some applications might not be redrawing the area beneath the menu, which means it'll be 
a blank area for the next menu's transparency. Thus, the non-transparency (it actually is 
transparent, but there's nothing under it). 
Comment 5 Gunnar Johannesmeyer 2003-08-13 15:09:25 UTC
ok. i ve just wondered, because the second non-transparency menu is also displayed, when 
this new kontextmenu doesnt overlap with the first one. 
Comment 6 Maksim Orlovich 2003-08-13 15:23:16 UTC
Thiago: Indeed, as Gunnar pointed out, this happens even on non-overlapped 
menus. This is /very/ weird.
Comment 7 Maksim Orlovich 2003-08-13 15:24:20 UTC
*** Bug 53626 has been marked as a duplicate of this bug. ***
Comment 8 David Renie 2004-01-02 03:45:44 UTC
This problem still exists in 3.1.4
Comment 9 Alexander Willner 2004-01-18 20:21:58 UTC
And it still exists in 3.1.5 ;)
Comment 10 Alexander Willner 2004-01-21 22:54:53 UTC
And it still exists in 3.2 RC1 ;) 
Comment 11 Maksim Orlovich 2004-02-01 17:25:26 UTC
The reason for this is that, for some reason the menu actually gets shown and hidden and shown again, so we end up taking a screenshot w/the menu still on the screen. Might not be fixable.
Comment 12 Alexander Willner 2004-02-01 18:25:04 UTC
"Might not be fixable"?!
I don't think so ;) I'm developing software too (ok, just small one) but I've just the time to help KDE with bugreports.
I really cannot believe this behaviour is not fixable.
I think there are two different problems.

First: Here in Konqueror
- Click somewhere with the RMB and then 10 cm somewhere else. It works perfectly
- Click somewhere with the RMB and then 1 cm somewhere else. Ok, you see the old menu in the background again

Second: On the desktop
- Click somewhere with the RMB and then 10 cm somewhere else. The transparency is much reduzed 
- Click somewhere with the RMB and then 1 cm somewhere else. I'm not sure wheter you can see the old menu...transparency is also much reduzed
Comment 13 Maksim Orlovich 2004-02-01 18:32:44 UTC
Well, it might be addressable somehow in the depth of Qt. Now, what you see is not the old menu position -- but the new one. It apparently does show/hide/show on the same spot, and we get the menu picture due to asynchrony. Wonder why there isn't any flicker, though.

Comment 14 Alexander Willner 2004-02-03 00:10:27 UTC
Interesting to see that I've the same behaviour with my middle mouse button on the desktop (show list of all programms on all virtual desktops).
But it works perfectly with the middle mouse button on the desktop when a program (e.g. konqueror) have the focus...
Comment 15 Maksim Orlovich 2004-05-16 23:56:01 UTC
*** Bug 81706 has been marked as a duplicate of this bug. ***
Comment 16 Maksim Orlovich 2004-06-29 16:49:26 UTC
*** Bug 84201 has been marked as a duplicate of this bug. ***
Comment 17 Maksim Orlovich 2004-11-12 05:41:05 UTC
*** Bug 93141 has been marked as a duplicate of this bug. ***
Comment 18 Lucas 2004-12-10 17:30:37 UTC
"That happens because the transparency is being taken of the menu that is being un- 
 displayed. The only way to take  the real transparency is to make the original contents be 
 redisplayed, then the new menu be shown (which causes flicker)."

This sounds like the only way to fix it, how bad is the flicker? With a fast computer would you even notice it? If not, then I don't see why it's a problem, since GUI effects are for higher end computers anyways. If I left click and right click really fast I don't notice any difference than if I just right click instead. And left clicking first shows the correct menu, so I don't see why this can't be fixed.
Comment 19 Vincent Panel 2006-10-14 12:09:20 UTC
Hmm... no news ?
Comment 20 Dario Andres 2009-05-02 01:34:35 UTC
KDE4 doesn't support fake transparency anymore. (you can get real transparency with compositing and Desktop Effects if you want)
Closing as UNMAINTAINED
Thanks