Version: 1.9.0 (using KDE 4.6.2) OS: Linux When in full screen mode the "clickable" part of the "exit full screen mode" button does not spread across the whole button (only the left part, close to the icon of the button). Also, the "presentation" button is almost impossible to click: you have to hover the mouse over the button for some time to find a clickable part. Reproducible: Always Steps to Reproduce: Just enter fll screen mode Actual Results: I can't get out of full screen mode by clicking any part of the "Exit full screen mode" Expected Results: Any part of the button should do OS: Linux (x86_64) release 2.6.38-gentoo-r6 Compiler: x86_64-pc-linux-gnu-gcc I don't know if it matter but I have an ati graphics card and it happens with both open-source and proprietary drivers.
Cannot reproduce. Which style are you using, Oxygen?
(In reply to comment #1) > Cannot reproduce. Which style are you using, Oxygen? Yes, I'm using Oxygen... I will try in a different computer and will get back to you (maybe it's Gentoo related...though it doesn't look very likely)
(In reply to comment #1) > Cannot reproduce. Which style are you using, Oxygen? Ok, now I know the reason: it only happens here when composition is enabled. If I disable all the desktop effects :( the full screen mode works properly. That probably means this is a kwin (or something else) bug rather than a digikam one, doesn't it?
yes probably. I move this file to Oxygen team. Gilles Caulier
Manu Can you reproduce, with compositing on, and a different widget style ? to check whether its a kwin or an oxygen issue ?
(In reply to comment #5) > Manu > Can you reproduce, with compositing on, and a different widget style ? > to check whether its a kwin or an oxygen issue ? Yes, I just reproduced it with CDE. It seems to me that it's related to kwin...but maybe there is some hidden twisted option in the "Device" section of Xorg that fixes this (I'm refering to "XaaNoOffscreenPixmaps" "true" and stuff like that). I'm just saying because it shocks me that no one else reported this before :-S Anyway, I really appreciate someone taking care of this...so thank you very much!!
So re-assigning to kwin
@hugo: please remember to change the assignee when reassigning. @manu: could you please provide some more info for the people not knowing digikam so that we can understand what's happening. Personally I doubt that this is in any way related to kwin and I think it is a bug in a different part (e.g. Digikam or X). Compositing does not change window management and applications in any way. So we need to know whether the problem persists with different compositing modes (e.g. XRender) and other Compositors (e.g. Compiz) and if other applications show the same behavior.
(In reply to comment #8) > @hugo: please remember to change the assignee when reassigning. > > > @manu: could you please provide some more info for the people not knowing > digikam so that we can understand what's happening. > > Personally I doubt that this is in any way related to kwin and I think it is a > bug in a different part (e.g. Digikam or X). Compositing does not change window > management and applications in any way. So we need to know whether the problem > persists with different compositing modes (e.g. XRender) and other Compositors > (e.g. Compiz) and if other applications show the same behavior. Hi Martin, I don't know exactly what information you need (xorg configuration, kde settings...). Apart from what I already described above, I can also mention than going from window mode to full screen mode and vice versa, the screen flickers for an instant (not that it's very annoying but maybe it's a symptom of something else). When in full screen mode it happens what I already tried to describe above: if you want to press the "exit full screen" button again, it seems that the only part of the button that is clickable is the very border. More things: in this computer I'm using a nvidia graphics card with proprietary drivers (though it also happened to me in a laptop with open source ati drivers) and my xorg configuration is a basic one (no special options in the "Device" or "Screen" sections). Also, I just tried using "Xrender" instead of "Opengl" in "Type of Composition" and the problem persists. If you want me to try something else, just let me know.
I've never managed to get the toolbar visible in digikam fullscreen mode (so used the shortcut) - there's a checkbox, but the settgin seems just ignored in 1.9.0 *shrug* However, this (iff at all) sounds like a "re-redirection flicker on tooltip" issue. Call "kcmshell4 kwincompositing", select the "advanced" (3rd) tab and uncheck "suspend desktop effects for fullscreen windows" Then try again and report.
(In reply to comment #10) > I've never managed to get the toolbar visible in digikam fullscreen mode (so > used the shortcut) - there's a checkbox, but the settgin seems just ignored in > 1.9.0 *shrug* > > However, this (iff at all) sounds like a "re-redirection flicker on tooltip" > issue. > Call "kcmshell4 kwincompositing", select the "advanced" (3rd) tab and uncheck > "suspend desktop effects for fullscreen windows" > > Then try again and report. Hi Thomas, sorry for the dealy..but the day you posted that message I tried to follow the link from the e-mail, but it was broken...and after that I completely forgot :$ Anyway, that workaround is not working for me. It seems that it makes no difference wether that option is enabled or not (I just tried both and no way). Let me know if you want me to check something else. Greetings.
Nevermind, happens to myself on a regular base as well ;-) I've meanwhile hacked the digikam config file to get the toolbar in FS mode and cannot reproduce your observation (unredirectionm, compositing, OpenGL or not) -> do you keep some (autohiding?) plasma panel or maybe yakuake on top of your screen? The other thing was to determine a culprit effect (that might keep some input widget around) -> disable all effect plugins but keep compositing enabled. If the problem vanishes you'll have to bisect it by re-enabling plugins one by one to see which causes this.
(In reply to comment #12) > -> do you keep some (autohiding?) plasma panel or maybe yakuake on top of your > screen? Yes I do keep an autohiding panel on top...and also yakuake :) Actually, I have two computers (desktop and laptop) - with nvidia card (proprietary or open-source drivers): if I disable the autohiding panel (just the autohiding feature), then the issue goes away (I can't try right now if disabling desktop effects is also a workaround since I'm not at work) - with ati (open-source drivers): disabling the desktop effects is indeed a workaround (I love them, though...damn it :D ) EVEN when the autohiding panel is enabled. > The other thing was to determine a culprit effect (that might keep some input > widget around) > -> disable all effect plugins but keep compositing enabled. If the problem > vanishes you'll have to bisect it by re-enabling plugins one by one to see > which causes this. I can try this it what I wrote above is not useful (I'm guessing not much, right?)
You're either clicking the plasma "shadows" (but the panel should not be on top of a fullscreen window) or plasma grabs intercepts clicks and sends them to the wrong client This issue should be gone with 4.7 (where the panel shadows are no more part of a real window) but can you please sleep 10; xwininfo and in the 10 sleepy seconds set digikam fullscreen and then when the cursor turns into a cross click the "inactive" part of the toolbutton. Then post the output. Thanks.
PS: you won't have to try on the effects anymore. If it's related to the plasma panel, it's hardly to one of them as well.
(In reply to comment #14) > but can you please > sleep 10; xwininfo > and in the 10 sleepy seconds set digikam fullscreen and then when the cursor > turns into a cross click the "inactive" part of the toolbutton. when I do this, I don't really know if I'm clicking a part of the button that is inactive (since it is kind of random :-S and no button is highlighted under the cross) so I made two attemps clicking two parts of the button that are "usually" inactive (almost any part of the button but the edges). The second output is probably more meaningful since at least the window is recognized as belonging to digikam. xwininfo: Window id: 0x1e4af33 (has no name) Absolute upper-left X: 512 Absolute upper-left Y: 0 Relative upper-left X: 512 Relative upper-left Y: 0 Width: 342 Height: 30 Depth: 0 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOnly Colormap: 0x0 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: yes Corners: +512+0 -512+0 -512-738 +512-738 -geometry 342x30+512+0 ============================ xwininfo: Window id: 0x6200042 "digiKam" Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1366 Height: 768 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+0 -0+0 -0-0 +0-0 -geometry 1366x768+0+0
> xwininfo: Window id: 0x1e4af33 (has no name) .. > -geometry 342x30+512+0 Is your panel (including shadows) maybe 30px high and about 342px width...? ;-) You can use kruler to estimate it more precisely.
> Is your panel (including shadows) maybe 30px high and about 342px width...? ;-) > You can use kruler to estimate it more precisely. Actually, it's not exactly that: it's 314 x 52 :-S (I don't see any shadow, by the way)
Sounds close enough (14px padding for the shadows and 2px min height?), i guess the xwininfo measured size will change if you make the panel eg. wider as well. -> the window should not be on top of the stack of a fullscreen window unless it's a) override type b) risen by the client (the result would be that digikam is no more "real" fulslcreen then) You can check for this, but i'll configure me a plasma panel like yours and see what happens. -> What plasma theme do you use?
> the xwininfo measured size will change if you make the panel eg. wider as well. I tried increasing the size of the panel and: Absolute upper-left X: 480 Absolute upper-left Y: 0 Relative upper-left X: 480 Relative upper-left Y: 0 Width: 406 Height: 30 Depth: 0 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOnly Colormap: 0x0 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: yes Corners: +480+0 -480+0 -480-738 +480-738 -geometry 406x30+480+0 so, yes, it seems the measurements of xwininfo change. > -> the window should not be on top of the stack of a fullscreen window unless > it's > a) override type > b) risen by the client (the result would be that digikam is no more "real" > fulslcreen then) > > You can check for this I really don't know how to check any of that :-S if you want my help there, you will have to give some hints... > -> What plasma theme do you use? I'm using oxygen.
*** Bug 255129 has been marked as a duplicate of this bug. ***
The problem described in this bug report cannot happen with Plasma 5 any more. We changed the interaction of the auto-hiding panel and it gets hidden properly by KWin and does not take any input events any more. As the initial problem was reported against a 4.x version I set to unmaintained, though fixed would also fit ;-)