I am using QWebView to display some flash content in this. I have been set the attribute of this window to be frameless and made it as a child window of some other process(Remote desktop Terminal session window).
I wanted to grab the ALT+F4 key press combination on this flash video. I mean to say if user clicks on the flash video(i.e. my QWebView window is in focus now), at that time if user presses ALT+F4, then I wanted to take some action on this event.
I have overridden keypressevent(QKeyEvent), but I am not getting this to be called , even though after setting the focus policy.
NOTE :- I am getting key press event only and only when user click on the QWebView window outside the flash area.
Related
I have a popup in my app which can be moved by the user to another screen. The popup is show in intervals. When the user unplug or turn off the screen and the popup is shown, actually it is not, because the screen is off. How to detect when the popup (Qt quick Window type widget) is really visible for the user?
i have an app where i have 2 widgets, one widget shows a video and the other one two buttons as transparent widget lying over the video. Means the widget with the buttons has the focus. When now somebody clicks on the video normally this should emit a signal to open a website in an external browser, but while the other widget has the focus, this signal is not emitted while the click only changes the focus to the video but is not getting the click itself.
is there a way to use the click, to change the focus and catch the click event to open my website?
Georg
I guess you can try the function: setFocusProxy()
video.setFocusProxy(button);
Maybe you can get some help.
Whats the difference between QDialog::show() and QDialog::open()?
show() will just show you the dialog without affecting the other windows in your program. open() will show() the window + prevent other windows from being accessible through setWindowModality(), i.e., it becomes a modal window.
This is useful if you want to open a file, for example, and you don't want the user to be able to do anything in the program until a file is chosen and that dialog is closed.
Quoting from Qt's manual:
A modal dialog is a dialog that blocks input to other visible windows in the same application. Dialogs that are used to request a file name from the user or that are used to set application preferences are usually modal. Dialogs can be application modal (the default) or window modal.
When an application modal dialog is opened, the user must finish interacting with the dialog and close it before they can access any other window in the application. Window modal dialogs only block access to the window associated with the dialog, allowing the user to continue to use other windows in an application.
The most common way to display a modal dialog is to call its exec() function. When the user closes the dialog, exec() will provide a useful return value. Typically, to get the dialog to close and return the appropriate value, we connect a default button, e.g. OK, to the accept() slot and a Cancel button to the reject() slot. Alternatively you can call the done() slot with Accepted or Rejected.
As it is stated in the doc, QDialog::open()
Shows the dialog as a window modal dialog, returning immediately.
whereas QDialog::show(), which is in fact QWidget::show(), will only show your dialog as a standard, non-modal widget.
I have a QDialog which i'd like to be modal, i.e. I'd like the user to be locked out of the GUI completely until I programatically hide the dialog.
Here is a small reproducible example:
QDialog *dialog = new QDialog(this, Qt::Splashscreen);
dialog->setModal(true);
dialog->setWindowModality(Qt::ApplicationModal);
dialog->exec();
This is easily closed by clicking outside of the dialog.
Pressing the esc key would also close the dialog however in my custom implementation I am catching the event and dealing with it separately.
Edits
This only seems to occur on Windows, on Linux it behaves as desired.
Pressing alt + F4also closes the dialog regardless of catching key events.
In GUI dialogs, most applications provide for keyboard control as follows:
Enter key - presses the default button. (Default is usually indicated with a bold button border.)
Esc key - presses the Cancel or close button.
Space key - presses widget that currently has keyboard focus.
Tab key - advances focus to next widget.
Question is, when keyboard focus is on a widget that is a button, should the default button be changed to be the one with focus?
I see some issues with this behavior:
The display noise of redrawing buttons to unbold the outline of original default button and rebold the button under focus as being new default.
The Space key is now somewhat redundant with Enter key.
There is no keyboard accelerator to get the normal default button now (Usually the OK button).
However, it seems the trend has been in this direction to change the default button with focus change to another button. What is the rationale for this departure from the early GUIs? It would seem to provide less functionality given there is no way to press the original default button. Did people find that the original model was too complicated for users to understand? I would think keyboard control of dialogs would be a task for advanced users who would have no trouble understanding the model and prefer to have accelerator for current button (Space) and original default button (Enter) at all times.
Note that Qt for one is supporting the change: QPushButton's autoDefault property is responsible for the behavior of changing the default button. By default its value is true. Therefore, you must take extra action to set it to false for all buttons, to prevent them from becoming the default button when focused.
This is not a "departure from the early GUIs", at least not if by "early GUIs", you mean Windows 1.0. The behavior that you describe has been this way since the beginning.
The focused button is always "pushed" when the Enter key is pressed. The default button is only triggered in the following two situations:
The default button has the focus (which it does by default), or
The focus is on a control that does not process Enter key presses (such as a static control, or a single-line textbox that does not have the ES_WANTRETURN style flag set).
The famous Win32 blogger Raymond Chen has a post explaining this behavior (focus specifically on the last two quoted paragraphs):
A dialog box maintains the concept of a "default button" (which is always a pushbutton). The default button is typically drawn with a distinctive look (a heavy outline or a different color) and indicates what action the dialog box will take when you hit Enter. Note that this is not the same as the control that has the focus.
For example, open the Run dialog from the Start menu. Observe that the OK button is the default button; it has a different look from the other buttons. But focus is on the edit control. Your typing goes to the edit control, until you hit Enter; the Enter activates the default button, which is OK.
As you tab through the dialog, observe what happens to the default button. When the dialog box moves focus to a pushbutton, that pushbutton becomes the new default button. But when the dialog box moves focus to something that isn't a pushbutton at all, the OK button resumes its position as the default button.
The dialog manager remebers which control was the default button when the dialog was initially created, and when it moves focus to something that isn't a button, it restores that original button as the default button.
The behavior that I would expect is:
If I press enter when the window just pop up, it should press the default button
If I press tab, I start navigating through the widgets. In this case there are two options:
2.1 I press enter - this event should be delivered to the focused widget. There's no need to change the default button - simply hand the event to the focused widget.
2.2 I press escape. In this case, everything should go back to the state after the window is created.
Notes:
I come from a mixed background - I don't know if I learned this in windows, linux or Mobile OSes! This is just how I expect things to work out.
I don't use the space key (didn't know it's functionality)