X11 had been ignoring add_menu(..., MENU_SELECTED) to specify a
pre-selected menu entry. This adds support for that.
Attempt to implement pre-selected entry for PICK_ONE menu sanely by
returning the pre-selected entry instead of toggling it off if the
user chooses it explicitly. Inner workings of menus are convoluted
so I'm not sure it's 100% correct, although testing hasn't found any
problems. (tty currently returns 0 for "nothing picked" when
explicitly picking a pre-selected entry in a PICK_ONE menu, and the
core jumps through hoops to handle it. That can't be cleaned up until
all interfaces which support pre-selected entries achieve sanity.)
Make "random" be chosen for <return> or <enter> during role selection
and highlight it to reflect that. (Role selection for X11 uses its
own code instead of nethack menus, so pre-selection isn't applicable.)
Without this, the keyboard commands don't work in the extended
command window on Linux. If the translations are removed from
menuformview, then the keyboard commands don't work on Mac.
Having the translations in both doesn't seem to hurt.
Instead of just using 'random' as the default choice if the user hits
<return> when picking role, race, gender, or alignment, flag it as
pre-selected in the menu so that it can be seen to be the default.
Someday somebody is going to have to fix up the interaction between
PICK_ONE menu and pre-selected choice....
Make the six buttons (ok, cancel, all, none, invert, search) on
menus for X11 all have the same width.
'ok' should probably be changed to 'okay' to be consistent with
X11_getlin(). (Another inconsistency: the extended commands
menu uses 'dismiss' rather than 'cancel'.)
Two cosmetic changes for the X11 version of the getlin() routine:
1) Make the text entry box big enough to hold 60 characters before
sliding the beginning input off the left edge, instead of just 13,
so that user can see much more of what is being typed;
2) Make the cancel button be a little wider, and the okay button be
the same width as the cancel button so they look a little nicer.
When entering an extended command, allow the user just type
and match a new command immediately, if no match was found,
instead of needing to wait the 2.5 seconds.
Update X11's status display to include the expanded set of status
conditions. This time the order is
Petrifying <hunger> Blind
Slimed <encumbrance> Deaf
Strangled Levitating Stunned
Food Pois Flying Confused
Term Ill Riding Hallucinating
with the application defaults file specifying red text for the first
column and black for the other two. Previously it was all one column
with seven entries. [Slimed was missing along with the six new ones
(deaf, stone, strngl, lev, fly, ride) and both types of sickness were
shown as 'FoodPois' or 'Ill' or 'FoodPois Ill' on one line.]
So now basic bot2, #if STATUS_VIA_WINDOWPORT genl_status_update, and
#if !STATUS_VIA_WINDOWPORT X11 fancy status have three different
orderings. genl_status_update has hunger and encumbrance first
because all the other status conditions are grouped together as one
bitmask item. bot2 has 'lev', 'fly', 'ride' last so that they're
the first things to be sacrificed if the string of status conditions
ends up being truncated. (genl_status_update also has those last.)
In addition to updating status conditions, I reordered the Hp, Pw, &c
section too so that it's closer to tty in organization.
Hit points Maximum HP
Power Maximum Power
Armor Class Alignment
Exp.Level Exp.Points (if 'showexp')
Gold Moves (if 'time')
Score (if 'showscore')
I didn't have SCORE_OR_BOTL set so haven't seen the last one, but
it's in the same position as it was before.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
Restore the ability to select extended commands by keystroke.
The key translation stuff had gotten attached to the wrong widget.
When using keys to highlight an entry in the extended command menu,
don't reset the key-by-key handling so quickly. (On second and
subsequent keystrokes, if you waited more than 0.5 second, the new
key started picking an extended command from scratch rather than
continuing the current one, making it pretty hard to disambiguate
commands which have the same initial letter. Now the delay
threshold is 2.5 seconds. In theory that should become a user-
preference resource but I don't think it's worth the effort.)
Display the help choice in response to '?'.
Clean up the formatting of the top two buttons (dismiss + help).
Start with a scroll bar if the menu is too big to fit on the screen.
Prior to this, on OSX, the full menu would be constructed but any
of it that was 'displayed' beneath the bottom of the screen was
inaccessible because it couldn't be dragged higher and couldn't be
resized to get a scroll bar (since the way to resize on OSX is by
dragging the bottom right corner--which was off the screen).
The problems I mentioned recently are still present: when scroll
bar is present, I can click beneath it and it moves down, but
neither dragging it up nor clicking above it will move it back up.
Fortunately the recently implemented up and down arrows both work,
even after clicking/dragging starts failing.
There was a lot of trial and error involved here. Most of it
eventually got phased out, but the mystery of 'defaultDistance'
(which is reported to be 0 but is actually 4) remains. The screen
height stuff at the end ought to be fixed up if someone can figure
out how to get the width of a horizontal scroll bar or the height
of a title bar. (I'm sure I used to know how to do the latter,
but that was 25 or so years ago, and in Fortran with Xlib rather
than Xt or Xaw....)
Several people have asked if 3.6.0 supports playing with tiles on
a public server. Because there's no way for the user's end to know
what that white @ is, this adds special console escape codes for
tile hinting.
The idea was originally a patch called TelnetTiles by Justin Hiltscher,
but this expanded version comes via NAO, where it's been in use for years.
This is basically an interim hack, which should go away when/if
we support actual client-server model.
This was a request from a blind player. It's hard to find
the left edge of the menu when it's drawn on the map, so
clear the screen and align menus to the left edge of the screen
when this option is turned off.
Originally this was called the window edge patch.
'... inconsistency in character creation menus'.
During role selection, the final 'is this ok?' menu has 'yes'
preselected so accepted <return> or <enter> to answer yes. The
pick-role, pick-race, &c menus prior to getting to that stage didn't
have a default, so using <enter> meant nothing was chosen, and choosing
nothing was treated as a request to quit. This changes that so it's a
request for 'random' instead.
'Provisional fix' because it ought to do this by making 'random' be a
pre-selected menu entry so that the default choice is visible. But
that takes more effort than I'm inclined to expend on this.
If player specified all four facets of role: role, race, gender, and
alignment, via command line or option settings, the tty interface still
asked the player to confirm whether the character's role/&c was ok?
Skip that confirmation when all four things have already been chosen.
Like the just fixed naming for discoveries list, there are several
other add_menu() calls which specify <space> instead of 0 as a useless
selector on separator lines. These others are all for role selection,
where menus don't get big enough to need next-page.
I don't know what I was thinking at the time, although it must have
seemed like a good idea for some reason....
Changes to be committed:
modified: win/win32/winhack.c
sys_early_init was never called for win32 GUI. That was causing "rnd(0) -
program in disorder" in tt_oname.
Update the unix Makefiles and the older OSX hints files to handle the
pile marker tile overlay. I didn't touch hints/macosx10.10 and .11
since I think there's still a merge for them pending.
A couple of formatting tweaks for bemain.c are included, for no
compelling reason. What are the odds that anyone will every build
that again?
Keep window bookkeeping up to date when tty interface is shuting down.
The other interfaces should do something similar when they make windows
known to the core become unavailable.
Use casts to try to suppress a couple of assignments of long to short
that Michael's compiler warns about. 'cw->maxrow' might have a value
that's too big for 'short' (when dealing with really big menus), but
'cw->maxcol' never will (unless someone comes up with a terminal or
emulator that's wider that 32K-1 characters...).
Changes to be committed:
modified: src/objects.c
modified: win/share/tilemap.c
Warnings during tile builds (and incorrect tile mappings
at run time when MAIL wasn't defined):
Creating 16x16 binary tile files (this may take some time)
warning: for tile 325 (numbered 325) of objects.txt,
found 'ETAOIN SHRDLU' while expecting 'stamped / mail'
warning: for tile 326 (numbered 326) of objects.txt,
found 'LOREM IPSUM' while expecting 'ETAOIN SHRDLU'
The recent addition of the first new extra scroll descriptions in a
very long time caused this problem to show up when MAIL was undefined.
There was a magic number in use that made an assumption that there
were only 4 such extra scroll descriptions, those being
"FOOBIE BLETCH", "TEMOV","GARVEN DEH","READ ME"
Release some dynamically allocated memory prior to exit. These were
previously left alone due to assumed complexity (at least by me...),
but dealing with them turned out to be straightforward.
|#if FREE_ALL_MEMORY
free BASE_WINDOW -- tty-specific; other windows are drawn on top of it
free ttyDisplay -- tty's basic data structure
|#endif
free nh_HI, nh_HE -- termcap values handled differently from the rest
These are the last things that 'heaputil' always reported as not freed
for the basic Unix+tty configuration. (I've observed other things not
being freed; those are post-3.4.3 bugs that need to be found and fixed.)
Plus a modest amount (really!) of reformatting.
Also got rid of 'copy_of()' since dupstr() does the same thing [except
for the 'treat Null as ""' part; when needed, that can be done in the
call: dupstr(!str ? "" : str)].
One of the steps in the pre-release checklist: make sure the version
number in the X11 icons is up to date. nh32icon and nh56icon both have
the version number (major and minor values only, not patchlevel).
Update it from 3.4 to 3.6 for both. (nh72icon doesn't have any version
info in its design, so doesn't need any update.)
The X11 'bitmap' program strips out the header comments, so I modified
the image, saved it, used 'git diff --patch' to capture the changes,
'git checkout' to revert to the existing file, and edited in the diff
bands pertaining to the changed data. No doubt this could have been
done in some easier fashion, but it was victory just to find the bitmap
utility and achieve results using a one-button mouse--worse, a clumsy
touchpad substituting for one--when it's designed for a three-button one.
