1. Basic Organization of UI Software

2. 2 The User Interface n 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. 3 Separation of UI from “Appl” n Really good reasons to want separation of UI (In general want “separation of concerns”) – Modularity (good software design) – Different expertise needed – Don’t want to iterate the whole thing

4. 4 Unfortunately this is typically very hard to do in practice n 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. 5 Separation of concerns is a central theme of UI organization n A continual challenge n A continual tension and tradeoff n Real separation of UI from application is almost a lost cause

6. 6 UI tasks n So far have: n Clearly there is more structure UI Appl

7. 7 UI tasks n Basic parts of UI Appl Input Output Appl Inter UI Core

8. 8 UI tasks n Basic flow (later: Norman’s Diagram) Appl Input Output Appl Inter

9. 9 How do we connect these disparate parts into working whole n Tempting to architect systems around these boxes – One module for input, one for output, etc. – Has been tried (“Seeheim model”) Didn’t work real well

10. 10 Architectures with “3 big boxes” don’t work well because... n Modern (“direct manipulation”) interfaces tend to be collections of quasi-independent agents – Each “object of interest” is separate – e.g. a button F produces “button-like” output F acts on input in a “button-like” way F etc.

11. 11 Leads to object-based architecture n Each object implements each aspect – In a way that reflects what it is n Objects organized hierarchically – Normally reflecting spatial containment relationships è“Interactor trees”

12. 12 Challenge: separation of concerns n 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. 13 Tasks again in more detail (roadmap of topics) n Core functions (cross cutting) – Hierarchy management F Again: will be trees of objects – Geometry management F coordinate systems F bounds – Object status / information management

14. 14 Tasks again in more detail n Output – Layout F establishing size and position of each object – (Re)drawing – Damage management F knowing what needs to be redrawn – Localization & customization

15. 15 Tasks again in more detail n Input – Picking F Figuring out what objects are “under” a screen point – Event dispatch, translation, handling F A lot of the work is in here

16. 16 Tasks again in more detail n Application interface – Won’t actually have a lot to say about this

17. 17 Example: subArctic n All functions of an interactive object encapsulated in a base class – The “interactor” interface (API), and – The “base_interactor” class F All objects on the screen inherit from this base class n Again: interactor == control, widget, component, container in other systems

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

19. 19 interactor API defines methods for – Hierarchy management – Geometry management – Object status / info management – Layout – (Re)drawing – Damage management – Picking

20. 20 In subclasses and other parts of the toolkit: n Input dispatch and handling n Application interface – Via “callbacks” n subArctic does not really support internationalization / customization

21. 21 Hierarchy management…

22. 22 subArctic interfaces are trees of interactors n To make something appear on the screen you must add it to the tree n SA takes care of many details from there – Screen redraw – Input dispatch top_level column button

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

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

25. 25 Object status / information n Each interactor maintains information about its “state” – visible(), enabled() n Each keeps application info – user_info(), set_user_info() – Hint: will need this for project 1

26. 26 Each object handles: n Layout (later…) n Drawing – Each object knows how to (re)create its appearance based on its current state F draw_self() which calls draw_self_local() (which you write) F draw_children() F This is the only way to draw on the screen!!

27. 27 Each object handles: n Damage management – Tell the system that something about your internal state has changed and your image may not be correct – damage_self() n Picking – Determine if a point is “inside” or “over” – picked_by(x,y) F In local coordinates of the object

28. 28 Other parts n Input (will talk about later…) n Application interface – Not in interactor, but there is a convention for “callbacks” that all use F “Application” object registers with the interactor and says “call me when something happens”

29. 29 Callback n All objects receiving callbacks must implement the callback_object interface – One method: callback() – Gets called upon user action F Parameters indicate what happened F Application responds by…

30. 30 Callback n All objects receiving callbacks must implement the callback_object interface – One method: callback() – Gets called upon user action F Parameters indicate what happened F Application responds by modifying the interactor tree

31. 31 Lots of parts, but… n 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() n subArctic motto: “It just works”

32. 32 Lots of parts, but… n Only have to implement the specialized parts – Typically draw_self_local() and input n But can implement many different things to get custom behavior!

33. 33 Practical subArctic details…

34. 34 subArctic conventions n Uses names_like_this n All instance variables are protected – named: _variable – read with:variable() – write with:set_variable(value);

35. 35 Let’s build an interface...

36. 36 How does Java find subArctic (or any.class files it needs)? n Simple mapping from names to locations – Needed for operation on the web n Each class has two parts – Package it is in (from package decl) – Class name within that package (from class declaration)

37. 37 Mapping from file system to classes n Packages map to directories – sub_arctic.lib package maps to …/sub_arctic/lib directory n Classes map to files – interactor maps to interactor.class – which is normally created from interactor.java

38. 38 CLASSPATH n 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. 39 CLASSPATH n 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 => only one entry in CLASSPATH

40. 40 Problems with CLASSPATH n Compiler may let you compile, but then can’t find.class files at runtime n 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. 41 Problems with CLASSPATH n Did you leave out the package declaration in your source file? n “~user” is not expanded n sub_arctic.zip file in CLASSPATH n “…/myjava/sub_arctic” instead of “/myjava”

42. 42 subArctic can be found n http://www.cs.cmu.edu/~hudson /teaching/05-631/sub_arctic http://www.cs.cmu.edu/~hudson /teaching/05-631/sub_arctic n /afs/cs.cmu.edu/project/ hudson-6/sub_arctic

43. 43