Difference between revisions of "UI Overhaul"
| Line 5: | Line 5: | ||
=Introduction= | =Introduction= | ||
| − | PCGen is undertaking a UI overhaul, details below | + | PCGen is undertaking a UI overhaul, details below, we welcome feedback in our [[Talk:UI_Overhaul]] page. |
* [[Old UI Overhaul Page]] | * [[Old UI Overhaul Page]] | ||
| − | = | + | =New Utilities= |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* JTreeViewPane | * 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 | :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 | * 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. | :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= | =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. | 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 | *Facade Implementation | ||
:Facades are expected to override their toString() method because they are going to be displayed directly in the UI. | :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. | :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 | *Swing Components | ||
:Any class that extends a swing component is expected to have a null constructor | :Any class that extends a swing component is expected to have a null constructor | ||
| + | |||
*CharacterInfo Tabs | *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. | :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. | ||
=Progress Screenshots= | =Progress Screenshots= | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 11:48, 9 March 2010
Introduction
PCGen is undertaking a UI overhaul, details below, we welcome feedback in our Talk:UI_Overhaul page.
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.
