Layout Policies and Constraints in User Interface Design, Study notes of Software Development

Download Layout Policies and Constraints in User Interface Design and more Study notes Software Development in PDF only on Docsity!

Damage Management & Layout

Damage management

 Need to keep track of parts of the screen that need update

 (^) interactor has changed appearance, moved, appeared, disappeared, etc.  (^) done by “declaring damage”  (^) each object responsible for telling system when part of its appearance needs update

Damage Management

 (^) Can optimize somewhat  (^) Multiple rectangles of damage  (^) Knowing about opaque objects  (^) But typically not worth the effort

Damage Management in Swing

JComponent RepaintManager repaint() addDirtyRegion() paintImmediately() paintComponent() paintBorder() paintChildren() Event Dispatch Queue

Layout

 (^) Deciding size and placement of every object  (^) easiest version: static layout  (^) objects don’t move or change size  (^) easy but very limiting  (^) hard to do dynamic content  (^) only good enough for simplest cases

Dynamic layout

 (^) Change layout on the fly to reflect the current situation  (^) Need to do layout before redraw  (^) Can’t be done e.g., in paintComponent()  (^) Why?

Layout in Swing

 (^) invalidate() method  (^) Called on a container to indicate that its children need to be laid out  (^) Called on a component to indicate that something about it has changed that may change the overall layout (change in size, for example)  (^) validate() method  (^) Starts the process that makes an invalid layout valid--recomputes sizes and positions to get correct layout

“Issues” with Swing validation

 (^) invalidate() is often called automatically  (^) e.g., in response to changes to components’ state  (^) ... but not always  (^) e.g., if a JButton’s font or label changes, no automatic call to invalidate()  (^) Mark the button as changed by calling invalidate() on it  (^) Tell the container to redo layout by calling validate() on it  (^) In older versions of Swing you had to do this by hand  (^) Newer versions (post 1.2) add a shortcut: revalidate()  (^) Invalidates the component you call it on  (^) Begins the process of validating the layout, starting from the appropriate parent container  (^) Validation also uses the RepaintManager

Layout with containers

 (^) Containers (parent components) can control size/position of children  (^) example: rows & columns  (^) Two basic strategies  (^) Top-down (AKA outside-in)  (^) Bottom-up (AKA inside-out)

Top-down or outside-in layout

 (^) Parent determines layout of children  (^) Typically used for position , but sometimes size  (^) Example?

Bottom-up or inside-out layout

 (^) Children determine layout of parent  (^) Typically just size  (^) Example?

Bottom-up or inside-out layout

 (^) Children determine layout of parent  (^) Typically just size  (^) Shrink-wrap container  (^) parent just big enough to hold all children  (^) e.g., pack() method on JWindow and JFrame  (^) Resizes container to just big enough to accommodate contents’ preferredSizes

Neither one is sufficient

 (^) Need both  (^) May even need both in same object  (^) horizontal vs. vertical  (^) size vs. position (these interact!)  (^) Need more general strategies

Layout Policies in Swing

 (^) Swing layout policies are (generally) customizable  (^) Some containers come with a “built-in” layout policy  (^) JSplitPane, JScrollPane, JTabbedPane  (^) Others support “pluggable” policies through LayoutManagers  (^) LayoutManagers installed in Containers via setLayout()  (^) Two interfaces (from AWT): LayoutManager and LayoutManager  (^) Determines position and size of each component within a container  (^) Looks at components inside container:  (^) Uses getMinimumSize(), getPreferredSize(), getMaximumSize()  (^) ... but is free to ignore these  (^) Example LayoutManagers:  (^) FlowLayout, BorderLayout, GridLayout, BoxLayout, ...