Abstract Widgets

1
Abstract Widgets

• Dealing with more complex models

2
Abstract Widgets

• Most widgets limited in terms of the complexity
  of the model they can handle
• Need to consider how we might use widgets where
  the model is external to the widget
• Abstract widgets handle this arrangement by
  supported common models
• Tree widget handles hierarchy
• Table widget handles tabular structured data

3
Widgets
Windowing System
Graphics
View
EssentialGeometry
Model
Controller
Input
4
Widgets
Windowing System
WIDGET
Graphics
View
EssentialGeometry
Model
Controller
Input
Abstraction of the Model View Controller
Arrangement
5
Widgets
Property Settings
Windowing System
WIDGET
Graphics
View
ABSTRACT MODEL INTERFACE
EssentialGeometry
Model
Controller
Input
6
Abstract Widgets

• Separates the model from the widget through a
  well know abstract model interface
• Model is implemented externally needs to respond
  to the abstract interface
• This allows widgets to be used to control deeper
  more complex systems
• Filestores
• Databases

7
Property Settings
Windowing System
WIDGET
Graphics
View
ABSTRACT MODEL INTERFACE
EssentialGeometry
TranslatorObject
Controller
Input
Model
8
Translator Object

• Translates between the abstract model interface
  and the means of driving existing APIs for the
  model
• The translator class
• accepts the model in its constructor
• implements all of the widget abstract model
  methods,
• passing them on to the appropriate model methods.
  
• Translator is not another model
• It will need to hide complexity of the underlying
  system but should seek to be as thin as
  possible

9
Tree Widgets

• Tree are one of the classic abstract model
  widgets
• Provide an interactive interface onto
  hierarchical structures
• Browsing through the structure
• Amending nodes in the structure
• Model is external to the widget
• Networks systems
• File stores
• Interactive elements separated from the
  underlying model through an abstracted interface

10
File store

• Hierarchy reflects file store
• Nodes are
• Directories
• Files
• Each Node has
• Label
• Icon
• Open Close Box
• Changed Icon

11
Favourites

• Hierarchy reflects user structuring
• Nodes are
• Folders
• URLS of each site
• Each Node has
• Label
• Icon
• Open Close Box

12
Software Packages

• Hierarchy reflects software structure
• Nodes are
• Package names
• Files defining classes
• Each Node has
• Label
• Icon
• Open Close Box

13
Mail Boxes

• Hierarchy reflects user structuring
• Nodes are
• Folders of mailboxes
• Mailboxes containing email
• Each Node has
• Label
• Icon
• Open Close Box

14
Similarities

• All represent a tree as an indented outline using
  the same layout.
• Every node of the tree has a textual name and one
  or two icons. Containers have two icons, one for
  open and one for closed.
• They all use little plus/minus boxes to
  open/close the container
• Clicking on the name allows the user to change
  the name of any of the nodes

15
Differences

• Containers have variable numbers of children
  arranged in varying depths in the tree.
• Every node has a different name.
• There are different icons for different
  applications and for different items within those
  applications.
• Some use faint gray lines to indicate which nodes
  are siblings but some do not.
• The may use a different type and size of font.

16
Abstract Widget Structure

• Similarities handled by the widget
• Differences managed by either the model or
  properties
• Properties focus on appearance
• Font face, size and style
• boolean to display sibling lines
• number of pixels to indent at each level
• External models handle content differences.

17
Abstract Widget Interface

• Interface provides all of the information the
  widget needs to know about the tree
• Two main components to the interface
• The model itself that our widget will manipulate
  to interact with the structure
• The second is the notification mechanism for the
  widget to learn about external model changes.

18
TreeNode
public interface TreeNode int
numberOfChildren() // how many children
nodes are there. Zero for leaf nodes TreeNode
getChild(int childIdx) // get one of this
nodes children Image getIcon() // gets
the primary icon for this node Image
getOpenIcon() // if this is a container
this returns the icon for when it is open
String getName() // gets the name of this
node void setName(String name) //
changes the name of this node
19
TreeNode Interface -- Browse the Model

• Provides all the information to move through
  hierarchical structure allowing the widget to
  display it.
• Can recursive tour through the tree and present
  it as needed.
• Does not make the widget aware of changes to the
  underlying model so other elements of the
  interface are needed

20
Notification of Model Change

• Changes can occur at any point in the tree
• We can locate any node in the tree with a path
• each container provides access to its children by
  an index
• Sequence of indices that leads from the root of
  the tree to the desired node.
• Treewidget implements this to allow model to
  notify view of changes

public class TreeWidget extends Widget
public void nodeChanged (Listltintgt
pathToChangedNode) . . . public void
nodeToInsert (Listltintgt insertLocation) . . .
public void nodeToDelete (Listltintgt
deleteLocation) . . .
21
Model Change through the view

• Provide methods that let the widget alter the
  model

