| Summary: | "control-alt-delete" brings up shutdown dialog, but it can't be activated by keyboard | ||
|---|---|---|---|
| Product: | [Unmaintained] kdm | Reporter: | Christian Trippe <christiandehne> |
| Component: | general | Assignee: | kdm bugs tracker <kdm-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andrei.ilie, dev+kde, jnelson-kde, joschi.brauchle, kdebugsbmw, kdespam34fb987, marco_parillo, rdieter, wbauer1 |
| Priority: | NOR | ||
| Version: | 0.1 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/46f1055ffdcd2e068296576a7824012f42e9b9a8 | Version Fixed In: | 4.11.22 |
| Sentry Crash Report: | |||
|
Description
Christian Trippe
2011-03-20 21:03:51 UTC
Same here on Fedora 14 using KDE 4.5.5 ... Maybe related to: https://bugzilla.redhat.com/show_bug.cgi?id=654901 https://bugzilla.redhat.com/show_bug.cgi?id=631767 https://bugzilla.novell.com/show_bug.cgi?id=679964 This seems to affect more than KDM: - after logging in in KDE 4.5.5, Alt+F1 doesn't open the KickOff Menu anymore (Alt+F2 seems to still be working) - when needing privilege escalation, in most cases the root passord dialog appears beneath the open windows, so you have to raise it manually is this a QT issue ? @Andrei: the Alt-F1 is just a config option - see https://bugzilla.novell.com/show_bug.cgi?id=637583 works for me with current master (kde 4.7 pre), qt 4.7.3, x server 1.9.99.901. superficially this sounds like a duplicate of bug 234362, but it's lacking the trigger "open popup menu". but for completeness, does the behavior change if you activate the dialog via the menu (either via keyboard or with mouse)? in any case, a problem outside of kdm's control seems most likely. (In reply to comment #4) > but for completeness, does the behavior change if > you activate the dialog via the menu (either via keyboard or with mouse)? Yes, it is the same, if I activate the dialog via mouse or keyboard (using KDE 4.6.3, Qt 4.7.3, X-server 1.9.3). From comment 4 from the openSUSE bug: As a note, I can add that by setting GrabInput=Always in "/usr/share/kde4/config/kdm/kdmrc" (default is not to have it set and this using "IfNoAuth"), the authentication dialog gets focused and one can enter the password. On my system this works quite nicely, but whether this is a general usable "work-around", I cannot say. After all, then comments in "kdmrc" claims that such a setting might cause problems: # Whether to grab keyboard and mouse while the greeter is visible. Grabs # may improve security, but make on-screen keyboards, etc. unusable. How does one re-open a bug? THis is *still* an issue with 4.7.0 I can confirm comment #4 that either GrabInput=Always or GrabServer=true seems to help the issue for me. I can confirm that this is STILL a problem in 4.9.1 .... Please reopen - this bug report is valid against KDE 4.9.1 :( *** Bug 321070 has been marked as a duplicate of this bug. *** This is still an issue with version 1.4 / KDE 4.13.0. I was about reporting this (mentioned here for search engines): The kdm shutdown pupup (buttons: shutdown, restart, cancel) is not keyboard-controllable. At least it is not keyboard-controllable by the usual keys (arrow keys, tab, enter). Fine that there is a workaround, but the UI should be controllable by keyboard. At least such really basic and important functionality. So it would really be nice if someone finds a fix to this for integration into the default code and settings. If the keyboad focus for the user/pw fields is an problem, what about the shutdown menu temproraryly replacing the login field (i.e. no popup - which has a non-fitting GUI look anyway...)? Git commit 46f1055ffdcd2e068296576a7824012f42e9b9a8 by Wolfgang Bauer. Committed on 04/08/2015 at 17:51. Pushed by wbauer into branch 'KDE/4.11'. Fix input focus for KDM's dialogs when GrabInput is not active Commit d03df616 made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Related: bug 338018 REVIEW: 121755 M +2 -2 kdm/kfrontend/kfdialog.cpp http://commits.kde.org/kde-workspace/46f1055ffdcd2e068296576a7824012f42e9b9a8 |