[crossfire] GTK-V2 Message Control

[Kevin Bulgrien]

SVN revision 12184 presents the stable GTK-V2 Message Control system.  Output
count and time are now user controlled via spinbuttons.  The spinbuttons can
be pasted into, and allow use of PgUp/PgDn to adjust them faster.  The
previously announced message routing is unchanged.  You can now route message
types to whatever panel you want them to go.  Routing to both panels or none
is supported.

The dialog has tool-tips all over it to provide in-client help.

The save and load buttons are active now, and the client loads the save file
automatically when it starts if one exists.

The save and close buttons also now apply the displayed settings when they are
used.

By the way, this implementation varies from the original server implementation.
Messages that are not currently buffered for duplicate suppression always are
shown one time as they enter the buffer.  This helps you see each type of
message immediately before the duplicate suppression kick in.  The first
message is only shown if the message has to be re-buffered - not just because
the output count or time tripped.  Messages are only kicked out of the buffer
if new messages come in and push them out.

The system has 10 buffers to try to better suppress duplicates considering how
many different attack messages exist.  It seems to do a reasonable job.  The
server implementation only had 5 buffers.

The other difference is one I'm not totally sold on.  The buffers are only 56
characters wide.  Longer messages will never be buffered as it seems rare that
long messages would be duplicated anyway.  Every now and then this makes the
messages pop out in an odd order, so I'm not 100% sure how good the idea was,
but I left it that way for now.  I had the width originally set at 40 characters,
but then I would get some instances where I "found amazingly long trap name"
after I had already disarmed it.  56 seems to have cleared that up.

The message type names could probably use some tool tips if more information is
accumulated about what kind of information is associated with each type.  The
header file where the message types are set up is not real verbose on what all
the different types mean.

The code seems stable to me.  If several people bang on it, I think a client
release is warranted in the very near future.

With this new routing capability, it is probably worth adding at least one more
message panel to one or more of the client layouts.  You almost have to use one
as a chat panel, so I can see how having one more panel that can be used, say,
to keep around that store inventory, book content, or whatever could be very
helpful.  I also had this idea that it might be cool to have a fourth status
bar type message panel (non-scrollable) as an option.  What do you think?

If more panels are added, I plan to make sure the client layout does not have to
have all the panels.  That would make it much easier to do the small layouts.  I
hit a wall on the 640x480 because there seems to be a point where the client
window just does not behave when it gets too small.

I know.  This probably upped the geek factor on this client.  I did hold back on
adding controls to allow the user to adjust the number of buffers and their size.
Still, I think there is an audience that will appreciate the new functionality.

Enjoy.  Feedback welcome.

Kevin