Bug 137404 - "Sys. config. probs." window prevents access to k3bsetup (with focus under mouse)
Summary: "Sys. config. probs." window prevents access to k3bsetup (with focus under mo...
Status: RESOLVED FIXED
Alias: None
Product: k3b
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-15 17:50 UTC by Francois Marier
Modified: 2006-11-16 14:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
the way to reproduce (199.01 KB, image/png)
2006-11-15 20:44 UTC, Eddy Petrişor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francois Marier 2006-11-15 17:50:16 UTC
Version:           0.12.17 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Here is a problem reported by eddy.petrisor@gmail.com on the Debian bug tracker (http://bugs.debian.org/398743):

I am using the "focus under mouse" focus model and I have seen that when
the k3bsetup window is opened via the "System configuration problems"
window in k3b, if I go away (let's say to the task bar) with the mouse
and then want to return to the k3bsetup window, (probably) because of
the properties/signal handlers of the "System configuration problems"
window, the k3b window takes focus (expected), but also pops up covering
the k3bsetup window (unexpected and undesired).

This behaviour (poping up) is a behaviour which is defined by the window
manager/desktop environment and must not be handeled by the k3b
application since it overrides without reason the user settings.

IIRC, I haven't met this behaviour in k3b until this version, but it
could be older since I haven't used the application (that particular
option) for a while (about 3 month, I _think_).
Comment 1 Sebastian Trueg 2006-11-15 18:16:51 UTC
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.
Comment 2 Francois Marier 2006-11-15 18:39:35 UTC
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.
Comment 3 Francois Marier 2006-11-15 20:19:54 UTC
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.
Comment 4 Eddy Petrişor 2006-11-15 20:36:03 UTC
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.
Comment 5 Eddy Petrişor 2006-11-15 20:44:20 UTC
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.
Comment 6 Sebastian Trueg 2006-11-16 09:55:14 UTC
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.
Comment 7 Eddy Petrişor 2006-11-16 11:20:43 UTC
> 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?
Comment 8 Sebastian Trueg 2006-11-16 12:26:23 UTC
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() )
Comment 9 Sebastian Trueg 2006-11-16 12:27:48 UTC
Sorry that I did not believe you. :)
Comment 10 Eddy Petrişor 2006-11-16 14:50:59 UTC
> 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?