| Summary: | Splash screen covers KDE wallet password prompt | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | programmeryh |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | major | CC: | fboranek, hohyeis, kfunk |
| Priority: | NOR | ||
| Version: | 4.8.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
programmeryh
2010-09-22 15:12:22 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. Note: The splash screen can also the "updating system configuration" message box. I wouldn't actually call this minor, for new users this could be very distracting. Reproduced on Windows XP. *** Bug 261623 has been marked as a duplicate of this bug. *** Is this report still valid with Amarok 2.4.3 or the current git version? Just tested with new user, unfortunately still valid. 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. And it appears to actually be a KDE problem, not an Amarok one, as this also happens with for example Choqok. 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. *** Bug 299628 has been marked as a duplicate of this bug. *** 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 |