When Qt's extended command selection dialog is set for all commands
or all normal mode commands, it displays the "#wait" command as
"wait (rest)". Picking by mouse is straightforward; the extra text
on the button has no effect. Picking by typing "#wa" will choose it;
there aren't any other choices matching that so the player never gets
as far as typing 'i'. This change allows the player to type "#rest"
as an alternate way to choose it. "#re" matches some other stuff
and the choice is left pending, adding 's' makes it unique but not
explicitly chosen (so still possible to back up), then adding 't'
chooses it. The core never knows the difference.
Simplify extended command selection under Qt by allowing the
autocomplete subset be one of the choices for its [filter]. That's
the same subset as X11 uses, where #q is unambiguous for #quit
instead of competing with #quaff and #quiver.
Unlike under X11, the player can use [filter] to switch to the full
command set and get access to a few commands which have no useable
key and aren't flagged to autocomplete. (Mostly obscure wizard mode
commands but #exploremode is in that situation.)
In normal and explore modes, the [filter] button just toggles between
two sets of commands (all normal mode commands vs autocomplete normal
mode commands). In wizard mode there are four choices and you might
need to click on [filter] up to three times to step through to the
target one among four sets (all commands, all normal mode commands,
autocomplete commands for both normal and wizard, full subset of just
the wizard mode commands).
For Qt, always render text windows with fixed width font instead
of switching from proportional to fixed when the text contains
any line(s) with four consecutive spaces. That was really meant
for menu lines without selector letters which want to be lined
up under or over ones with such, and wasn't a very good heuristic
for text windows.
Most of the text files for the '?' command happen to have such
lines so are already being shown with fixed-width font. data.base
entries were hit or miss; most have attribution lines indented by
four or more spaces but some don't, so display was inconsistent:
some were shown with fixed-width font and some with proportional.
Change the '|'/#perminv final positioning for X11 to be the same
as for curses: finishing with <escape> leaves the current view,
with <return> resets to unscrolled.
Actually getting ESC and RET to the right place wasn't trivial;
down the rabbit hole and out the other side. Using yn_function()
to get the #perminv keystrokes is less than ideal. (curses also
started that way but switched to raw character input for this.)
Stripping article ("a ", "an ", "the ") off inventory items to
squeeze a little more info into truncated persistent inventory
was initially case insensitve. That was removed because it isn't
needed but the comment still reflected it.
Add new '|' command, aka #perminv, which allows the player to
send menu scrolling keystrokes to the persistent inventory window.
Implemented for X11, where its usefulness is limited, and for
curses, where it is more needed and also more fully functional.
The interface can either prompt for one keystroke, act upon it,
and return to normal play, or it can loop for multiple keystrokes
until player types <return> or <escape>. X11 does the former if
the 'slow' application resource is False so that prompting uses
popups, and the latter when 'slow' is True where prompting is in
a fixed spot and doesn't end up causing the persistent inventory
window to be stacked behind the map window. curses always does
the loop-until-done approach. It also accepts up and down arrow
keys to scroll one line at a time.
Also adds two new menu scrolling commands, menu_shift_right (key
'}' by default) and menu_shift_left ('{') if wincap2 flags contain
WC2_MENU_SHIFT. Shifting allows different substrings of too-long
lines to be seen.
For X11, neither works because their handling requires a horizontal
scrollbar and for some reason that escapes me our menus don't have
one of those. If they did, shifts could work for all menus but a
shifted window would hide the selection letters. So shifting would
be most usefully done as: pan right, read more of any long lines,
immediately pan back to the left.
For curses, they only apply to the persistent inventory window.
Shift right redraws it with class headers and inventory letters
shown normally but the item descriptions omit their leftmost
portion, showing more text towards the end. Shift left reverses
that and does nothing if the beginning is already in view. Forward
and backward scrolling while shifted leave the shift in place.
Give the window-port side of *_update_inventory() an argument.
Calls in the core still omit that; invent.c's update_inventory()
is the only place that cares.
Looking up scrollbars did not work as intended. The code wanted an
ancestor widget that had both horizontal and vertical scrollbars,
but menus either have none or just vertical. The lookup code found
some top level widget and returned bad data.
When panictrace feedback occurs due to catching a signal rather
than controlled panic, the backtrace is useless when running the
curses interface unless the terminal gets reset first. Let's
just hope that the signal triggering a panictrace doesn't occur
while resetting the terminal.
In a couple of places, call menu_popdown instead of duplicating
its contents. I'm fairly sure that executing the is_active bit
that the duplications omitted is safe.
Several minor formatting bits are mixed in.
Widget widths should have type 'Dimension' rather than plain 'int'.
Perform a couple of things once during popup widget creation rather
than every time it gets popped up.
When X11_yn_function() re-uses a popup widget to issue a prompt
and get the player's response, make it resize properly. I'm not
sure why the old hack for that apparently worked for some folks
and not for me, or why this does work for me. At least it does.
Also, make the minimum popup width be 25 characters so that
really short prompts don't result in tiny popups. Since the
popup appears at whatever spot the pointer happens to be sitting,
it isn't always immediately noticeable when the player is using
the keyboard rather than the pointer.
X11_getlin() echoing its prompt and response to message window
truncates combined value to maximum allowed pline (rather than
having pline truncate it). But it was truncating the response
as if the prompt was maximum allowed length instead of its actual
length, so possibly hiding some of the user's text unnecessarily.
After player has responded to a getline prompt, echo the prompt
and the line of text response to the message window. Uses pline()
so also gets put into core's message history for dumplog.
More issues. The incorrectly rendered map after panning is one
I haven't seen before. Normally I only have a clipped map if I
force double size tiles rather and hadn't noticed this behavior
for that case, so manually resizing--and/or the scrollbars which
get added when that occurs--may be what triggers it.
X11_yn_function() issues a pline() to put the prompt and player's
response into the message window. Change it to use visctrl() to
make sure that the response character is ledgible when something
like the '&' command allows an arbitrary answer.
This patch adds a leading space and two extra trailing spaces
to the prompt when it's being issued via popup, but that hasn't
affected the issue mentioned next....
The popup prompting when the 'slow' resource is False doesn't
always resize properly. I saw both too wide and too narrow
[What do you want to throw? [abc] ]b
[ In what direction? ]
and
[Really quit? [yn] (n) ]y
[Dump core? [ynq] (q) ]n (size seemed right, but hard to tell)
[Do you want your posses] (might have shown one more letter;
resize doodad in window's bottom right
corner on OSX oscures the rightmost
column--which is ordinarily a space)
The truncated one did accept responses. If I answered 'n' then
the next question was truncated too, but for 'y' (plus ensuing
feedback) it would be sized correctly for the question after that.
To be clear: the popup width issue was present before this change
and is still present after it. The code already has a hack that's
intended to deal with this but it doesn't do the job for me.
If 'perm_invent' is preset in player's options, have X11 show the
persistent inventory window from the start instead of waiting for
an 'i' command. moveloop() prolog needed a tweak do deal with it
cleanly.
Require WC_PERM_INVENT in order to honor the perm_invent option.
X11 and curses already set that, tty and curses don't support it,
so only Windows GUI needed to be updated for it.
When persistent inventory window is up, remove it if 'perm_invent'
option gets set to False. This has a side-effect of fixing the
end-of-game prompting problem it caused.
This hack prevents the perm_invent window for X11 on OSX from
creeping every time it gets updated. It is far from perfect and
at the very least ought be handled via user settable X resources
rather than hardcoded values, but it's as much effort as I'm likely
to spend.
Add a new file containing a list of issues that ought to be fixed.
The initial entries are things I noticed while experimenting with
perm_invent; there is lots of older stuff that could/should be
there too. I'm not sure whether the first one is OSX-specific; the
others aren't.
Under curses interface, provide a way to get a little more space
for perm_invent without turning off windowborders entirely.
Possible 'windowborders' values:
0 = no borders, max screen space available for useful info
1 = full borders, two lines and two columns wasted for each window
2 = contingent borders, show if screen is big enough, else hide
New:
3 = as 1 except no borders for perm_invent window
4 = as 2 except never borders for perm_invent window
3 and 4 let the map, message, and status windows have borders while
providing two extra lines and two extra columns on each line for
persistent inventory. It's not much but better than nothing when
borders are enabled.
Prevent the "X Error (bad Atom)" situation that causes an
"X Error" panic.
The issue isn't fixed. This fails to implement the intended
functionality of having the X server remember the persistent
inventory window's location across games (until the next time
that the X server restarts). Worse, on OSX the window creeps
each time it is updated (visually it seems to be moving down by
the height of the window's title bar).
That's not as bad as having it move to the pointer's location as
it did in 3.6.1, but prior to the commit which introduced this
code that had been fixed and it stayed put during the current
game, so more work is definitely needed.
tty and X11 honor the menu_xxx options. Qt currently doesn't
support menu manipulation by keyboard. curses does support that
but was only handling the default menu keys.
../win/Qt/qt_main.cpp: In member function ‘virtual void nethack_qt_::NetHackQtMainWindow::closeEvent(QCloseEvent*)’:
../win/Qt/qt_main.cpp:1377:9: warning: variable ‘ok’ set but not used [-Wunused-but-set-variable]
1377 | int ok = 0;
| ^~
../win/Qt/qt_yndlg.cpp: In member function ‘char nethack_qt_::NetHackQtYnDialog::Exec()’:
../win/Qt/qt_yndlg.cpp:80:9: warning: variable ‘ch_per_line’ set but not used [-Wunused-but-set-variable]
80 | int ch_per_line=6;
| ^~~~~~~~~~~
Whitelist all the verified existing triggers:
makedefs.c: In function ‘name_file’
attrib.c: one compiler balks at a ? b : c for fmtstring
cmd.c: In function ‘extcmd_via_menu’
cmd.c: In function ‘wiz_levltyp_legend’
do.c: In function ‘goto_level’
do_name.c: In function ‘coord_desc’
dungeon.c: In function ‘overview_stats’
eat.c: one compiler balks at a ? b : c for fmtstring
end.c: one compiler balks at a ? b : c for fmtstring
engrave.c: In function ‘engr_stats’
hack:c one compiler balks at a ? b : c for fmtstring
hacklib.c: one compiler balks at a ? b : c for fmtstring
insight.c: one compiler balks at a ? b : c for fmtstring
invent.c: In function ‘let_to_name’
light.c: In function ‘light_stats’
mhitm.c: In function ‘missmm’
options.c: In function ‘handler_symset’
options.c: In function ‘basic_menu_colors’
options.c: In function ‘optfn_o_autopickup_exceptions’
options.c: In function ‘optfn_o_menu_colors’
options.c: In function ‘optfn_o_message_types’
options.c: In function ‘optfn_o_status_cond’
options.c: In function ‘optfn_o_status_hilites’
options.c: In function ‘doset’
options.c: In function ‘doset_add_menu’
options.c: In function ‘show_menu_controls’
options.c: In function ‘handle_add_list_remove’
pager.c: In function ‘do_supplemental_info’
pager.c: In function ‘dohelp’
region.c: In function ‘region_stats’
rumors.c: sscanf usage
sounds.c: In function ‘domonnoise’
spell.c: In function ‘dospellmenu’
timeout.c: In function ‘timer_stats’
topten.c: In function ‘outentry’, fscanf, sscanf, fprintf usage
windows.c: In function ‘genl_status_update’
zap.c: one compiler balks at a ? b : c for fmtstring
win/curses/cursstat.c: In function ‘curses_status_update’
win/tty/wintty.c: In function ‘tty_status_update’
win/win32/mswproc.c: In function ‘mswin_status_update’
Microsoft and other non-GNU compilers don't recognize gcc tricks
like /*NOTREACHED*/ to suppress individual warnings. clang recognizes most
of them because it tries to be gcc-compatible. Because of that, a lot of
potentially useful warnings have had to be completely suppressed in the
past in all source files when using the non-gcc compatible compilers.
Now that the code is C99, take advantage of a way to suppress warnings for
individual functions, a big step up from suppressing the warnings
altogether.
Unfortunately, it does require a bit of ugliness caused by the
insertion of some macros in a few spots, but I'm not aware of
a cleaner alternative that still allows warnings to be enabled
in general, while suppressing a warning for known white-listed
instances.
Prior to the warning-tiggering function, place whichever one of
the following is needed to suppress the warning being encountered:
DISABLE_WARNING_UNREACHABLE_CODE
DISABLE_WARNING_CONDEXPR_IS_CONSTANT
After the warning-triggering function, place this:
RESTORE_WARNINGS
Under the hood, the compiler-appropriate warning-disabling
mechanics involve the use of C99 _Pragma, which can be used
in macros.
For unrecognized or inappropriate compilers, or if
DISABLE_WARNING_PRAGMAS is defined, the macros expand
to nothing.
