Basic Organization of UI Software

1
Basic Organization of UI Software
2
The User Interface

• Typically want to think of UI as only one
  component of an overall system
• The part that deals with the user
• Distinct from the functional core (AKA the
  application)

3
Separation of UI from Appl

• Really good reasons to want separation of UI (In
  general want separation of concerns)
• Modularity (good software design)
• Different expertise needed
• Dont want to iterate the whole thing

4
Unfortunately this is typically very hard to do
in practice

• More and more of interactive programs are tightly
  coupled to UI (in some cases everything)
• Generally need to structure around user concepts
• UI structure sneaks into application
• Tight coupling can offer benefits to user (better
  feedback)

5
Separation of concerns is a central theme of UI
organization

• A continual challenge
• A continual tension and tradeoff
• Real separation of UI from application is almost
  a lost cause

6
UI tasks

• So far have
• Clearly there is more structure

Appl
UI
7
UI tasks

• Basic parts of UI

Input
Appl Inter
Appl
UI Core
Output
8
UI tasks

• Basic flow (later Normans Diagram)

Input
Appl Inter
Appl
Output
9
How do we connect these disparate parts into
working whole

• Tempting to architect systems around these boxes
• One module for input, one for output, etc.
• Has been tried (Seeheim model)Didnt work real
  well

10
Architectures with 3 big boxes dont work well
because...

• Modern (direct manipulation) interfaces tend to
  be collections of quasi-independent agents
• Each object of interest is separate
• e.g. a button
• produces button-like output
• acts on input in a button-like way
• etc.

11
Leads to object-based architecture

• Each object implements each aspect
• In a way that reflects what it is
• Objects organized hierarchically
• Normally reflecting spatial containment
  relationships
• Interactor trees

12
Challenge separation of concerns

• Challenge is doing all this different stuff in a
  single object without creating a hopelessly large
  and complicated beast
• Will see strategies later
• Basically will use O-O techniques to manage
  complexity

13
Tasks again in more detail (roadmap of topics)

• Core functions (cross cutting)
• Hierarchy management
• Again will be trees of objects
• Geometry management
• coordinate systems
• bounds
• Object status / information management

14
Tasks again in more detail

• Output
• Layout
• establishing size and position of each object
• (Re)drawing
• Damage management
• knowing what needs to be redrawn
• Localization customization

15
Tasks again in more detail

• Input
• Picking
• Figuring out what objects are under a screen
  point
• Event dispatch, translation, handling
• A lot of the work is in here

16
Tasks again in more detail

• Application interface
• Wont actually have a lot to say about this

17
Example subArctic

• All functions of an interactive object
  encapsulated in a base class
• The interactor interface (API), and
• The base_interactor class
• All objects on the screen inherit from this base
  class
• Again interactor control, widget, component,
  container in other systems

18
Standard object-oriented approach

• Base class (or interface) defines the set of
  things that every object must do
• Subclasses provide specific specialized
  implementations
• e.g., do the right drawing, input, etc. to be a
  button vs. a slider vs. a column

19
interactor API defines methods for

• Hierarchy management
• Geometry management
• Object status / info management
• Layout
• (Re)drawing
• Damage management
• Picking

20
In subclasses and other parts of the toolkit

• Input dispatch and handling
• Application interface
• Via callbacks
• subArctic does not really support
  internationalization / customization

21
Hierarchy management
22
subArctic interfaces are trees of interactors
top_level

• To make something appear on the screen you must
  add it to the tree
• SA takes care of many details from there
• Screen redraw
• Input dispatch

column
button
button
23
Hierarchy management

• interactor API provides methods for interactor
  tree manipulation
• parent(), child(I), num_children()
• add_child(), remove_child(),
• move_child_to_top(),
• Debugging hint if nothing shows up on the
  screen, check that you added it to the tree.

24
Geometry management

• Every interactor maintains its own geometry
• Bounding box x(), y(), w(), h()
• x,y is relative to parent
• i.e., 0,0 is at parents top-left corner
• All drawing happens within that box
• System clips to bounding box
• Including output of children!
• Drawing is relative to top-left corner
• Each interactor has own coord system

25
Object status / information

• Each interactor maintains information about its
  state
• visible(), enabled()
• Each keeps application info
• user_info(), set_user_info()
• Hint will need this for project 1

26
Each object handles

• Layout (later)
• Drawing
• Each object knows how to (re)create its
  appearance based on its current state
• draw_self() which calls draw_self_local() (which
  you write)
• draw_children()
• This is the only way to draw on the screen!!

27
Each object handles

• Damage management
• Tell the system that something about your
  internal state has changed and your image may not
  be correct
• damage_self()
• Picking
• Determine if a point is inside or over
• picked_by(x,y)
• In local coordinates of the object

28
Other parts

• Input (will talk about later)
• Application interface
• Not in interactor, but there is a convention for
  callbacks that all use
• Application object registers with the
  interactor and says call me when something
  happens

29
Callback

• All objects receiving callbacks must implement
  the callback_object interface
• One method callback()
• Gets called upon user action
• Parameters indicate what happened
• Application responds by

30
Callback

• All objects receiving callbacks must implement
  the callback_object interface
• One method callback()
• Gets called upon user action
• Parameters indicate what happened
• Application responds by modifying the interactor
  tree

31
Lots of parts, but

• Base classes (base_interactor and
  base_parent_interactor) provide many default
  implementations
• e.g. pick() which calls picked_by() which just
  tests for inside bounds
• e.g. draw_self() sets up local coordinate system,
  clipping, etc. and calls draw_self_local()
• subArctic motto It just works

32
Lots of parts, but

• Only have to implement the specialized parts
• Typically draw_self_local() and input
• But can implement many different things to get
  custom behavior!

33
Practical subArctic details
34
subArctic conventions

• Uses names_like_this
• All instance variables are protected
• named _variable
• read with variable()
• write with set_variable(value)

35
Lets build an interface...
36
How does Java find subArctic (or any .class files
it needs)?

• Simple mapping from names to locations
• Needed for operation on the web
• Each class has two parts
• Package it is in (from package decl)
• Class name within that package (from class
  declaration)

37
Mapping from file system to classes

• Packages map to directories
• sub_arctic.lib package maps to /sub_arctic/lib
  directory
• Classes map to files
• interactor maps to interactor.class
• which is normally created from interactor.java

38
CLASSPATH

• But where is in /sub_arctic/
• System starts looking for package directories in
  a fixed set of places
• The places listed in your CLASSPATH
• separated list on Unix, on Windoze
• System looks inside those directories to find
  package directories

39
CLASSPATH

• Note package directories themselves never go in
  CLASSPATH
• The directory that contains package directories
  is the one listed
• Suggest only one place for Java code gt only one
  entry in CLASSPATH

40
Problems with CLASSPATH

• Compiler may let you compile, but then cant find
  .class files at runtime
• Make sure the thing in your CLASSPATH is the
  directory that contains the directories for your
  packages
• e.g., /java/sub_arctic/lib/interactor.class
• for sub_arctic.lib.interactor
• CLASSPATH should have /java

41
Problems with CLASSPATH

• Did you leave out the package declaration in your
  source file?
• user is not expanded
• sub_arctic.zip file in CLASSPATH
• /myjava/sub_arctic instead of /myjava

42
subArctic can be found

• http//www.cs.cmu.edu/hudson/teaching/05-631/sub_
  arctic
• /afs/cs.cmu.edu/project/hudson-6/sub_arctic

43
(No Transcript)