nethack-gwaa-kiwi/nethack
1
0
Fork 0
Code Pull Requests Activity

Qt text windows

Browse Source 
Text window search behaved very strangely:  at some point after
selecting [Search], entering a search string, having the string
entry popup go away, and having the search performed, but before
the result could be shown, the text window got pushed behind the
main window (map+messages+paperdoll+status).  Clicking on the
main window's minimize button hid the main window and gave access
to the text window behind it.  That was still functional even
after having been inaccessible; another search could be performed
and/or it could be dismissed.  I still don't know what causes
that or how to properly fix it, but using raise() is a workaround
to bring it to the front where it belongs.  Unfortunately you can
see it go away and come back so searching for text is distracting.

Allow <return> (when not searching) to dismiss all text windows
including RIP.  Accept ctrl+[ as ESC.

Make text window searching be case-insensitive.

Searching wouldn't find a match on the first line of text.  Now
it will.

This also includes an attempt to fix github issue #400 (typing a
pickup command while "things that are here" popup text window is
displayed seems to hang the program), but since I can't reproduce
that, I can't tell whether the fix works.  The issue description
says that pickup started executing and "things here" couldn't be
dismissed which is different from "things here" being behind the
map waiting for it to be dismissed.  The attempted fix is for text
window handling to tell Qt that it wants control of the keyboard,
so nethack shouldn't see any attempted pickup command.
This commit is contained in:
PatR
2020-11-05 15:35:30 -08:00
parent 24ec7f232c
commit e4106bb161
4 changed files with 152 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
win/Qt/Qt-issues.txt
+7
View File
@@ -52,4 +52,11 @@ intended to be displayed, is displayed (as blank terrain).
3.6 status conditions (Stone, Slime, Strngl, Deaf, Lev, Fly, Ride)
have been implemented but need icon artwork (one 40x40 tile for each).
In a menu window, typing ':' (via shift+something) works to initiate
a search without the need to click on the [Search] button. In a text
window, it does not, despite moving the menu key press interpretation
code into its own routine and calling that for both types of windows.
From the text window code, it sees the initial shift but not the ':'
that should follow.
-----