View Issue Details

IDProjectCategoryView StatusLast Update
0004524DarkRadiantGUIpublic24.01.2021 16:38
ReporterMirceaKitsune Assigned Togreebo  
Status closedResolutionunable to reproduce 
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 My operating system is Linux (openSUSE Tumbleweed / KDE).
TagsNo tags attached.




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.



03.07.2017 17:39

administrator   ~0008960

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


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?


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


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?


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.


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).


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.


23.01.2021 06:12

administrator   ~0013493

Is this still an issue? If not, I'd vote for closing this entry.


24.01.2021 15:48

reporter   ~0013504

Yes, close this one please. I haven't experienced it in years, tried reproducing again just to be sure and not seeing any issue.

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
23.01.2021 06:12 greebo Note Added: 0013493
23.01.2021 06:12 greebo Status acknowledged => feedback
24.01.2021 15:48 MirceaKitsune Note Added: 0013504
24.01.2021 15:48 MirceaKitsune Status feedback => new
24.01.2021 16:38 greebo Assigned To => greebo
24.01.2021 16:38 greebo Status new => closed
24.01.2021 16:38 greebo Resolution open => unable to reproduce