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

diff --git a/win/Qt/Qt-issues.txt b/win/Qt/Qt-issues.txt
new file mode 100644 (file)
index 0000000..a4405b4
--- /dev/null
+++ b/win/Qt/Qt-issues.txt
@@ -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).
+
+-----