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.
groundwork only - window port interface change
This changes the last parameter for add_menu() from a boolean
to an unsigned int, to allow additional itemflags in future
beyond just the "preselected" that the original boolean offered.
There shouldn't be any functionality changes with this groundwork-only
change, and if there are it is unintentional and should be reported.
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.
Reported directly to devteam, so no #H number. Conditional code in
amii_get_ext_cmd() included an unmatched '{', which would break
compilation (at least if EXTMENU was enabled) and also resulted in
the remainder of winami.c being mis-formatted (the functions there
were treated as being inside a block rather than at file level).
This is completely untested.
There's some code suppressed via '#if 0' with a comment "fix for PL2".
We haven't used the patch-level nomenclature since version 3.0!
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Pat noted that I neglected to drop the SCCS lines on the files I've been
committing, so clean up those and any others I could find where the SCCS
line date is out of date.
PORTS: Please make sure I've done the right thing for/to your code.
This patch adds a new winproc that lets the window port approve or cancel
the suspend request - this should take care of the Mac Qt lockup issue.
In addition, Unix suspend is restricted to accounts that can use the shell
if SYSCF is defined.
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
[See cvs log for doc/window.doc for more details.]
Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.
The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.
(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)
A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.
This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?
This provides the core support needed for status field highlighting.
This patch doesn't actually perform status field highlighting for any port,
but provides the core hooks for doing so.
The syntax is:
OPTIONS=hilite_status:{fieldname}/{threshold}/{below}/{above}
where {fieldname} is the name of a status field.
{threshold} is the value used as the threshold to trigger a display
change. It can also be set to "updown" to trigger
a display change whenever it rises or whenever it falls.
If you end the threshold value with %, then it signifies
that you want to trigger the display change based on the
percentage of maximum.
{below}, {above}
are the color or display attribute that you want to use when
the field value is underneath the threshold. Supported display
fields are: normal, inverse, bold, black, red, green,
brown, blue, magenta, cyan, gray, orange,
bright-green, yellow, bright-blue, bright-magenta,
bright-cyan, or white.
Valid field names are:
alignment, armor-class, carrying-capacity,
charisma, condition, constitution, dexterity,
dungeon-level, experience-level, experience,
gold, HD, hitpoints-max, hitpoints, hunger,
intelligence, power-max, power, score,
strength, time, title, wisdom
Refer to window.doc for details. Guidebook updates to come later.
Introduction of a new set of window port status display
routines. The new routines are conditional on
STATUS_VIA_WINDOWPORT
being defined in config.h. See the experimental section,
where the #define resides for the time being.
On September 11, 2003 "<Someone>" wrote:
> When we're going to have a different save file format, could
> the last messages in the message history be saved as well, so
> ^P would work the same before and after saving (possibly
> including a few less messages to make room for the startup
> messages?).
This seemed like a reasonable request. This patch:
- adds the core support required.
- adds the tty supporting routines.
<Someone> wishes to add a couple of new options to the wince port ("run fullscreen" and "do not use CE software keyboard").
The wincap field was full, so this adds a second field for
additional options.
to allow common parsing in the core, and direct access to the
results by the window port.
Notes:
o Adds a new field, wincap, to the window_procs
structure for setting bits related to the preference
features that the window port supports. This allows
run-time determination of whether a particular option
setting is applicable to the running window port. A
window-port is free to support as many, or as few,
of the available options as it wants. Ensure that
only the ones supported have their corresponding bit
set in window_proc.wincap. [see chart in
doc/window.doc for help with that.]
o The settings I stuck into wincap for each window
port are almost certainly not accurate, so each port
team should review them. You should only include
the ones that you will actually react to and make
adjustments for if the user changes that option.
Without the setting in wincap, the option won't even
show up in the 'O'ptions menu.
o preference_update() added to the window-port
interface, so that the window-port can be notified
if an option of interest (an option with its
corresponding bit set in wincap field) is
changed.
o provided a genl_preference_update() routine in
windows.c and used it for all the existing
window ports since they don't have a functional
one of their own yet.
o this messes around heavily with iflags and the options
arrays in options.c
o I hope I didn't break any port's existing code. I
tried not to. The Mac however, in particular, should
be looked at because it suffered a namespace collision
with what I was working on around fontname. It had
Mac specific font stuff in options.c. Please test
the Mac.
