Bug 374701 - UI doesn't respond to keyboard input until clicked on
Summary: UI doesn't respond to keyboard input until clicked on
Status: RESOLVED FIXED
Alias: None
Product: ktouch
Classification: Applications
Component: general (other bugs)
Version First Reported In: 16.12.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Gottfried
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-07 16:14 UTC by LaserMoai
Modified: 2017-01-10 10:44 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In: 16.12.2
Sentry Crash Report:


Attachments
Breeze Dark screenshot (51.42 KB, image/png)
2017-01-07 16:14 UTC, LaserMoai
Details
KTouch with Dark Breeze Theme (51.44 KB, image/png)
2017-01-09 08:24 UTC, Sebastian Gottfried
Details

Note You need to log in before you can comment on or make changes to this bug.
Description LaserMoai 2017-01-07 16:14:15 UTC
Created attachment 103265 [details]
Breeze Dark screenshot

This makes resuming work in it after a pause a bit of a hassle. The window definitely is in focus. Amarok doesn't have this problem.

Also, is it normal that the app looks terrible with Breeze Dark theme? I'm using qt5ct.

DE: Xfce
Comment 1 Sebastian Gottfried 2017-01-09 08:24:12 UTC
Created attachment 103299 [details]
KTouch with Dark Breeze Theme
Comment 2 Sebastian Gottfried 2017-01-09 08:29:48 UTC
> This makes resuming work in it after a pause a bit of a hassle. The window
> definitely is in focus. Amarok doesn't have this problem.
Yeah, it seems training area looses the keyboard focus once you alt-tab out of the windows. I'll have to investigate.
 
> Also, is it normal that the app looks terrible with Breeze Dark theme? I'm
> using qt5ct.
Looks fine too me. IMO Breeze Dark theme is a bit to contrasty, but that's a taste issue, not a technical one. KTouch adheres to the theme as intended, if configured via Plasma's System Settings. See my screenshot. Your screenshot doesn't look like the Breeze theme at all, no matter if dark or light. E.g. the button style is totally off.

Also please report clearly distinct issues with individual tickets. Status management gets messy if one ticket tracks multiple problems. I'll will use this ticket from now on to track the focus problem.
Comment 3 Sebastian Gottfried 2017-01-10 10:44:51 UTC
Git commit d4eac6a475681cf50d96e7d3480681f475c416b6 by Sebastian Gottfried.
Committed on 10/01/2017 at 10:34.
Pushed by gottfried into branch 'Applications/16.12'.

Fix Keyboard Focus Loss Issue For Trainer

When the main window got reactivated by window manager interaction
the training area lost the keyboard focus. This makes it impossible
to resume training immediately, one has to click into the window one
more time to set the focus manually.

In fact the whole Qt Quick scene lost the focus. The scene in is
rendered in its own QWindow and embedded into the main window with
QWidget::createWindowContainer. Then we main window receives the focus
it doesn't delegate the focus automatically to the embedded QWindow.

Setting a focus policy of the container widget fixes this.

Also prevent tabbing out of the training area. This is not useful
thing to have.
FIXED-IN: 16.12.2

M  +1    -0    src/mainwindow.cpp
M  +3    -0    src/qml/TrainingWidget.qml

https://commits.kde.org/ktouch/d4eac6a475681cf50d96e7d3480681f475c416b6