DOC PREVIEW
UMD CMSC 433 - Graphical User Interfaces

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CMSC 433 – Programming LanguageTechnologies and ParadigmsSpring 2005Graphical User InterfacesApril 19, 20052(Incomplete) History of GUIs• 1973: Xerox Alto– 3-button mouse, bit-mapped display, windows• 1981: Xerox Star– Double-clicking, overlapping windows, dialogs• 1983: Apple Lisa– Pull-down menus and menu bars• 1984: Apple Macintosh, X Windows• 1985: Microsoft Windows(from http://toastytech.com/guis/guitimeline.html)3Why a GUI Toolkit/API?• Easier to build GUIs• Consistency of interface– Among applications– Between platforms (in Java)4GUI Basics• Interface consists of many components– Windows, menus, buttons• User can perform variety of operations– Move window– Click button– Press key• These are events25A Note on AWT versus Swing• Abstract Window Toolkit (AWT)– Original Java GUI– Still supported, but being replaced• Swing -- souped-up AWT– Pluggable look-and-feel– More, better widgets• AWT class X has corresp. Swing class JX– E.g. Button vs. JButton6Creating Components• Components are the usual widgets– JButton, JPopupMenu, JScrollBar– Components know how to draw themselves– But they (generally) don’t say where they are• In Swing, components live in containers– JFrame, JDialog, JApplet– Containers decide how to layout components– Various layout algorithms7Observer pattern8Programming with Events• Initialize objects– Create everything on the screen– Register your event handlers (observers)• Then toolkit takes over with event loopwhile (true) {e = getEvent(); findEventHandler(e).actionPerformed(e);}39Adding Observers (Listeners)• Components have a set of listeners– void addActionListener(ActionListener l)– void addKeyListener(KeyListener l)– void addMouseListener(MouseListener l)• Possible listeners vary with component10Listener Interfacespublic interface ActionListener { void actionPerformed(ActionEvent e);}public interface MouseInputListener { void mouseClicked(MouseEvent e); void mouseEntered(MouseEvent e); void mousePressed(MouseEvent e); ...}11Events• Event objects contain the detailed infopublic class MouseEvent { ... int getClickCount(); Point getPoint();}• Tradeoff between number of event classesand amount of info in each event12SwingApplication.java• (Optional) Step 1: Install look and feelpublic static void main(String[] args) { try { UIMananger.setLookAndFeel( UIManager.getCrossPlatformLookAndFeelClassName() ); } catch (Exception e) { } ...• Default is to use “native” look and feel413Step 2: Make the ComponentsJFrame frame = new JFrame(“SwingApplication”);SwingApplication app = new SwingApplication();Component contents = app.createComponents();frame.getContentPane().add(contents, BorderLayout.CENTER);• Frames are windows– ContentPane is the display area (w/o menu bar)• contents added to the frame– Layed out as BorderLayout.CENTER14Step 3: Install any Listenersframe.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); }});• WindowAdapter implements WindowListener– Contains default do-nothing methods• Notice we ignore the value of e15Step 4: Make Window Visible frame.pack(); frame.setVisible(true);}• pack() sizes window to fit subcomponents• setVisible(true) shows the window– Not drawn until this is set• main(String[] args) exits– Swing event thread handles events16Layout and Painting• Swing places components according tolayout manager– Don’t need to worry about screen size etc.– (Not really true)• Window painted from back to front– Component paints itself before subcomponents– Double-buffered so painting looks smooth517The Event-Dispatching Thread• All events are dispatched by a single thread– Implies events dispatched in order– Also implies next event not processed untilcurrent event dispatch returns• Need to make event dispatch fast– (Re)-painting also done in event-dispatchingthread• What if another thread needs to modify GUI?– Swing library mostly not thread safe18Single-Thread Rule“Once a Swing component has been realized, allcode that might affect or depend on the state ofthat component should be executed in theevent dispatching thread.”java.sun.com tutorial• A component is realized after– setVisible(true) ( == deprecated show())– pack()19Dealing with Threads• Wait a second, what about the example?f.pack(); // f is realized heref.setVisible(true); // so isn’t this unsafe?– Apparently this “usually” works, so it’s OK (?)• A few methods can be used from any thread• SwingUtilities.invokeLater(Runnable r)– Event-dispatching thread will invoke r– (after all pending events dealt with)20Making Event Dispatch Fast• Standard problem in event or interrupt-driven systems– Short tasks in response to events are fine• Divide long tasks into top half, bottom half– Top half is quick; typically, buffers– Bottom half runs in separate thread• Consumes data from buffer• Can use invokeLater() if it eventually updates GUI621UI Hall of Fame or Shame?22UI Hall of Shame• Application directory dialog (not system)– Inconsistent• Requires typing a path name– No browse option– What if you have many directories?• Instead, want recognition over recall23Tips• Don’t make the user look stupid• The goal of all software users is to be moreeffective24UI Hall of Fame or Shame?725UI Hall of Fame– MS Publisher– Modified file dialog– Recognition based• Browsable names• Browsable content• Preview can be turned off• Optional search• Design Suggestion:– Add entry box for directly typingin name with auto-completion offilenames26Tips• User interfaces that directly wrapunderlying systems are often


View Full Document

UMD CMSC 433 - Graphical User Interfaces

Documents in this Course
Trace 1

Trace 1

62 pages

Reflection

Reflection

137 pages

Testing

Testing

25 pages

Paradigms

Paradigms

10 pages

Testing

Testing

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Trace 1

Trace 1

46 pages

Jini

Jini

4 pages

Final

Final

15 pages

Java RMI

Java RMI

13 pages

Testing

Testing

16 pages

Load more
Download Graphical User Interfaces
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Graphical User Interfaces and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Graphical User Interfaces 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?