Bug 252047 - Splash screen covers KDE wallet password prompt
Summary: Splash screen covers KDE wallet password prompt
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.8.3
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 261623 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-22 15:12 UTC by programmeryh
Modified: 2012-05-09 14:44 UTC (History)
3 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 programmeryh 2010-09-22 15:12:22 UTC
Version:           2.3.1 (using KDE 4.4.4) 
OS:                Linux

Splash screen covers KDE wallet password prompt.



Reproducible: Always

Steps to Reproduce:
Start Amarok.

Actual Results:  
Splash screen covers KDE wallet password prompt.


Expected Results:  
KDE wallet password prompt appear on splash screen.

I'm using KDE with Compiz fusion.
Comment 1 mishad_work 2010-11-04 23:04:17 UTC
Same for me using the 2.4-GIT.exe Windows version on Win7 64-bit.

Even when obscured, its still possible to enter the wallet password (assuming you realise what it required).

Note that when a secondary display is in use, the KDE wallet sometimes appears on second display, with Amarok splash screen on primary display, so that the obscuring doesn't happen. Not sure whether this counts as a workaround.

Better workaround (on Windows; equivalent presumably applies on Linux): use Alt-Space to get the KDE wallet window's system menu, select Move, and move it out from behind the splash screen.

Another workaround: disable the Amarok splash screen.
Comment 2 mishad_work 2010-11-04 23:06:04 UTC
Note: The splash screen can also the "updating system configuration" message box.
Comment 3 Kevin Funk 2010-11-06 22:05:26 UTC
I wouldn't actually call this minor, for new users this could be very distracting.

Reproduced on Windows XP.
Comment 4 Kevin Funk 2011-06-05 15:38:17 UTC
*** Bug 261623 has been marked as a duplicate of this bug. ***
Comment 5 Myriam Schweingruber 2011-10-11 12:00:44 UTC
Is this report still valid with Amarok 2.4.3 or the current git version?
Comment 6 Myriam Schweingruber 2011-11-07 12:14:25 UTC
Just tested with new user, unfortunately still valid.
Comment 7 Myriam Schweingruber 2012-03-04 17:11:50 UTC
This is also valid on first start with the Amazon location selection dialogue.

Changed importance to major as it is a serious problem in the first time usability.
Comment 8 Myriam Schweingruber 2012-05-08 14:12:13 UTC
And it appears to actually be a KDE problem, not an Amarok one, as this also happens with for example Choqok.
Comment 9 Martin Flöser 2012-05-08 15:32:34 UTC
It cannot be a KDE bug as it clearly states in comment #0 that this is with Compiz Fusion. If two window managers show this behavior it's not the WM's fault :-)

Now what could be done about it? Let's consider what is said in comment #7: Amarok shows a splash screen and a window is opened up underneath. Sorry, that's the application's fault. For obvious reasons the splash screen has to go away as soon as the application is ready. If it can present a dialog the splash screen has to be closed by the application.

To quote the EWMH: "_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up. "

I cannot see how the window manager can do anything about it. It's the responsibility of the Client to know when it considers itself as started up or not.
Comment 10 Myriam Schweingruber 2012-05-09 14:07:05 UTC
*** Bug 299628 has been marked as a duplicate of this bug. ***
Comment 11 Thomas Lübking 2012-05-09 14:44:49 UTC
Copied over from bug #299628

Hiding splashs on clicks is NO STANDARD but just implemented in some very few WMs (actually kwin is more or less the only common one just tried and it does work for me with kwin) where compiz is NONE of them.
Both compiz and kwin handle stacking fine here, but however this is NOT DETERMINISTIC because the the splash and the dialog are transient for the very same window and the splash is marked keep above.

-> the entire setup really begs for this bug and it's actually the different degrees of WMs grace which prevents those issues (There's no specific splash layer defined, kwin ignores the keep above flag and points them to the normal layer - the code is very old and commented "no damn annoying splashscreens" ...)

The user is (probably) using openbox which will stick to the keep above flag of the splash screen and keep it above the non keep above dialog, does not hide the splash on click and (different from compiz but like kwin) allows at least for alt + lmb moving