GUI Architecture

= GUI Architecture =

Introduction
The current GUI code in PARPG is rather sketchy at best. There is no real consistent way to do things and Hud is becoming a conglomeration of doing all the GUI interactions. This article is an attempt to reorganize how our GUI code is made and standardize the future process for implementing new GUI widgets to the game.

If you are not familiar yet on how the GUI code works in the game you can check out several files within PARPG itself, but also check out the following links to get a grasp on how PyChan works.
 * PyChan Overview - Good information on the general construction of a typical PyChan GUI construction
 * FIFE Documentation - This further explains the syntax of using PyChan
 * FIFE GUI Tutorial - A quick and dirty tutorial to get you playing with PyChan

The following files contain most of PARPG's GUI code: hud.py, contextmenu.py, inventorygui.py, popups.py, filebrowser.py

Easy Cleanup
Probably the first and easiest thing to change will be to restructure our source files. Anything GUI related should be put into a /scripts/gui directory so that we do not clutter up the main script folder with tons of source files. This is a small issue and can be easily fixed.

Hard Cleanup
Now comes the major part of the re-factor. It helps if you break apart how our GUI can be thought of down into two distinct categories: Out of game, and In game. An example of an out of game widget would be our games title screen, or credits whereas in game widgets would be things like the inventory, our hud, and context menus. There is a small subset of widgets that can be members of both of these groups, but for the most part they are mutually exclusive.

Our re-factoring should take this into consideration. Thus I propose two different classes be created to manage these interactions.

Commonalities
The following list tells us what all widget code should have in common.
 * Each widget should have a show/hide method of its own.
 * Each widget should have an initializing method of its own.
 * A value denoting whether or not the widget is a blocking widget. Meaning that if this widget is displayed, other widgets should not be.

Differences
Differences are a little less tangible and will follow less strict guidelines since they are mostly conceptual differences rather than implementation differences.

The main difference is that out of game widgets will force the game to either pause, or put the game in an uninitialized state. For example, we don't want to have our character running around or dying when we are actually trying to load/save a game. Nor when PARPG first starts and shows us the title screen do we want the a new game to be running in the background while we decide what we are going to do.

Dialog Widgets
Dialog boxes are probably the exception that proves the rule to all of the above. Dialogs are going to be present in nearly every part of the game. We will most of the time always want them to leave the game in an un-paused state when they appear, and we will most of the time always want them to be displayed on top of and at the same time with other widgets.

Specific Coding Requirements
To be written...