Difference between revisions of "UI Overhaul"

From PCGen Wiki
Jump to: navigation, search
(Design Specification)
(Global Changes)
Line 21: Line 21:
 
=Global Changes=
 
=Global Changes=
  
 +
* New Minimum supported resolution of 1024x600
 
* [[Sort Dropdowns]]
 
* [[Sort Dropdowns]]
 
* [[Logo]]
 
* [[Logo]]

Revision as of 09:42, 24 June 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 CDOM 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: 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.