joelafrite
17th July 2013, 14:03
Hello,
I am observing a very strange phenomenom in my application. (Running on Linux, using Qt 4.6.2.)
I have a non-editable QComboBox widget with a few entries. When the drop down list is displayed, the screensaver is delayed from triggering. As soon as the drop down list is closed (e.g. clicking anywhere else), the screensaver triggers immediately (if enough time has passed while the drop down list was displayed).
In normal circumstances, this would just be a very minor (if strange) bug, but my application is used in a security-sensitive context and we actively rely on the screensaver to blank the screen and lock the session.
The bug seems independent of the window manager and the actual screensaver program (tested with Gnome + gnome-screensaver and Matchbox + xscreensaver).
Can anyone explain what's happening?
EDIT: Might be related, might not: when the drop down list is opened, the combo box seems to catch key presses that should be sent to the WM, such as Alt+Tab or Print Screen.
I am observing a very strange phenomenom in my application. (Running on Linux, using Qt 4.6.2.)
I have a non-editable QComboBox widget with a few entries. When the drop down list is displayed, the screensaver is delayed from triggering. As soon as the drop down list is closed (e.g. clicking anywhere else), the screensaver triggers immediately (if enough time has passed while the drop down list was displayed).
In normal circumstances, this would just be a very minor (if strange) bug, but my application is used in a security-sensitive context and we actively rely on the screensaver to blank the screen and lock the session.
The bug seems independent of the window manager and the actual screensaver program (tested with Gnome + gnome-screensaver and Matchbox + xscreensaver).
Can anyone explain what's happening?
EDIT: Might be related, might not: when the drop down list is opened, the combo box seems to catch key presses that should be sent to the WM, such as Alt+Tab or Print Screen.