Bug 54885 - mainwindow shouldn't be hover shaded when the focus moves from it to its transient
Summary: mainwindow shouldn't be hover shaded when the focus moves from it to its tran...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 59432 79263 113264 115993 133702 144615 220230 227389 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-02-19 22:32 UTC by jon
Modified: 2010-11-27 19:21 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jon 2003-02-19 22:32:55 UTC
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.
Comment 1 Joseph Martin 2003-05-31 15:53:56 UTC
I can confirm this bug. I'm running Debian unstable, KDE 3.1.2, KWIN 3.1.2
Comment 2 James M Greenhalgh 2003-06-15 09:46:24 UTC
I can confirm this bug still exists in HEAD. 
Comment 3 Lubos Lunak 2003-07-25 16:50:53 UTC
*** Bug 59432 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Zander 2004-02-03 12:50:42 UTC
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.
Comment 5 Lubos Lunak 2004-04-08 09:40:19 UTC
*** Bug 79263 has been marked as a duplicate of this bug. ***
Comment 6 Lubos Lunak 2004-04-08 09:40:44 UTC
#79263 is the same with a popup menu.
Comment 7 Mike Perik 2004-09-09 22:20:35 UTC
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.
Comment 8 Marcel Partap 2005-01-13 10:45:50 UTC
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?
Comment 9 Thomas Zander 2005-01-13 11:02:35 UTC
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.


Comment 10 Lubos Lunak 2005-09-30 18:00:55 UTC
*** Bug 113264 has been marked as a duplicate of this bug. ***
Comment 11 Lubos Lunak 2005-11-14 16:22:30 UTC
*** Bug 115993 has been marked as a duplicate of this bug. ***
Comment 12 Marcel Partap 2005-12-05 02:31:47 UTC
problem seems to be still here in 3.5
Comment 13 Lubos Lunak 2006-09-07 14:35:11 UTC
*** Bug 133702 has been marked as a duplicate of this bug. ***
Comment 14 Christoph Burger-Scheidlin 2006-09-09 15:19:36 UTC
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.
Comment 15 Christoph Burger-Scheidlin 2006-09-09 15:23:37 UTC
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.
Comment 16 Marcel Partap 2007-04-22 17:54:57 UTC
...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 ;)
Comment 17 Elmar Stellnberger (AT/K) 2008-01-31 21:12:24 UTC
  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!
Comment 18 squan 2009-06-07 16:09:29 UTC
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.
Comment 19 Travis Evans 2009-06-07 22:27:59 UTC
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.
Comment 20 arne anka 2009-06-30 11:41:28 UTC
still valid in debian's kde4.x.
Comment 21 arne anka 2009-08-12 16:43:18 UTC
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.
Comment 22 Martin Flöser 2009-12-19 16:42:25 UTC
*** Bug 144615 has been marked as a duplicate of this bug. ***
Comment 23 Martin Flöser 2009-12-27 10:51:54 UTC
*** Bug 220230 has been marked as a duplicate of this bug. ***
Comment 24 Martin Flöser 2010-02-17 20:03:50 UTC
*** Bug 227389 has been marked as a duplicate of this bug. ***
Comment 25 Martin Flöser 2010-10-21 20:41:52 UTC
*** Bug 254898 has been marked as a duplicate of this bug. ***
Comment 26 Thomas Lübking 2010-11-27 19:21:27 UTC
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