public interface TreeRoot public TreeNode
root public void addListenerWidget(TreeWidge
t widget) public void removeListenerWidget(T
reeWidget widget) public void
deleteNode(Listltintgt deleteLocation) public
void moveNode(Listltintgt fromLocation, Listltintgt
toLocation) public void changeName(Listltintgt
nodeToChange, String newName)
22
File browsing

• The entire file system is obviously too large to
  copy into the tree widget model. The abstract
  interface technique provides us the advantage of
  pre-built widgets on a signification model.
• Access to file system through an API and to
  provide tree browser will need three translator
  classes.
• a FileRoot class that implements TreeRoot.
• This class can have a constructor that accepts a
  path name for the root folder.
• a TreeFolder class and a TreeFile class to
  interface to folders and files respectively that
  implement TreeNode interface
• A TreeFolder would find out the number of files
  and folders that it contains and report them as
  children.
• Using the file system API the TreeFolder class
  will create TreeFolder or TreeFile classes for
  the folders and files that it contains.

23
Cone Trees
24
Hyberbolic Trees
25
Treeviz Maps

• Exploits size associated with each node to drive
  layout
• Need to amend the abstract model with a getSize()
  method in the treenode interface

26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
Degree of Interest Trees

• Exploits a degree of interest per node to drvie
  presentation to users

30
Microsoft File Table
31
Eclipse Error Log
32
Email List
33
Email List
Music Player List
34
Similarities to be handled by Widget

• A fixed set of columns each with a title and/or
  possibly an icon.
• An arbitrary number of rows that will probably
  require scrolling.
• Every cell of the table has a string and/or an
  icon for its content. If the icon and string
  occur together the icon is first.
• Rows can be sorted based on any of the column
  contents.
• Rows can be selected and that selection used
  elsewhere. Selecting a song in will play that
  song. Selecting a message will display the
  contents of the message.
• It is possible to hide or show and resize the
  width of columns.

35
Differences to be handled by model and properties

• The number of columns is fixed but there are
  varying numbers of columns between applications.
• Columns have different names, icons and widths.
• The contents of rows and cells are all different.
  
• There are differences in font and background
  colour.

36
Table Widget

• The key is the communication between the widget
  and the model
• to retrieve and change model information
• to be notified of changes to the model.
• In most cases the table is used primarily for
  viewing of information rather than editing it.
• BUT, selected rows can be deleted and frequently
  cell string contents can be edited and changed.
• More complex manipulations of the table model are
  generally handled by other widgets and then
  notifications forwarded to the widget.

37
Abstract Model

• public interface TableModel
• public void addTableListener(TableListener
  listener)
• public void removeTableListener(TableListener
  listener)
• public int nRows() // returns the number of rows
  
• public TableColumn getColumns() // returns
  descriptors for all of the columns
• public String getCellString(int rowIndex, int
  columnID)
• public void setCellString(int rowIndex, int
  columnID,String newCellValue)
• public Image getCellIcon(int rowIndex, int
  columnID)
• public void selectRow(int rowIndex) // notifies
  the model when a row is selected
• public void deleteRow(int rowIndex)
• public enum ColumnJustifyLEFT, CENTER, RIGHT
• public interface TableColumn
• public int columnID()
• public ColumnJustify justification()
• public String getColumnName()
• public void setColumnName(String newName)

38
Table Listener Interface

• public interface TableListener
• public void cellToChange(int rowIndex, int
  columnID,
• String
  newCellValue)
• public void rowChanged(int rowIndex)
• public void rowsToDelete(int firstRowIndex,
• int
  nRowsToDelete)
• public void rowsInserted(int firstRowIndex,
• int
  nRowsInserted)
• public void columnDescChanged(int columnID)
• publis void tableChanged()

Provides Notification at Different Levels of
Scope (Table, Row, Cell, Labels)
39
Table Properties

• Our Table widget also needs properties.
• header font, cell font, background colour,
• Also alternating line background colour to
  highlight rows with slightly different colours.
• May also need column properties balance between
  the properties for columns and things placed in
  the model
• Alignment could be a property but is placed in
  model as columns are already defined
• Deciding between properties and model elements
  based on how often you see changes occurring and
  by whom

40
Drawing Widget

• More complex model than regularly structured tree
  and table
• Want to explore how we may have a model to
  support some form of shared drawing interface
• Placement of entities within some form of canvas
  will be vital
• But what else

41
(No Transcript)
42
(No Transcript)
43
Similarities

• The model is fundamentally a list of objects to
  be drawn on a surface.
• There is a menu of objects that can be selected
  and placed in the drawing area.
• Creating new objects uses the same event sequence
  and interactive behaviour.
• click to place an item,
• down-drag-up to create two control points,
• placement of multiple control points.
• Selection works by clicking on objects,
  shift-clicking to select multiple objects and
  rubberband rectangles to select a group of
  objects.
• Objects can be dragged around the draw area.
• Object are manipulated by dragging control points
  and those control points are displayed in a
  similar way.
