The metaserver support seems to be able to “lock up” the client for long periods of time if a network operation blocks.

• The whole UI hangs when this happens (windows do not update).
• How hard would it be to multi-thead the client?
• Update: The client has changed to use non-blocking network operations and now programmatically times out at 30 seconds instead of blocking for about 4 minutes. The client still hangs. It might be good to put something on the dialog to say the delay might happen and not to get too itchy to kill it.

Ability to play audio files in conjunction with server features that allow maps to specify mood music.

• User-interface controls to configure what audio file to play for a particular mood.
• Deploy a basic set of standard audio files with the client.
• JXClient uses .wav, but Ragnor says .ogg is preferred, except that he tried and gave up once. It would probably be good to try for .ogg. .wav is uncompressed.
• Deploying audio files via network should likely happen outside of the client protocol, and use a standard file transfer protocol, but due to the size of the files this should be carefully thought out.

• Try SO_LINGER at mwedel's suggestion to try to address very bad lockup if the keyboard is used while quitting the client.

• The client now supports use of a general gtkrc file and layout-specific gtkrc files in ~/.crossfire.
• A GTK_MODULES environment variable seems to easily defeat theming.
  • This seems not uncommon with GTK apps.
  • GTK3 notes specifically address fixing things that have made it possible for custom theme engines to do this.
  • The client should probably have some kind of built-in help to let the user know what might be done to fix it… the current symptoms are very hard to interpret.

• Pickup seems recently broken (Maybe with switch to Glade3?). The default selections are incorrect.

• spellmon 2 is supported in client code, but the extended information is not actually available to the player yet.
  • additional ingredients should be listed in the Cost/Cast column rather than by adding a new column.

• Panels containing buttons that can be configured to issue specific commands.
• Buttons might even allow ability to configure a graphic on its face.

• Add a chat-specific panel?
• Message routing system should allow a client to not have a specific number of message panels.
  • So layouts can vary the number of available panels to adapt to large/small footprints, etc.
  • Auto-disable routing to panels not defined in a layout.
  • Disallow configuring routing to unavailable panels.
• In-client configuration of message routing to the available message panels?
• Ability for the user to determine the number of message panels in the client.
  • This could be used to make smaller layouts as the number of panels could be reduced to 1.
• Add a “status bar” style message panel that displays only the last message of a particular type.
• Automatic line-wrap based on message pane size, font, etc. The client wraps at 40 characters whether that is sensible or not.
• Optional logging of chats and tells.
• Time stamping of messages.

• Document GTK-V2 in-client what Echo Bound Commands means/does. Is it even useful? How?
  • “Bound” refers to keybinds.

Introduces players to scripting without requiring the depth of knowledge needed to run scripts.

• GUI-assisted scripting that is not as powerful as the regular scripting interface.
• Dialog similar in concept to keybinding, but different in function.
  • Table of maybe four columns, a variable or fixed number of rows:
    • Trigger
    • Comparison operator (if the trigger needs a level check; ie. HP trigger is probably level triggered, so equal, less than, etc).
    • Trigger level
    • Command
  • Buttons to control the dialog

• Aliases for hard-to use commands like: `write` as an alias for `use_skill inscription`? Such a thing might be better done server-side for some things. This could be considered an enhancement of key-binding.

• New default layout.
  • With the increasing popularity of netbooks, gtk-v2.glade is not a good default. The default needs to be a small-screen-friendly layout.
  • JXClient min height is 640.
  • JXClient min width is 1000.
• Sizing handle visibility improvement.
  • dialogs.glade has had a lot of work done to improve visuals.
  • The main client windows really need to make the resize handles more visible… especially the default layout.
• dialogs.glade:
  • mwedel suggests splitting dialogs.glade into pieces with a script to merge the pieces back into dialogs.glade. The rationale presented was that multiple developers could work on dialog sets without having as much need to merge changes with work by other developers. The dialogs file is also getting rather large. kbulgrien suggests split/merge instead of just merge. Some style work is nicer to do with all the dialogs in the same file.
  • Review all dialogs for use on a small desktop. The configuration dialog has been fixed, but others have not been similarly reviewed.
• sixforty.glade:
  • Experiment with how to make both message panes visible.
  • Notebook for ground/inventory?
• Vertical bar indicators are possible.
  • Add variety to available layouts.
  • Could result in more dense status layout?
• Map pane scroll bars
  • Remove?
  • Make functional?
  • Consider Magic Map when deciding what to do with them.

• Consider adding client-side help.
  • Since we now have a libglade client, it is possible to construct dialogs at run-time.
  • The client could obtain help from the server dynamically by using the help commands.
    • This could be done automatically, but that could be too complex (when? on connect, after login, etc.).
    • A Help | Update and/or Help | Create command could be added that invokes the function to create a help dialog.
    • A run-time-created XML document with help pulled from the server could be saved to a file and re-used at client start.