4 May 2008 @ 01:08, by John Ringland
Before joining the conversation, please read and accept this Invitation to a Conversation.
Excerpts from brainstorming notes related to
SMNDesignView
For more information on SMN see SMN
on Anandavala.
I am exploring the idea of developing a Netbeans 6.0 module,
either as a plugin or as a rich-client application.
Things to consider:
I need a good vision of what I am building before I start
designing it.
What is it that the SMN functionality seeks to provide the
application user? What will people want the whole application or
plugin to do?
What sorts of things will people want to be able to do with the
GUI and with the model and with the simulation space itself via the
GUI? How best can the GUI facilitate this?
If developed as a plugin then how will the SMN functionality be
integrated into the rest of Netbeans?
If developed as a rich-client application then how will it come
together as a single whole application?
How best to implement the matrix itself? As some kind of table? It
needs to be programmatically controlled and not set in the code –
we may want more or less rows or columns, we may want different types
of elements altogether (e.g. instead of text fields they are buttons
perhaps).
The matrix-view is a small window that allows for detailed access,
but for large models we need a lower resolution but broader scope
view, we could have subsystem / supersystem viewing levels for the
matrix. One could view systems at the atomic scale, or as a single
whole system, or at many different levels between these. The designer
can click on systems (either by row, column, vector element or rowOp)
and choose to collapse all sibling subsystem and show only their
supersystem. Or they can drill into a supersystem and show all or
selected subsystems.
The state vector needs to be represented somehow in the
matrix-view so that the system designer can visualise the current
state of the model. The multiple system viewing levels apply to the
state vector as well.
Whether an SM or an SV element, at each level there is some screen
graphic to represent it to the designer. If the element is an atomic
system it shows a text field to display and edit the data. If it is a
conceptual system then there is an icon that displays the subsystems
as small squares within the element.
When the designer double-clicks on an element they drill into the
system and reveal all subsystems. There is also a right-click option
on elements that brings up a dialogue box for selecting which
subsystems to show.
The main interface is a matrix-view into the SMN model so some
kind of table UI is required, for example a JTable from Java.
The article at (http://www.codeguru.com/java/articles/162.shtml)
describes how to create a JTable where the cells can be any
Jcomponent.
A JTable “is meant to be placed in a JscrollPane .”
“Each JTable has three models: a TableModel ,
TableColumnModel , and ListSelectionModel .
All table data is stored in a TableModel , normally in a
2-dimensional structure such as a 2D array or a Vector
of Vector s. TableModel implementations
specify how this data is stored, as well as manage the addition,
manipulation, and retrieval of this data. ”
Perhaps the SystemMatrix can be concepualised as a TableModel and
accessed via a JTable.
From the JTable entry of the Swing documentation at
(http://java.sun.com/developer/Books/swing2/chapter18-01.html).
“18.1.2 The TableModel Interface
abstract interface javax.swing.table.TableModel
Instances of TableModel are responsible for storing a
table's data in a 2-dimensional structure such as a 2-dimensional
array or a vector of vectors. A set of methods is declared for use in
retrieving data from a table's cells. The getValueAt()
method should retrieve data from a given row and column index as an
Object , and setValueAt() should assign the
provided data object to the specified location (if valid).
getColumnClass() should return the Class
describing the data objects stored in the specified column (used to
assign a default renderer and editor for that column), and
getColumnName() should return the String
name associated with the specified column (often used for that
column's header). The getColumnCount() and getRowCount()
methods should return the number of contained columns and rows
respectively.
Note: The getRowCount() is called frequently
by JTable for display purposes and should be designed
with efficiency in mind because of this.
The isCellEditable() method should return true
if the cell at the given row and column index can be edited. The
setValueAt() method should be designed so that if
isCellEditable() returns false , the object
at the given location will not be updated.
This model supports the attachment of TableModelListener s
(see below) which should be notified about changes to this model's
data. As expected, methods for adding and removing these listeners
are provided, addTableModelListener() and
removeTableModelListener() , and implementations are
responsible for dispatching TableModelEvent s to those
registered.
Each JTable uses one TableModel instance
which can be assigned/retrieved using JTable 's
setModel() and getModel() methods
respectively.”
I could use a JTable as a view into the system matrix and place
into that view either standard table cells (data input / output) for
atomic systems OR icons for conceptual system interfaces. For the
state vector the cells can be either atomic data OR icons for
conceptual system states. The rowOps are actually 'vSystem”
objects, they are either simple data OR icons for operations that are
defined elsewhere.
Some examples, all integer or double numerical data and summation
operator, all strings and concatenation operator, conceptual systems
with corresponding icons or a mixture of these.
The user can drag and drop columns around the place to rearrange
the view, the corresponding row, rowOp and state vector element is
moved as well. The columns are the only means by which the designer
can rearrange the systems in the view.
I found some great code examples for tables with all kinds of
useful enhancements like groupable rows and columns and so on...
(http://www.crionics.com/products/opensource/faq/swing_ex/SwingExamples.html)
Some useful table
extensions may be:
Groupable Header
Use to represent the sub/supersystem structure of the model.
Similarly below.
|
Multiple Row Header
|
Multi-Line Header
Provide full length names for systems.
|
Mixed (Colored Cell, Multi-Font
Cell, Multi-Span Cell)
Use to highlight certain elements or distinguish certain
systems by using different fonts and colours.
|
Push and Sort
Allows the designer to rearrange the systems in the matrix-view
based on the data in the elements.
|
ToolTip Header
Provide extra information about each system.
|
Fixed Column
Keep the State Vector and RowOp vector in place so we can have
the matrix and all vectors represented within a single table
object.
|
Fixed Row
|
SmallCell and ComboBox
Useful when there is only a small number of values to choose
from or when using symbolic states like in a Turing machine.
|
Column Border
Use to distinguish the SystemMatrix, StateVector and RowOp
vector.
|
Cell Border
Use to show private or protected systems that only allow
interactions with system interfaces within the marked regions.
|
Editable header
Allow the designer to easily rename systems.
|
Before joining the conversation, please read and accept this Invitation to a Conversation.
|