Bug 137404

K3bSetup is simply started as another application. So if you focus on K3b, you 
surely do not get K3bSetup since it is not a dialog in K3b but another 
application running in another process.

If I understood correctly please close this bug as invalid.

I thought that the user was talking about the K3b dialog warning about errors and asking to run k3bsetup.  But it sounds like you are right and that I have read this one wrong.

I will verify with the user and mark it as invalid if he confirms that he was talking about K3bsetup.

Sorry about that.

Here are some clarifications from Eddy:

The effect is conjugated and it happens when:
* the k3bsetup app was started via dialog box
* the dialog is still open (of course, who cares, we are dealing with k3bsetup)
* the k3bsetup is opened
* focus policy is "under mouse" and raising policy is "on click" (no timed raising)
* the mouse pointer enters the k3b window "airspace" (which is below the k3bsetup one)

NOTE: This behaviour can be seen with ANY other window placed on top of k3b when the dialog in question is still open! The only restriction is that the other window must be smaller than the one of k3b.


> So if you focus on K3b, you surely do not get K3bSetup since it is not 
> a dialog in K3b but another application running in another process.

This indicates me he ignored the focus under mouse model I am using. Also, I don't know for sure what he means by "get".

The problem is that:

1) the focus is one thing and the focused window being popped up is an entirely
   different issue
2) I expect windows to gain focus when the mouse hovers over them, but I expect
   them to be raised ONLY when I click them
3) k3b overrides the RAISING policy by linking the raise action to the "got focus"
   event which is WRONG and shouldn't be k3b's business.

I have already replied to the bug in Debian BTS. Sorry for the inconvenience.

Reply:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398743;msg=17


To reiterate, the behaviour is not strictly related to the k3bsetup window, it can be reporoduce with any other different application as long as the conditions explained in the pointed reply are satisfied.

Created attachment 18573 [details]
the way to reproduce

The red arrows indicate the direction and start point (the non-pointy end of
the arrow) of the mouse move while trying to reach the zim window, in order to
reproduce the bug.

As you can see, in this case, the "on top window" is not necessarily k3bsetup,
but that is the way I found it.

I don't see how this can have anything to do with K3b. There is not a line of code in K3b dealing with window raising.

> I don't see how this can have anything to do with K3b. There is not a line of code in K3b dealing with window raising.


In that case, who is to blame? The qt library?

But, more important, can you reproduce the bug?

SVN commit 605328 by trueg:

Use the main window as parent for the system problem dialog.
After denying a problem in K3b for the bug I fixed it now.

BUG: 137404


 M  +1 -1      k3bapplication.cpp  


--- trunk/extragear/multimedia/k3b/src/k3bapplication.cpp #605327:605328
@@ -144,7 +144,7 @@
 
     if( K3bSystemProblemDialog::readCheckSystemConfig() ) {
       emit initializationInfo( i18n("Checking System") );
-      K3bSystemProblemDialog::checkSystem();
+      K3bSystemProblemDialog::checkSystem( m_mainWindow );
     }
 
     if( processCmdLineArgs() )

Sorry that I did not believe you. :)

> Sorry that I did not believe you. :) 

No problem, I'm glad you did in the end :-)

Francois, any chance of a fixed package? Or will you be waiting for a new release?