Difference between revisions of "UI Overhaul"

From PCGen Wiki
Jump to: navigation, search
(Demo)
Line 38: Line 38:
  
 
==Demo Status==
 
==Demo Status==
 +
* 2010-05-10: Sources and characters are now accessible.
 
* 2010-05-06: Sources can now be loaded, but characters are currently not accessible.
 
* 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-05-01: New downloadable demo added to CI process.

Revision as of 03:46, 17 May 2010

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!

Global Changes

Tabs

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 UI Autobuild to download the files. To run it you will need the following:

  • Libraries archive - only needs to be downloaded once
  • Program archive - The PCGen program as updated with the latest UI work, download this regularly to try out our latest work.
  • A source of data - copy the data, outputsheets, preview and system folders from your 5.16.2 or later install of pcgen or grab the data download from the main autobuild .

Note: To get the above files you will need to be logged into Hudson. A more widely accessible distribution channel will be set up shortly.

Demo Status

  • 2010-05-10: Sources and characters are now accessible.
  • 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

  • JTreeViewPane
This class is an improvement upon JTreeTable that uses a JTreeViewModels instead of a TreeTableModel to display the data in a JTreeTable. Use of the JTreeViewPane is preferred over use of the JTreeTablePane
  • GenericListModel
This is a simple extension of a ListModel that supports Generics. This implementations of this class use GenericListDataEvents to propagate changes in the list. GenericListDataEvents the set of Data that was affected during the change; when data is added, it includes the added data, when data is removed or changed, it includes the removed data.

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 GenericListModels 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 GenericListModel.
  • 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 GenericListModel that they associate with and update themselves accordingly.