Version: (using KDE KDE 3.1) Installed from: Debian stable Packages OS: Linux When the shade window on hover is enabled, and you move the mouse into a child window of the window that's active (and is un-shaded because you've hovered), both/all windows shade/disappear. Steps to reproduce: 1. Enable window shade hovering. Rt. click on window title bar -> Configure Window Behaviour Advanced -> Enable Hover 2. Open applicate (ex: KMail) 3. Double click on title bar, to shade. 4. Mouseover title bar, to unshade. 5. Do something that opens a child window (ie: <CTRL>+F in KMail) 6. Mouseover new child window 7. Utter explicitives that you now have to double click to unshade the window and go about your business. Hover shade is an awesome feature, but this little bug annoys me.
I can confirm this bug. I'm running Debian unstable, KDE 3.1.2, KWIN 3.1.2
I can confirm this bug still exists in HEAD.
*** Bug 59432 has been marked as a duplicate of this bug. ***
This bug is still present in KDE 3.2. The unshade code should not limit its check to the specific window; but should include all of its children.
*** Bug 79263 has been marked as a duplicate of this bug. ***
#79263 is the same with a popup menu.
This can also be demonstrated by enabling hover and double clicking on the title bar so that the window shades. Now click on the titlebar menu in the left corner of the title bar. Try to move down to the "To Desktop ->" menu item. The window shades and it's impossible to get to _any_ menu item that doesn't overlap the windows title bar. You can navigate the menu via the keyboard though.
In current CVS, when you give focus to a child window, the main window shades and the child stays visible. Is this to be considered fixed?
On Thu, Jan 13, 2005 at 09:45:53AM -0000, Marcel Partap wrote: > In current CVS, when you give focus to a child window, the main window shades and the child stays visible. Is this to be considered fixed? No, the parent should not shade since it should only share when focus moves to another application. Focus moving to a child frame means focus is still with this application, and it should not shade.
*** Bug 113264 has been marked as a duplicate of this bug. ***
*** Bug 115993 has been marked as a duplicate of this bug. ***
problem seems to be still here in 3.5
*** Bug 133702 has been marked as a duplicate of this bug. ***
I just tried to reproduce and for me the original window shades, but the new window stays open. I tried selecting print from the location menu in konqueror to show the print dialog for a webpage and writing a new note in kmail. On both occasions I see the same behavior if I move into the new dialog, the original window shades, yet the printer/note window stays open.
The focus is not properly returned to the original window after closing the child, so if I close the child window, the parent is not unshaded.
...almost filed another duplicate, this problem is still there. It's kinda like an elephant trap, it don't bother you if you're a mouse but if you are an elephant it's constant terrror-- would be great if someone fixes this before christmas-- it seems to be related to this in events.cpp: void Client::leaveNotifyEvent( XCrossingEvent* e ) [...] // TODO this still sucks if a window appears above this one - it should lose the mouse // if this window is another client, but not if it's a popup ... maybe after KDE3.1 :( // (repeat after me 'AARGHL!') if ( !lostMouse && e->detail != NotifyInferior ) { int d1, d2, d3, d4; unsigned int d5; Window w, child; if( XQueryPointer( qt_xdisplay(), frameId(), &w, &child, &d1, &d2, &d3, &d4, &d5 ) == False || child == None ) lostMouse = true; // really lost the mouse } I don't quite understand how this works and could not come up with code to fix it, fortunately there are those who can ;)
Shading/Hovering of windows will likely become more and more popular with newer versions of Xorg supporting transparency especially because most distributors are now providing appropriate Xorg updates. A shaded window with transparent title held on top of others simply can not annoy. Nevertheless the resolution of this bug will even be more crucial for the acceptance of hovering!
I always work with shade on hover and I'm quite sure that this has been fixed for a longer period, I would say from KDE-3.5 to KDE-4.2. Nevertheless this bug is back with KDE-4.3-b2. It would be nice if a regression test for this would be added to ensure that future regressions get discovered immediately.
No, it's still there in KDE 3.5.10. The parent window still shades; both it and the child window should stay open. I can reproduce Comment #7 as well. I don't know about KDE 4.x, though, since I haven't tested yet.
still valid in debian's kde4.x.
while with older versions it was somehow unpredictable, with kde4.3 it now happens always. having ff set to always shaded, always on top and hitting ctrl+s the save-dialog appears -- without focus! once i move the mouse into the dialog, ff disappears completely -- ie it does not only collapse but even is not on top anymore. a workaround is, to leave the mouse inside ff main window and selecting via alt+tab ff and with tab walk the fields/buttons of the dialog.
*** Bug 144615 has been marked as a duplicate of this bug. ***
*** Bug 220230 has been marked as a duplicate of this bug. ***
*** Bug 227389 has been marked as a duplicate of this bug. ***
*** Bug 254898 has been marked as a duplicate of this bug. ***
took us only 7 1/2 years ;-) but the below commit (4.6) should have fixed* the original bug report. if anyone has different problems with shading or doesn't like that (try 4.6 first, the patch adresses two or three issues with transient windows) behaviour or whatever, please feel free to open a new bug resp. wishlist entry. *transients are -regarded shading- treated independ from their main windows, ie. if you shade the main window, hover-unshade it, open a transient and enter that (leaving the main window) the mainwindow will be reshaded, since this is it's state, but it will not autominimize the transient or whatever and can be re-hovered. Anything beyond that (keep the main client open if the mouse moves in/directly to a transient etc.) is highly use case dependent and needs a justifying discussion n the kwin mailing list. ------------- SVN commit 1194907 by luebking: adjust/fix behaviour of Modal Dialogs reg. Minimizing, Virtual Desktop change & Shading BUG: 193611 BUG: 180195 M +16 -1 client.cpp M +4 -1 group.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1194907