[See cvs log for include/rm.h or doc/window.doc for more complete description.]
Attach hero info, death reason, and date+time to a level that's being saved
as bones. Read such data back when loading a bones file, then treat it as
part of that level for the rest of the game. Dying on a loaded bones file
will chain the new hero+death+date to previous one(s) if new bones get saved.
outrip() now takes an extra argument of type time_t, and interface-specific
implementations of this routine need to be updated to handle that.
This is the code I built trying to figure out the large window size issue.
It completely compiles out if not needed (see -DWINCHAIN in hints/macos10.7)
and except for one call during setup has zero overhead if compiled in and
not used. See window.doc for more info.
Defs for UNUSED parms. I know this has been controversial, so use is isolated
to the chain code and windows.c (where it shouldn't be intrusive and saves about
50 warnings).
Hints file for 10.7, but the build process still needs to be migrated from
the branch.
Provide a mechanism for cleanly moving between tentative window system
selections during startup. Now, before a second (or later) system is selected,
the first will be notified that it is losing control. See window.doc.
Some time ago we received a patch submission which attempted to
handle the Alt key for terminals or emulators which transmit two char
sequence "ESC c" when Alt+c is pressed, but I can't find it. I don't
remember the details but recall that it had at least once significant
problem (perhaps just that it was unconditional, although it may have
been implemented in a way which interferred with using ESC to cancel).
This patch reimplements the desired fix, making the new behavior be
conditional on a boolean option: altmeta. That option already exists
for the Amiga port, where it deals with low-level keyboard handling but
essentially affects the same thing: whether Alt+key can be used as a
shortcut for various extended commands. This one affects how the core
processes commands, and is only available if ALTMETA is defined at
compile time. I've defined that for Unix and VMS; other ports don't
seem to need it. (I'm not sure whether "options" created by makedefs
ought to mention it. So far, it doesn't since this isn't something
users are expected to tweak. The setting of the non-Amiga altmeta
option doesn't get saved and restored, so won't affect saved data if
someone does toggle ALTMETA and then rebuild.)
When [non-Amiga] altmeta is set, nethack's core will give special
handling to ESC, but only during top level command processing. If ESC
is seen while reading a command, it will be consumed and then the next
character seen will have its meta bit set. This introduces a potential
problem: typing ESC as a command will result in waiting for another
character instead of reporting that that isn't a valid command. Since it
isn't a valid command, this shouldn't be a big deal, but starting a count
intended to prefix your next command and then typing ESC after deciding
to abort that count runs into the same situation: nethack will wait for
another character to complete the two character sequence expected for
"ESC c". There's not much that can be done with this, other than have
the Guidebook mention that an extra ESC is needed to cancel the pending
count, because digits followed by ESC could actually be a numeric prefix
for Alt+something rather than an attempt to abort the count.
..\src\windows.c(329) : 'boolean (__cdecl *)()' differs in parameter lists from 'boolean (__cdecl *)(void)'
Committed on the Free edition of March Hare Software CVSNT Server.
Upgrade to CVS Suite for more features and support:
http://march-hare.com/cvsnt/
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.
[Third of three message history patches.]
Add another argument to putmsghistory() so that it can tell whether
it's processing multiple messages for restore (which should be treated as
being older than any current messages) or a single message to stuff into
history (which should be treated as the most recent message even though
it hasn't been displayed in the message window).
[First of three message history patches.]
The post-3.4.3 hangup changes broke the post-3.4.3 message history
save/restore for tty (and maybe Win32, if it supports hangup handling;
other interfaces haven't implemented message history save/restore yet)
during hangup saves by preventing interface-specific getmsghistory() from
being called. Relatively benign; hangup save just behaved as if message
history was empty, so restore had no old messages to put back. Naturally
post-hangup restore is when players would be most interested in reviewing
the previous session's messages, so benign failure isn't acceptable. Fix
is to leave getmsghistory() intact when replacing windowprocs with the
I/O-free routines. [I can't trigger real hangups for testing, but can
call hangup() from within the debugger to force an approximation of one.]
If nhwindows_hangup() were to get called a second time, it would have
saved hup_exit_nhwindows() as the previous interface's shutdown routine.
Then if/when exit_nhwindows() gets called, hup_exit_nhwindows() would
have called itself with uncontrolled recursion. So guard against that by
preventing the hangup shutdown routine from ever being saved as previous
interface shutdown routine.
Also, avoid the exit_windows macro when using it as a pointer rather
than for a function call, since pre-ANSI compilers might be confused by
its expansion.
From two weeks ago:
> The last of my intended hangup overhaul. Once hangup is detected,
> replace currently loaded windowing routines with stubs that never do any
> terminal I/O. Real interface routines call their siblings directly rather
> than via the windowprocs pointers, so this shouldn't pull the rug out from
> under them, but it also can't prevent whatever they have in progress at
> the time of hangup from attempting further I/O once the handler returns.
hangup_nhwindows() shouldn't call exit_nhwindows() prior to replacing
windowprocs with no-ops. Even though the original intgerface can still
access its own routines directly, the exit_nhwindows() routine probably
releases its dynamic data structures. And those could be in active use if
the hangup occurs while an interface routine is executing.
The last of my intended hangup overhaul. Once hangup is detected,
replace currently loaded windowing routines with stubs that never do any
terminal I/O. Real interface routines call their siblings directly rather
than via the windowprocs pointers, so this shouldn't pull the rug out from
under them, but it also can't prevent whatever they have in progress at
the time of hangup from attempting further I/O once the handler returns.
[We might want to change nhwindows_hangup() into winprocs.hangup_nhwindows()
so that each interface has more control over its own fate.]
This assumes that user input of ESC and menu selection result of -1
everywhere in the core will eventually cause active function calls to
unwind their way back to moveloop() rather than to continually re-prompt.
(This assumption is not a new one, just a bit more explicit now.)
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.
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.
