new file win/Qt/Qt-issues.txt

Record a bunch of Qt stuff before I forget it all.  It's probably
too late:  I'll bet I've left some things out.

Doesn't include several menu problems that I've already fixed but
not checked in yet.  (I don't have any other Qt changes pending.)
This commit is contained in:
PatR
2020-09-16 02:04:15 -07:00
parent eaf2af0b58
commit 81771ccda3

55
win/Qt/Qt-issues.txt Normal file
View File

@@ -0,0 +1,55 @@
Qt-NetHack issues
-----
Urgent: if the program crashes on OSX, a dialog box asking the user
whether to [ignore], [report], or [restart] will eventually appear
(it's slow). That should be repressed even if the report choice could
be directed at nethack.org.
Urgent: launching Qt nethack as a synchronous subprocess (ie, no
trailing '&') from a Terminal window, changing focus back to that
terminal after NetHack has started, and typing ^C sends the program
into an endless loop with repeated messages to stderr (the terminal)
complaining that the event loop is already running.
On OSX, if the program is run from nethackdir/nethack rather than from
NetHack.app/Contents/MacOS/nethack (plus having NetHack.app/Contents/
Info.plist containing pertinent information) then the menu bar at the
top of the screen won't accept mouse clicks and the application menu
entry in that menu bar will show as "nethack" (filename) rather than
"NetHack" (intended application name). The click issue can be worked
around by giving focus to some other application (which will put up
its own menu bar) and then back to nethack (thereby reloading nethack's
menu bar).
Sometimes scrolling a menu leaves the displayed text not matching what
nethack thinks is displayed, so making a selection by mouse click may
occasionally pick the wrong item. There's usually a visual clue when
this happens. As long as it's not a pick-one menu, scrolling up and
down or back and worth a few times will usually get things back in
sync, then you can click on the wrong entry to uncheck it and then on
the right entry to check that. Making a selection by typing its
letter doesn't suffer from this, but isn't always possible (ie, long
menu like 'O's where first 52 items have letters but remainder don't).
On OSX, command+Q while a menu (which has its own key event handler)
is popped up gets ignored. It should at least close the popup like
ESC and maybe also initiate quitting.
On the map, ^V is a dead key (at least on OSX; all other ASCII control
characters from ^A through ^U, ^W through ^Z, and ^[, ^\, ^], ^^, ^_
work; no attempt to have ^@ generate NUL has been made).
The save file selection widget at start of game issues a complaint to
stderr about adding a layout to a dialog which already has a layout,
similar to ones that YnDialog used to give for the count widget in
yn#aq dialogs. (That was resolved by inserting count in the middle
instead of trying to append to the end [without figuring out why Qt
was complaining--no doubt a Qt 2/3/4/5 issue], which is not a viable
solution for save file selection.) It also clobbers an existing save
file if you use a different name when starting a new game, then save.
Map column #0, which the core reserves for its own purposes and isn't
intended to be displayed, is displayed (as blank terrain).
-----