View Issue Details

IDProjectCategoryView StatusLast Update
0004524DarkRadiantGUIpublic23.10.2017 00:32
ReporterMirceaKitsune Assigned To 
PrioritynormalSeveritynormalReproducibilitysometimes
Status acknowledgedResolutionopen 
Platformx64OSLinux openSUSEOS VersionRelease
Summary0004524: DarkRadiant doesn't sense keyboard inputs
DescriptionDarkRadiant does not sense any keyboard commands. I can however use the mouse and click on buttons just fine.

This seems to change if I have a menu opened, which implies it might be a focus detection issue. For instance: If I select a brush then press escape to deselect it, nothing happens... but if I select a brush, click on a toolbar entry such as "File" and leave the menu open, then press escape, the brush does get deselected.
Additional InformationI compile DarkRadiant from latest Git master of https://github.com/codereader/DarkRadiant My operating system is Linux (openSUSE Tumbleweed / KDE).
TagsNo tags attached.

Activities

MirceaKitsune

MirceaKitsune

07.05.2017 12:57

reporter   ~0008847

Last edited: 07.05.2017 12:58

View 3 revisions

An update: The issue seems to be probabilistic, but happening almost always. I just started DarkRadiant, and the keyboard worked perfectly again... then I simply closed it and started it back up, and once more it would not sense any keys without a menu being open.

greebo

greebo

03.07.2017 17:39

administrator   ~0008960

So far, I cannot reproduce this issue in an openSUSE virtual machine.
MirceaKitsune

MirceaKitsune

20.09.2017 20:54

reporter   ~0009317

I'm still getting this issue in latest Git master, making DarkRadiant unusable for the time being. I wonder what may be different for me that's causing it.

Do you also use KDE, and tried either openSUSE Tumbleweed or 42.3? Perhaps inputs work differently in a virtual machine, hence why we don't see it there?
MirceaKitsune

MirceaKitsune

20.09.2017 21:02

reporter   ~0009318

Just noticed that if I run DarkRadiant from a console, I get the following messages printed which seem to be relevant:

(darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed

(darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed
MirceaKitsune

MirceaKitsune

12.10.2017 14:10

reporter   ~0009457

Ran a new test and noticed the following behavior: If I open another window such as the Surface Inspector, then click on that window to select it (any field or its background), keyboard shortcuts (such as the arrow keys to move or esc to deselect) work perfectly. However the moment I click in any of the viewports (2D or 3D) the keys stop working again. I can even hover the mouse cursor over those viewports after clicking the floating window... I just can't close this window or click in a viewport. Could this be a focus detection issue?
MirceaKitsune

MirceaKitsune

12.10.2017 14:28

reporter   ~0009458

Found a workaround as well as the apparent cause! The problem only happens when "Settings -> Map Files -> Open last map on startup" is enabled. If I tell DarkRadiant to not automatically open the previous map on start, I no longer get the frozen keys issue.
greebo

greebo

22.10.2017 10:29

administrator   ~0009521

Still can't reproduce this, and I have the "Open last map on startup" setting active. I configured it to load a 3-4 MB map file and I can see the progress dialog before the 3D views are appearing, but keyboard shortcuts seem to work ok.

This is on openSUSE as well as Ubuntu 17.10 (virtual machines).
MirceaKitsune

MirceaKitsune

23.10.2017 00:32

reporter   ~0009523

I'm really surprised in that case. I can't think of what I might be doing differently on my machine that could be triggering this. I can only hope it's not something very specific, like a program running in the background causing conflicts. Most likely it just doesn't happen on virtual machines, especially since they use different drivers for everything.

Perhaps someone else here uses openSUSE Tumbleweed as their desktop, or has access to a machine where they can install it and test this? Note that at some point, openSUSE offered live DVD's in addition to the installer... maybe you can boot one and try it from there? Not sure what more I can think of and suggest... thankfully I at least have a workaround now, in case this bug won't be easy to crack soon.

Issue History

Date Modified Username Field Change
06.05.2017 20:30 MirceaKitsune New Issue
06.05.2017 20:34 MirceaKitsune Priority normal => high
07.05.2017 12:57 MirceaKitsune Note Added: 0008847
07.05.2017 12:58 MirceaKitsune Note Edited: 0008847 View Revisions
07.05.2017 12:58 MirceaKitsune Note Edited: 0008847 View Revisions
03.07.2017 17:39 greebo Note Added: 0008960
03.07.2017 17:39 greebo Status new => acknowledged
03.07.2017 17:39 greebo Priority high => normal
03.07.2017 17:39 greebo Severity major => normal
03.07.2017 17:39 greebo Reproducibility always => sometimes
20.09.2017 20:54 MirceaKitsune Note Added: 0009317
20.09.2017 21:02 MirceaKitsune Note Added: 0009318
12.10.2017 14:10 MirceaKitsune Note Added: 0009457
12.10.2017 14:28 MirceaKitsune Note Added: 0009458
22.10.2017 10:29 greebo Note Added: 0009521
23.10.2017 00:32 MirceaKitsune Note Added: 0009523