combine boolean and compound options into a single allopt[] array for
processing in options.c.
move the definitions of the options into new include/optlist.h file which
uses a set of macros to define them appropriately.
during compile of options.c each option described in include/optlist.h:
1. automatically results in a function prototype for an optfn called
optfn_xxxx (xxxx is the option name).
2. automatically results in an opt_xxxx enum value for referencing
its index throughout options.c (xxxx is the option name).
3. is used to initialize an element of the allopt[] array at index
opt_xxxx (xxxx is the option name) based on the settings in the
NHOPTB, NHOPTC, NHOPTP macros. Those macros only live during the
compilation of include/optlist.h.
each optfn_xxxx() function can be called with a req id of: do_init, do_set,
get_val or do_handler.
req do_init is called from options_init, and if initialization or memory
allocation or other initialization for that particular option is needed,
it can be done in response to the init req.
req do_set is called from parseoptions() for each option it encounters
and the optfn_xxxx() function is expected to react and set the option
based on the string values that parseoptions() passes to it.
req get_val expects each optfn_xxxx() function to write the current
option value into the buffer it is passed.
req do_handler is called during doset() operations in response to player
selections most likely from the 'O' option-setting menu, but only if the
option is identified as having do_handler support in the allopts[]
'has_handler' boolean flag. Not every optfn_xxxx() does.
function special_handling() is eliminated. It's code has been redistributed
to individual handler functions for the option or purpose that they serve.
moved reglyph_darkroom() function from options.c to display.c
Provide a way to communicate additional behaviors and/or appearances
desired from NetHack window port menus.
This is foundation work for changes to follow at a future date.
Performance profiling showed that multiple strcmpi() calls were
occurring each and every time a character was going to the map.
This update:
- honors the WC_COLOR capability
- It allows a window-port to control individual color availability should the window-port wish to do so.
- Makes checking on the individual colors for the active window-port is a straightforward table lookup at the CLR_ offset.
iflags.use_color remains a master on/off switch for use of color, regardless of the capability
compiled into the game (default TRUE).
The has_color() routine, which is now a shared routine in src/windows.c, could likely be made
into a simple macro to eliminate the function call, but this update does not go that far.
This hits a lot of port files due to the window-port interface change, mostly cookie-cutter.
If nethack is built to use graphical tombstone but file rip.xpm is
missing from the playground, there would be a crash if the rip output
was shown. My first attempt to fix it prevented the crash but didn't
display any tombstone, just the last couple of lines of output which
follow the tombstone. This keeps that in case of some other Xpm
failure, but checks for rip.xpm via stdio and reverts to genl_outrip
for text tombstone if it can't be opened.
Restore handling for keystrokes on PICK_NONE menus so that scrolling
via keys works for them. (That handling was disabled as part of the
patch to support MENUCOLORS.)
Enable [cancel] button for all menus. (That had apparently been
grayed out for PICK_NONE menus since day 1 for X11 windowing.)
Previously the code used the ASCII Text Athena widgets for displaying
file contents. Unfortunately, the widget made it impossible to control
scrolling or pretty much anything else.
Use the menu code instead, making the file display window behave properly.
Set X resource NetHack*fancy_status: False to enable the TTY-style
status lines. Default is the fancy status.
This patch is somewhat unfinished - even though the TTY-style status
allow for status hilites, the colors don't work correctly yet.
Also changes the fancy status to use the windowport notification code.
Apparently this doesn't work, for some reason every widget reports
a different window, even when they are in the same window ...
Maybe widgets inside and outside a viewport are technically
in different windows?
Like BL_FLUSH, only send BL_RESET if the window port has
indicated it wants them via setting the appropriate WC2
bits in its window_procs structure. Update documentation.
Due to the new player selection dialog I did, it was possible
to rename your character - but this didn't rename the lock files
and tried to load a save from the wrong name.
This is a bit of a hack, but seems to work and didn't seem to
cause problems for the tty.
The dialog shows the player's name, race, role, gender, and
alignment in a single window, similar to the Qt4 dialog.
Also allows randomizing the character selection.
Use the dialog by setting OPTIONS=player_selection:dialog
The X11 interface reads file NetHack.ad (after cd'ing to the playground
directory, where 'make install' puts a copy) and feeds the contents to
X Windows for use as default resources to override the compiled in
defaults. When use of #define was introduced into NetHack.ad (back in
September, 2016) this was severely hobbled and startup spit out a lot
complaints to stderr about invalid resource values. This implements
rudimentary macro expansion for '#define name value' within the data
stream that's fed to X, getting back decent default values and
eliminating the invalid value complaints.
Umpteenth revision of the X11 extended command menu. Add a new
resource to NetHack.ad to control its initial size.
I still hope there's a better way to do this, but this is my last
shot at it.
The three line change I made previously to implement highlighting for
prompts that ask for single-character input was easy and worked well
for a tiles map, but it didn't look very good for a text map. This
handles both text map and tile map and also adds a configurable
'highlight_prompt' X resource to let the user enable or disable the
feature. The resource template file (win/X11/NetHack.ad, copied to
$HACKDIR during install) now has it enabled by default.
The highlighting--more specifically, the "lowlighting" when no prompt
is active--still looks bad if the map window has a vertical scrollbar
on left edge. I don't have any inspiration about how to fix that up.
If the user hasn't explicitly loaded application defaults (which I
haven't been doing), the X11 interface behaves differently if invoked
via the shell script than if the executable is run directly, because
the script sets up a path so that X can find $HACKDIR/NetHack.ad.
This hides the difference by reading in that file during initialization
and feeding its contents to XtAppInitialize as fallback resources.