UI Overhaul

From PCGen Wiki
Jump to: navigation, search

Introduction

PCGen is undertaking a UI overhaul, details below, . It is being lead by Connor Petty, James Dempsey and Tom Parker on the Code side and John Carimando and Kerry Kenneally on the Look and Feel side.

Other useful links

Overall Approach

  1. We feel that PCGen doesn't need a radical overhaul, it just needs lots of tweaks to the existing design to make it really feel like a RPG app.
  2. We feel that the UI overhaul from a design perspective can be done in lots and lots of small changes, hopefully making it easier for developers to tackle items as well as minimising the impact to end users. They have a fairly long list of small changes to make, which will be detailed in this wiki over time.
  3. The designers will run any possible designs past the developers first as they're not 100% aware of the limitations of Swing and they want to make sure that their designs aren't too time consuming or too difficult to implement. This will probably be in the format of screenshots and/or text.
  4. Once a rough design is agreed upon between the developers and the designers then the idea is to throw it to the community for discussion (wiki/polls etc where appropriate). The idea is to give the users a solid idea to discuss around as opposed to a free-for-all. The design is then finalised once the community has had its say.
  5. Developers can pick up on the various small feature requests and develop them on trunk and/or on cdomui branch as appropriate. These changes can be applied over the course of 6.0/6.2 and beyond, we realise that we already have enough on our plates for 6.0!
  6. The user interface should be usable on screens down to a minimum of 1024 x 600 (i.e. common netbook size)

Global Changes

Tabs

Other dialogs:

Demo

You can now give the new user interface a go on your own PC. As part of the autobuild of the CDOM UI branch, we are now creating a downloadable program. Go to CDOM UI Autobuild to download the files. To run it just grab the "PCGen CDOM UI Autobuild - Full Distribution" and extract it to a suitable location on your computer. Then run it using pcgen.exe or pcgen.sh files as normal.

Demo Status

  • 2011-03-06: Merged with trunk in the uisync branch
  • 2011-02-13: Templates tab ready for testing.
  • 2011-02-12: Races and domains tabs ready for testing. Equipping and purchase tabs - unqualified colouring applied, info on selected item displayed, equipment slot display tweaks. Source selection dialog fixes. Loading characters temporarily broken.
  • 2011-02-10: Races and domains tabs working still some tidy up remaining.
  • 2011-02-08: Characters can be loaded and saved. Gear purchase and equipping working, still some tidy up remaining.
  • 2010-09-21: Summary, classes, skills and Feats and Abilities tabs ready for testing.
  • 2010-05-10: Characters can be created, but not loaded or saved.
  • 2010-05-06: Sources can now be loaded, but characters are currently not accessible.
  • 2010-05-01: New downloadable demo added to CI process.
  • 2010-04-30: Revised load sources page added. Sources cannot be loaded and characters are not currently accessible.

Code Details

New Utilities

  • JTreeViewTable
This class is an improvement upon JTreeTable that uses a JTreeViewModel instead of a TreeTableModel to display the data in a JTreeTable. Use of the JTreeViewTable is preferred over use of the JTreeTablePane
  • ListFacade
This is a new type of list format for which its interface contains read only methods. This is used in much of the facade layer due to since listeners can be attached to it to monitor changes to the list. The ListFacade has one of 3 types of change events: Element Added, Element Removed, and Contents Changed. The Element Added/Removed events contain not only the element that was added or removed from the list but also the index at which the event occurred. The Contents Changed event tells the listener that more than one of the elements in the list has been changed and the whole list should be considered changed.

Design Specification

The most important design aspect of the new UI is that it will have an inherent separation from the core by having all of the data accessible through facades. This means that the UI will never know the implementation of the underlying data.

  • Facade Implementation
Facades are expected to override their toString() method because they are going to be displayed directly in the UI.
The ListFacades that are returned from methods are expected to be the same instances each time that method is called. Also, any changes to the underlying data must be reflected with changes in the ListFacade.
  • Swing Components
Any class that extends a swing component is expected to have a null constructor
  • CharacterInfo Tabs
All of the data on these tabs must be loaded and saved to a hashtable. The reason for this is that all of the models that are used to display information should not need to be recreated each time that tab is selected. If the tab reuses the models then the amount of time between tab switching would become milliseconds instead of seconds. The models themselves are expected to listen to changes from the ListFacade that they associate with and update themselves accordingly.

Things to be done

See UI_TODO_LIST for a shared memory of things to be done.

Retrieved from "http://159.203.101.162/w/index.php?title=UI_Overhaul&oldid=3030"