[crossfire] gtk2 client & skins/styles

Mark Wedel mwedel at sonic.net
Sun Nov 12 23:53:04 CST 2006


  I've been doing some work with the gtk2 client related to loading a rc file 
that controls the color and style of widgets.

  A work in progress screenshot can be found at:
http://wiki.metalforge.net/doku.php?id=user:mwedel

  The idea of this is first to make the game appear more game like, but second, 
I'd for see several different rc files users could select from for different styles.

  As part of these changes, I've also improved the code to just behave better 
with themes in general - in several places, the code was explicitly setting font 
or background colors, when the default would work just fine (background of the 
inventory lists, and the font color used in drawing text in the info windows).

  One thing I really like about what I've done so far is that it moves some of 
the compiled in constants into the rc file.  For example, the color/style of 
cursed/magic is compiled into the client.  With the rc file, if you don't like 
it, you just go in and change the style file for a combination you like.

  The rc file also allows more options to be set than can be reasonably done 
otherwise.  For the inventory look, instead of just the single background color 
control, there is background, foreground, as well as what font to use.  In my 
testing theme, I used italics for locked objects, bold for applied objects.

  The only problem here I don't have a good solution to is when an object has 
multiple attributes (cursed & applied, magic and locked, etc).  We could like at 
the different attributes and see what is set (cursed is red, applied is bold, 
since this should be red font in bold).  But what do you do if I have applied as 
green, cursed as red, and both using the same font.  Averaging the colors to 
yellow is probably the wrong answer (user may very well have something else set 
as yellow).

  What I've done now is just set up a simple priority scheme:
unpaid > cursed > magical > applied > locked

  The other thing that could be done is to define combination styles within the 
rc file itself - an 'applied_cursed' style, a 'locked_applied' style, etc. But 
that adds a fair number of styles.

  There are some other issues:
----
progressbar (hp/grace/food/sp/exp) - these use the gtk progressbar widget.  The 
problem is that some theme engines (like clearview) override the draw logic with 
their own internal logic, as such, the styles in the RC file doesn't work (or 
for that matter, the coloring within the current client).  If you're client 
doesn't display those bars in green or red (or shades between if using gradiated 
colors), you are using such a theme.

  My thought here is that the progressbars, for what we use them for, are very 
simple widgets, and that it may just make the most sense to make our own - after 
all, all we are really doing is just drawing a rectangular area of some color. 
In this way, we can make sure the appropriate styles work.

----
  text colors in the info window:  Currently, like other portions of the code, 
these values are hardcoded.  If the server says the message is red, it is drawn 
in red.  This would obviously cause problems if you use a red background in your 
theme.

  I'm thinking here to add something like 'text_red' themes, in which once 
again, you can set the text colors (may not be red) as well as styles to fix 
this problem.  If you have a red background, you may set the text_red thing to 
draw in pink instead for example.

  For the extended message types, I thinking to have styles for all of those, 
and if a style isn't set, it falls back to default.  In this way, once again, 
the player can customize all of these how he wants, and we don't have to have an 
interface within the game to do it (that might be nice, but having this in an RC 
file at least makes it reasonable, especially if we have some theme files that 
are nice).

  The complication in all this is that in the extended message type, one can set 
colors for specific portions of messages with '[color=blue]blue text[/color]' 
type of logic.  That in itself isn't a problem, unless the player has a blue 
background.  Since color can be anything, including rgb values, it also becomes 
very difficult for the client to try and make intelligent decisions on it - they 
can't necessarily look up a style for blue text, as they at may not exist. 
Current solution is to basically just hope it doesn't come up, but that doesn't 
seem like a great solution.
--

  Thoughts/comments/suggestions on all of this?






More information about the crossfire mailing list