Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.3.2
-
Linux, Mageia 4 x86_64
Qt 5.2.1 and 5.3.2
Description
The attached archive contains the code for two applications:
- TestQt is the container. It contains a simple QWidget, a layout and a QLineEdit.
- TestQt2 is meant to be embedded into the first one via QWindow::fromWinId() and QWidget::createContainerWidget(). It contains a simple QWidget, a layout, and a QTextEdit. Start it first.
Embedding works well, but there are focus issues:
- If you click into the QTextEdit, both the QLineEdit and QTextEdit have a blinking cursor (the parent application seems not to notice it has lost focus).
- Keyboard focus follows the mouse cursor: start typing in the QLineEdit, move the mouse over the QTextEdit (don't even click), see that the keyboard focus was handled to the QTextEdit. Move back to QLineEdit, it takes the focus back.
- According to the XEmbed specification, this is X's behaviour for embedded windows, but the toolkit (Qt here) should implement the XEmbed protocol in a way that prevents this unwanted behaviour (and they tell how).
- As a side note, behaviour changed slightly between Qt 5.2.1 and 5.3.2:
- in Qt 5.2.1, if you clicked inside the QTextEdit, then it would keep the focus even if the mouse hovers the QLineEdit (which is good). When QLineEdit had the focus, the "follow the mouse" behaviour would apply, though.
- in Qt 5.3.2, focus always follows the mouse cursor.
Expected behaviour: complete XEmbed protocol implementation so that keyboard focus doesn't follow the cursor and that windows actually known whether they have focus or not (double blinking cursor issue)
Thanks in advance for you attention.
Attachments
Issue Links
- relates to
-
QTBUG-32137 QX11EmbedContainer not supporting drag and drop (dnd) correctly
- Closed