Bug 952 - "confirm unsaved" dialog is not in focus when it pops up
Summary: "confirm unsaved" dialog is not in focus when it pops up
Status: CONFIRMED
Alias: None
Product: PulseView
Classification: Unclassified
Component: UI (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-26 11:24 CEST by Gerhard Sittig
Modified: 2017-06-03 17:31 CEST (History)
2 users (show)



Attachments
patch for dialog keyboard focus research (3.38 KB, text/plain)
2017-05-26 11:25 CEST, Gerhard Sittig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Sittig 2017-05-26 11:24:06 CEST
Pulseview pops up a dialog when the application or a view is about to get 
closed while it contains data that has not yet been saved to disk.  While 
the motivation is clear and appreciated (avoid losing data which the user 
cannot reconstruct easily), answering the dialog is tedious when the focus 
needs to get moved there first (mouse move) while the activity was initiated 
from the keyboard (CTRL-W/Q).

A search suggests that the issue is caused by Qt and the QMessagebox 
implementation.  See e.g. the "There is another issue ... new window 
does not gain keyboard focus ..." comment in 
http://grokbase.com/p/gg/android-qt/126yygv48z/pop-window-for-qt-android-app 

I'm not aware of other users' complaints, but there certainly is an issue 
that was reported on the 'Net.  The issue reproduces reliably here on 
Linux Mint.

The attached patch prepares to address the keyboard focus issue, but does 
not yet solve it.  More research is required.  Other dialogs may suffer from 
the same issue, and could benefit from a similar workaround when one becomes 
available.
Comment 1 Gerhard Sittig 2017-05-26 11:25:17 CEST
Created attachment 307 [details]
patch for dialog keyboard focus research
Comment 2 Soeren Apel 2017-06-03 16:28:55 CEST
I think this is also WM-related as I can't reproduce the issue using xfce.
Comment 3 Uwe Hermann 2017-06-03 17:31:27 CEST
Should be fixed, yeah, but I can't reproduce here either (icewm, no desktop environment), so it's likely indeed dependent on desktop/WM stuff.