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.
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.
../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;
| ^~~~~~~~~~~
By default, enable the SELECTSAVED option for everyone instead
of just for Windows or Qt. And make Qt obey the 'selectsaved'
run-time option.
It can be disabled in config.h if necessary.
Text windows only accept a few keys (<escape>, <return>, ':', now
<space>) and if they got other keys they passed those up the call
chain, arriving at the map where they were treated as commands
and were executed while the text window was still displayed. The
cited example was ',' for pickup while the "things that are here"
popup was shown. The 'foreign' key's command might be executed
successfully but the undismissed popup could become hung.
This fixes that ('foreign' keys will be ignored). It also lets
<space> be used to dismiss text windows.
Slightly better but far from perfect: if you perform a search,
then after it runs you need to type <escape> once, or <return>
or <space> twice, or else search again and pick [done] on the
search popup and then <return> or <space> once, to dismiss a
text window via keyboard. (Prior to this, typing <escape> or
searching again and picking [done] followed by <return> were the
only ways.) Also, searching for an empty string will now be
treated as if [done] had been picked.
Fixes#400
Fix the popup versions of qt_yn_function() to handle control
characters by using the same key press event decoding routine
and menus and extended commands. Moves 'keyValue()' to
qt_key.cpp and its declaration to qt_key.h, requring several
files to start using #include "qt_key.h".
'make depend' update to follow.
I can't take credit for this and still have no idea why it is
needed, but it fixes use of ^V as a command and as input to
to the regular version of yn_function(). In particular, '&'
command reports it as ^V. Unfortunately when 'popup_dialog' is
set, no control characters seem to be accepted by the part of
NetHackQtYnDialog(Exec+KeyPressEvent) responsible for arbitrary
input.
It also causes getlin() to terminate but I can't think of any
situation where ^V would be considered to be valid input for
getlin() so won't worry about that.
I put it in as '#if MACOSX' because I don't know whether any
other Qt platforms need it.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
Change the glyphttychar[ROWNO][COLNO] array from uchar to
unsighed short. DrawWalls() has handling for values in over 2000.
This also reformats pretty much all of the NetHackQtMapViewport
portion of qt_map.cpp.
The Qt routine NetHackQtMapViewport::Clear() was broken, but
fixing it hasn't changed the glyph display issue. None of the
other changes here would be expected to affect that but they
are in/among the sections of code under investigation.
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
Binding 'repeat' (DOAGAIN, or redo) to a different key than ^A
didn't work as intended because the code that used it was
checking for DOAGAIN (a key value from config.h) instead of
g.Cmd.spkeys[NHKF_DOAGAIN] (the key currently bound to repeat).
Contrary to the github issue, re-bound prefix keys worked ok for
me if followed by a direction. However, they behaved strangely
if followed by anything else. If the keystroke was stolen from
some other command and that command hadn't been bound to another
key, following the prefix with a non-direction could end up
executing the command that used to own the key. For example,
BIND=d:nopickup
to use 'd' to move without auto-pickup would work if you used
d<direction> but if you used d<something-else> if would execute
the drop command.
The NHKF_REQMENU prefix could be bound to some key other than
'm' but it only worked as intended if the new key was a movement
prefix.
This also makes DOAGAIN be unconditional. If it is deleted or
commented out in config.h, the default binding will be '\000' so
unusable (freeing up ^A for something), but still be available
to be bound to some key (perhaps even ^A).
This also includes an unrelated change to mdlib.c. The comments
added to config.h will force a full rebuild. Changing mdlib.c
now rather than separately will avoid forcing that twice.
Fixes#426
Turns out it was nearly as simple as I originally thought.
I just missed one significant detail the first time around.
This leaves DYNAMIC_STATUSLINES as conditionl but now enables
it by default. Using 'O' to change 'statuslines' from 2 to 3
or vice versa now works for Qt as well as for curses and tty.
Fix the strangeness where typing ':' in a menu window initiated
the menu search operation but typing ':' in a text window saw
the shift key be pressed but not the ';' that went with it, even
though they both called the same key decoding routine. That made
typing ':' to initiate text search be impossible. Menu windows
did more input focus manipulation in their constructor. Mimicking
that in text windows fixes the problem with keys not being seen by
the text window's keystroke handler.
Override the 'implicit_uncursed' option when formatting an item
of equipment for its paper doll tool tip. Each tile is outlined
in yellow if known to be uncursed; force "uncursed" in the tool
tip text for the same situation.
Also add or revise some comments.
Change "_Quit-without-saving" in the Game dropdown menu to be
"\177Quit-without-saving". That makes the prefix used on OSX to
prevent matching "^[&]?[Qq][Uu][Ii][Tt].*" be invisible.
Also change the order of the choices for the command+Q and
application dropdown menu entry "quit nethack" so that "cancel
and return to game" is the default for arbitrary response to the
confirmation prompt. <return> and <space> select "quit without
saving". Note that the nethack dropdown menu is OSX-specific
(a Qt feature to emulate other OSX applications) and its
nethack->Quit action is separate-from/in-addition-to Game->Quit
menu action mentioned above (which runs nethack's #quit command).
Prevent Qt from inserting an extra entry in the Help dropdown
menu displayed in the menu bar across the top of the screen
when nethack has focus. "Search [______]" lets the user enter
a string to search for but doesn't give nethack any control
over that so we can't have it.
I haven't found a sane way to get rid of it. The insane way
of not naming any menu "Help" works. This uses "\177Help" so
that it still looks like "Help" but won't match that string.
About 5 weeks ago, commit e4106bb161
changed Qt's searching in text windows to be able to find a match
on the very first line. It assumed that the first line would be
the current line except when repeating the same search after a
match. But after a failed search the current line index is -1 and
starting a new search would crash trying to look that line up.
Change qt_get_ext_cmd() to handle calling the extended command
selection menu again after player clicks on Filter/Layout/Reset
instead of relying on the core to do that. (In order to change
the menu, instead of attempting to reconfigure that on the fly
it returns to caller and then puts up a new menu with different
settings when called back. Initial checkin relied on the core
for the call back; this maintains full control for that within
the Qt interface code.)
For Qt's pick-an-exetended-command dialog, allow a player to
toggle the grid layout from column-oriented to row-oriented
and vice versa and when in wizard mode to cycle the set of
shown (and typable) commands from 'all' to 'normal mode-only'
to 'wizard mode-only' back to 'all'. The most recent values
are saved by Qt along with tile size, font size, and some other
stuff. The extended command dialog has a Reset button to force
them (the two extended command values) back to their defaults.
The dialog layout has a slight change to conserve screen space
as well as three additional control buttons:
Was Now
| [ Cancel ] | [Cancel] [Filter][Layout][Reset ]
|# |# Grid Title
| Grid title | [cmd 1] [cmd R+1] [cmd 2*R+1] ...
| [cmd 1] [cmd R+1] [cmd 2*R+1] ... | [cmd 2] [cmd R+2]
| [cmd 2] [cmd R+2] |...
|... | [cmd R] [cmd 2*R]
| [cmd R] [cmd 2*R]
'#' is the prompt where typed text gets echoed and 'R' is the
number of rows in the grid and varies by the set of commands
from the current filter. Grid dimensions have been adjusted:
'all' is 13x9, 'normal' is 13x7, and 'wizard' is 7x4 or 4x7
depending on layout orientation.
The wizard mode-only filter setting probably isn't very useful
because you can only type--or click on--commands which are
visible. So when set to wizard mode-only, you can't #quit for
instance. (Via extended command; there are still menu choices
for that particular action. And it's trivial to change filter.)
Qt on OSX is inserting "Search [_____]" as the first entry in
the Help dropdown menu (the one in the toolbar at the top of the
desttop). While trying--and failing--to figure out how to get
rid of that, I cleaned up a little bit of the old menu hackery
(that tries to workaround the fact that Qt on OSX insists that
some menu actions--based solely on their names--should go into
the appication menu rather than whichever menu the program is
trying to insert them into). The only observeable difference
is that 'About NetHack-Qt' will be at the top (actually second
because of that Search one) of the Help dropdown, where it is on
non-OSX builds, rather than last.
This tries to make the program name consistent too, changing
several instances of "Qt NetHack" to be "NetHack-Qt". The latter
is the name being set up as ApplicationName in qt_bind.cpp that
gets used when Qt stashes the Qt-specific settings wherever it
stashes them.
It also makes another tweak in formatting of 'About NetHack-Qt',
inserting one explicit line break to avoid some poor looking line
wrapping. I still haven't figured out how to control that popup's
size.
The #version command is a leading substring of the #versionshort
command and for Qt, it couldn't be executed by typing, only via
mouse click or one of the Qt-specific menus. #version<return>
or #version<space> now works for that.
The #versionshort command ought to be renamed to something else.
When responding to '#', the Qt interface puts up a grid of buttons
labelled with the names of commands. Then if the user types
instead of clicking on a button, buttons which can no longer match
are removed rather than grayed out. The remaining ones keep their
same relative positions. Once whole rows or whole columns were
gone, it looked awful. With rows gone, the size of the grid
shrank but the popup stayed the same size, so the one-line prompt
area expanded to fill up the vacated vertical space. That caused
the prompt and partial response to move as they stayed centered in
their growing area. With columns gone, the width of the buttons
in remaining columns expanded and they spread out to take up
vacated horizontal space. Once the candidate commands were all
in one column, the buttons spanned the width of the grid. (That's
mostly my fault due to changing the grid from being row-oriented
[a b c]
[d e ]
to column oriented
[a d]
[b e]
[c ]
which resulted in columns going away a lot faster and possibly down
to one when the old layout always had at least two. But old layout
could drop to one row; the current layout always has at least two.)
Also, accept ^[ as ESC. Typing ESC when partial input is present
kills that input but keeps prompting. Typing ESC when no input
is present (none entered yet or a second of two consecutive ESCs)
cancels the operation.
Allow ^U to kill partial input. If used when no input is present,
nothing happens, similar to backspace. Unlike tty and curses, it's
hardcoded here. That shouldn't be a problem because ESC can be
used as a substitute if ^U isn't what the player normally uses.
Multiple stints of flailing about without a clue finally led to
a breakthrough. When writing a new message to the multi-line
message window, force the view back to showing the starts of
lines if player has scrolled it to the side and left it that way.
Put another way, if it has been scrolled to the right, scroll it
as far as possible back to the left.
Qt's status highlighting was treating any change to hunger or
to encumbrance as "worse" (shown in red). That's wrong if you
go from weak to just hungry or from stressed to encumbered.
Comparing satiated with other hunger states is tricky. I've
ranked it between hungry and weak but that's fairly arbitrary.
Also, change the highlighting when Lev, Fly, and Ride are new
conditions from red to blue.
During status update at the time the 'showexp' option gets toggled
on or off, prevent comparing Xp (level) against Exp (points) when
deciding whether the value has gone up or down. Xp/Exp (when
toggling on) or just Xp (when toggling off) will be highligthed in
blue (changed, neither better nor worse) rather than green or red.
In "Qt settings" (or "Preferences" for OSX), the current font size
would show "Medium" if that was the current setting. So far, so
good. However, if you clicked on the up/down arrows to get the
dropdown menu, it was truncated to "Mediu" there regardless of
current setting. Force the menu to be wide enough to show "Medium".
If 'showscore' has been On and gets toggled Off while Score is
highlighted, remove that highlight immediately instead of letting
it stick around a few turns until it times out.
For the tool tips shown if you let the mouse pointer hover over
any of the cells in the paperdoll (inventory subset showing
worn and wielded items), remove the trailing period and add a
leading space and a trailing space. Improves readability.
When Qt highlights a field that has gotten better, use the same
shade of green as is used for the green range of hitpoint bar.
The old value was too dull, like olive green seen in shadow.
Highlight changes to dungeon location or alignment in blue instead
of green or red since neither the old value nor the new can be
classified as better than the other. Likewise when changing
between regular Hp and Xp (or Xp/Exp) to or from you-as-mon Hp and
HD when polymorph or rehumanization takes place.
When toggling Score On, start out highlighted in blue instead of
green. When toggling it Off, don't highlight the blank space
where it had been in red. At the moment there's a quirk here;
if it is highlighted in green (from recent change) or blue (from
having just been toggled on) at the time it gets toggled off, the
space stays green or blue until that highlight times out. (It has
occurred to me that the bogus red highlight might have been added
to deliberately overwrite stale green highlights. If so, a better
fix should be achievable.)
For the title (plname and rank or plname and monster-species),
capitalize the player name since core's botl() and at least some
other interfaces do that.
TODO: toggling Exp needs work. The field used for deciding
up/down changes gets swapped and the update in progress compares
apples and oranges. [This wasn't an issue in the original Qt
implementation where Xp and Exp were two separate fields.]
Fix the minor problem of the status lines moving up or down a
tiny amount when using the condensed (statuslines:2) layout and
the condition line changed from empty to non-empty or vice versa.
The widget used as filler when no conditions are shown needed to
have non-empty label text (single space suffices) and also has
to have its font set to the same value as the rest of status.
(I previously tried a label of " " and also "_" but had left the
font with its default value.)
The adjustments to the prefix string when the value of Xp/Exp
("Level" -> "Lvl" -> "L") or Score ("Score" -> "Scr" -> "S") was
too wide needed some fixing up. If shrinkage was needed, it was
setting the value multiple times and any extra times confused
field highlighting because it seemed to be assigning same value
rather than a changed one.
For condensed layout that moves Alignment to the Characteristics
line, add a vertical separator line between Charisma and Alignment.
