[crossfire] Continuing client messages UI work proposed/underway

[Kevin Bulgrien]

Following up on a thread started in December, I finally applied a patch to the
GTK-V2 client to experiment with improving message routing in the client.  This
code begins to sort messages between message pane 0 (Messages) and pane 1 (so-
called Critical Messages) based on MSG_TYPE classification.  What drove the
change was a desire to put player communication and other kinds of important
messages) in a panel that was not spammed with "You miss/hit..." messages, etc.
The idea being that the player does not want to have to scroll-back and hunt
for talks/chats and messages like all your armor is melting away from that acid
and your xp drained by that Nazgul or what have you - those messages need to
stay visible for longer periods of time.

In that vein, after some play testing, I found that there was a weird split
with character says appearing in pane 1 vs. NPC and Magic Mouth replies showing
up in pane 0, so a later patch added MSG_TYPE_DIALOG to the pane 1 routing.

As a side note, it may be noted that this change seems to drive certain of the
Glade client layouts to the top of the list of preferred ones since it means
that there is a lot of value to having pane 1 visible by default.

In any event, for those who can play 2.x GTK-V2, please feel free to comment on
changes.  The change was simple, but with its advent, it becomes much more
tantalizing to continue the improvement effort.

mwedel has suggested a number of possible ideas in this regard, and I better see
the potential now.  Two of the items under consideration are to add a panel
specifically to support player communication,  and, to allow a player to select
the message routing between the various message panels via in-client configuration
settings.

(Another idea is a lot more technically challenging, that therefore will not get
first attention, considers giving the player even more fine control of the UI
layout than is possible with the glade layout files that need a client restart.)

Anyway, on to the topic of new work... and in particular, planning how to prepare
for player configured message routing, a client quirk has popped up on the radar.
Messages are only classified according to MSG_TYPEs if they originate on the
server.  The client uses a simple, color-based routing method... namely that all
client-sourced messages are placed on pane 0, and any that are color are ALSO
put on pane 1.  The routing concept starts to make this behavior look kind of
weird.  "Why do those messages show up in all panels?  They really aren't all
that important!".  Essentially, this behavior comes down to the fact that the
clients all use a draw_info() function that have no awareness of message type.
The GTK-V2 client was the first client to support processing messages by type.

The solution is very simple and I have a patch made that instantiates a new
MSG_TYPE_CLIENT.  Subtypes for client messages haven't been focused on yet, but
should be quite basic.  GTK-V2's custom messages are few, and have already been
changed (in my sandbox only) over to use MSG_TYPE_CLIENT, but this makes the
client-messages sourced in the common code start to stick out like a sore thumb.

To start converting these messages to be routable, it becomes necessary to add a
draw_ext_info() function to all clients (X11/GTK-V1/GTK-V2).  In X11 and GTK-V1,
this is a stub function that discards type and sub-type by passing the text and
color data to draw_info().  In GTK-V2, draw_ext_info() calls message_callback()
which is the entry point for type-aware message handling.  Basically this proves
to me that now all client-sourced messages are easily converted to the type-based
routing method, which seems to be the best when considering making the client-side
routing configurable.

So, if you followed all that... and have an interest (for or against) the message
routing, feel free to comment on what you think about adding a new MSG_TYPE_CLIENT
and one or more related sub-types.

Pros:  This expands upon the GTK-V2 theme support in that now all message types can
be tweaked by a theme whereas in the present SVN client, the theme has no control
over client-sourced messages.  If additional message panes are implemented, this
change assures us that client-side messages need not be sprayed over all of them -
the routing can be more intelligent.  Client messages can now follow a single code
path instead of two (code comments in the client even ask the question of whether
the draw_info() code makes sense when there is (an implied) better method).  This
seems to make is simpler to read the GTK-V2 code that relates to client messages.
There are requests for client layouts 640x480 and smaller and smart message
handling in such tiny client screens is critical to playability.  This change seems
to enhance the ability to effectively support smaller screen layouts.

Cons:  I cannot think of any, can you?

I plan to continue this effort and eventually commit the changes, but I'll be glad
to entertain additional input.  I believe enough in the end-result that the balance
is already strongly tipped in favor of the change, but figure it is only fair to
open the topic up for discussion in case there is more to consider than has crossed
my mind.

One particular area that is a bit fuzzy is whether the new MSG_TYPE_CLIENT is that
necessary.  MSG_TYPE_ADMIN might be re-used instead of adding the new type.  It
has sub-types that could be construed to be a bit relevant, although I ended up
going with the new type simply because most MSG_TYPE_ADMIN sub-types were obviously
server-oriented, and it seemed a bit cleaner not to mix server and client messages
at the type level when some sub-types would make no sense at all for client-sourced
messages.  Opinions on this point are particularly welcome.

Kevin