• Deleting objects is the same.

44
Obvious Differences

• Set of objects to be created is very different as
  is their appearance on the menu
• How each object is drawn and how it relates to
  its control points is differen
• The Geometry for selection objects differs

45
Drawing Model

• Drawing model is simple BUT the model is strongly
  linked with the presentation.
• Objects in the drawing model differ in the way
  that they draw themselves and in the way that
  they handle their geometry.
• This fuzzy relationship between the model and the
  presentation
• The model for a drawing is simply a sequence of
  drawing objects that can be pained in order and a
  list of possible classes for drawing objects.

46

• public interface DrawingModel
• public void addDrawingListener( DrawingListener
  listener)
• public void removeDrawingListener(DrawingListener
  listener)
• public int nDrawingObjects()
• public DrawingObject getDrawingObject(int index)
  
• public void deleteDrawingObject(int index)
• public void addDrawingObject(DrawingObject
  newObject)
• public int nDrawingClasses()
• public DrawingClass getDrawingClass(int index)
• pubic interface DrawingObject
• public void redraw(Graphics g)
• public boolean isSelected(Point mousePoint)
• public Rectangle getBounds()
• public int nControlPoints()
• public Point getControlPoint(int index)
• public void setControlPoint(int index, Point
  newPoint)

47

• The DrawingModel itself consists of only three
  parts
• the registration of listeners
• the list of drawing objects with means for
  deleting and adding them
• a list of object classes that can be created.
• A DrawingObject needs a means for drawing itself
  to a Graphics object (redraw), support for
  selection(isSelected and getBounds) and
  mechanisms for manipulating control points.
• The DrawingClass contains the necessary
  information to create the menu and to create new
  objects.

48
Widget tasks

• 6 basic tasks that a widget must perform in
  either object creation mode (when one of the
  object classes is selected in the menu) or
  selection mode (when the pointer is selected in
  the menu)
• Redraw the drawing from the model.
• Create new objects on the drawing surface
• Select objects
• Drag objects around
• Drag control points
• Delete objects

49
Redrawing

• public class DrawingWidget
• private DrawingModel myModel
• private int selectedObjects
• . . . .
• public void redraw(Graphics g)
• for (int i0iltmyModel.nDrawingObjects()i)
  
• myModel.getDrawingObject(i).redraw(g)
• for (int i0iltselectedObjects.length i)
• DrawingObject somyModel.getDrawingObject(i)
• for (int cp0cpltso.nControlPoints()cp)
• Point pso.getControlPoint(cp)
• draw control point at point p

50
Creating new Drawing Objects

• nDrawingClasses() and getDrawingClass() methods
  give us the information that we need to build the
  menu of objects that we are offering to the user.
  
• For each DrawingClass the getIcon() and getName()
  methods give us the information that we need to
  fill the menu.
• Enumaration InputSyntax informs how the item is
  to be drawn
• Single Click
• Two Point Drag
• Multi-point input

51
Single Click Strategy

• DrawingObject newObj
• on mouse down
• DrawingClass dc object class selected in the
  menu
• newObj dc.createNew()
• newObj.setControlPoint(0, current mouse position
  )
• myModel.addDrawingObject(do)
• on mouse move
• newObj.setControlPoint(0,current mouse position
  )
• on mouse up
• newObj.setContolPoint(0,current mouse position )

52
Two Point Drag

• DrawingObject newObj
• on mouse down
• DrawingClass dc object class selected in the
  menu
• newObj dc.createNew()
• newObj.setControlPoint(0, current mouse position
  )
• newObj.setControlPoint(1, current mouse position
  )
• myModel.addDrawingObject(do)
• on mouse move
• newObj.setControlPoint(1,current mouse position
  )
• on mouse up
• newObj.setContolPoint(1,current mouse position )

53
Selecting Objects

• Most of the work done by geometry calculations is
  in the drawing object method do.isSelected(selectP
  oint)
• public class DrawingWidget
• public DrawingModel myModel
• public int selectObject(Point selectPoint)
• for (int imyModel.nDrawingObjects()-1igt0i--)
  
• DrawingObject domyModel.getDrawingObject(i)
• if (do.isSelected(selectPoint) )
• return i
• return -1 // no selection
• . . . .

54
Rectangle Selection

• public class DrawingWidget
• . . .
• public IndexList selectObjects(Rectangle select)
• IndexList result empty list of object indices
• for (int i0iltmyModel.nDrawingObjects()i)
• DrawingObject domyModel.getDrawingObject(i)
• if (do.getBounds().isInsideOf(select))
• result.add(i)
• return result

55
Summary

• Abstract widgets allow GUI to be linked with more
  complex models
• Exploit comonalities across different infromation
  structures
• Trees
• Tables
• Can be used to provide interfaces to more complex
  structures
• Drawing widget
• Next Examples of the use of JTable and JTree
  widgets
• Read through the swing tutorials.