In this part of your lab, you will take your solution from Part A and construct a GUI to support your object's API.

Goals:

• Know how to use the Java beans PropertyChangeSupport to notify interested software components about other components' updates.
• Know how to write a simple, elegant GUI for an API.

Before starting:

• Make sure you're good with Part A
• Run the sample solution Note! This solution represents more than you need to do to get full credit for this lab. See below.

Helpful resources:

• PropertyChangeSupport ( JavaDoc )
• JLabel ( JavaDoc )
• Text Components ( JTextArea )
• JTextField ( JavaDoc )
• JScrollPane ( JavaDoc )
• Menu stuff
  • Menu Tutorial
  • Components
    • JMenuBar (see JFrame's setJMenuBar )
    • JMenu
    • JMenuItem
  • Getting things done from menu choices
    • How to add an ActionListener to a menu item
    • actionPerformed method, which we used in bad way in Lab 1. Now, you should override the method in an inner class, to handle the event. Do not funnel all events through the same ActionListener! I'll cover this in class.
• Getting input from the user
  • Dialogs for text
    • Tutorial
    • Using the static methods of JOptionPane : showInputDialog , to get a String from the user
  • Mouse listeners and adapters
    • MouseListener tutorial
    • Use an anonymous, inner class extension of MouseAdapter and override the method you want to receive the kind of mouse events you want.
    • You can add a mouse listener (adapter) to any Component using addMouseListener
    • You may or may not care about the details of a MouseEvent , such as left-click, right-click, etc.
• You can conbine both of the above so that menus pop-up in response to mouse clicks, see JPopupMenu

What to do.

• The classes you make for this part should be in the package kwic.gui. You'll have to make a gui subdirectory in the kwic directory and put the appropriate package directive at the top of your class files for the GUI.
• Decide the gestures you want a user to perform to interface with each public method of the KWIC API.

  The sample solution as provided is much more than you need to do to get credit for this lab. Your GUI must provide reasonable access to the API of KWIC. You need only provide one mechanism for each method. If you provide more, along the lines of the sample solutuion, you can earn extra credit.

• Complete your code, test it.

Notes:

• It is suggested that you keep your main method in the Demo file at the root of the directories for this project. You can then compile and run from that directory. Otherwise, if you put the main method in your GUI class, you'll have to change the CLASSPATH settings for EMACS to include "../../". Those settings are under

  JDE->Project->Options->
  

  and then under Compile and Run. From there, change the CLASSPATH and click on State and then save for future sessions.
• You may decide that you want the Words of your KWIC object to be returned (iterated) in sorted order. Here are some thoughts on that:
  • It's easy if you're willing to modify your KWIC and Word Objects as follows:
    • Change HashMap to TreeMap in your KWIC object. A TreeMap is a Map whose keys are maintained in sorted order.
    • Your Word object must implement the Comparable interface so that TreeMap can compare one Word against another to keep them sorted.

      How should Word implement that interface? Three words: delegate, delegate, delegate.

  • It may be unreasonable to proceed as described above, burdening KWIC with sorting the keys: not every application needs them sorted. By forcing KWIC to do this work, all uses of KWIC pay the price.

    Thus, it may be more reasonable for your GUI to arrange to have the Words sorted. You can do this by implementing the QuickSort described in CS101 . Alterntaively, you could create a TreeSet instance on our GUI side, put the Words into there, and then when you iterate over them they will be sorted.

• The constructor for your main GUI class should accept an instance of an already constructed KWIC object, which may already have information in it.
• You are encouraged to write a helper method so that the same code can load the display on instantiation as well as when things change. If you have a JFrame jf then here's how to create or recreate it:
  1. First, empty any contents from the JFrame by calling jf.getContentPane().removeAll() The menu bar and its contents are not affected by this method call, and they will stay the way you set them up when you constructed your JFrame.
  2. Next, create a new JPanel (say, code>mainPanel) that has everything you want displayed. Of course, this JPanel may have JPanels inside of it, and you can set the layout of each JPanel however you want. You are encouraged to make each JPanel fairly simple, and to use GridLayout and BorderLayout to control where things go.
  3. Add the main JPanel to your JFrame: jf.getContentPane().add(mainPanel).
  4. Force the JFrame to redraw itself: jf. validate().
  5. Make sure the JFrame is visible: jf.setVisible(true).
• Use inner, anonymous classes to associate actions with graphical components. For a JButton or JMenuItem j, each of which is an extension of AbstractButton , this is done as follows (spacing below to show grouping):

    j.addActionListener(
                         new ActionListener() {  // anonymous inner class
                                                 // implements ActionListener
                            public void actionPerformed(ActionEvent e) {
                              // Do what you want in response to 
                              //   this AbstractButton "push"
                              // Ideally, you should be able to ignore "e"
                              //   because this is the only button associated with
                              //   this anonymous action
                            }
                         }
                       );
  

• Use inner, anonymous classes to associate actions with mouse events. If you have a Container c, this can be done as follows:

    c.addMouseListener(
                         new MouseAdapter() {  // anonymous inner class
                                               // extends MouseAdapter
                            public void MouseClicked(MouseEvent e) {
                              // Do what you want in response to 
                              //   this mouse click
                              // Ideally, you should be able to ignore "e"
                              //   because this is the only button associated with
                              //   this anonymous action
                              //   But look at e if you care which button was
                              //   clicked, how many times, etc
                            }
                         }
                       );
  

• To track when things change in the KWIC object, your GUI class should register itself for propoerty change support with the PropertyChangeSupport object provided by KWIC.

  PropertyChangeSupport is like publish/subscribe or subject/observer. It is conventional for the object that is publishing or changing itself to own the PropertyChangeSupport object. Our KWIC object has an accessor to retrieve that object (let's suppose it's the instance var pcs) .

  Then, inside KWIC, when something changes, you can broadcast that fact to all interested parties (in this case, your GUI class), by

     pcs.firePropertyChange("Name of Thing", oldvalue, newvalue);
  

  The "Name of Thing" is the name of the property that other parties might listen for changes. For example, "Word Deleted" or "Phrase Delete". The other paramters are Object types that could reflect the change in value. You may or may not need actual values there; if nothing is needed, you can supply null

  If kwicPCS is the instance of the PropertyChangeSupport object, then your GUI (or other interested parties) advertize their interest by:

     kwicPCS.addPropertyChangeListener(
  
        "Name of Thing",
  
        new PropertyChangeListener() { // anonymous, inner class
                                       // implements PropertyChangeListener
           public void propertyChange(PropertyChangeEvent e) {
              // Deal with this event how you like
              // You can probalby ignore e
           }
        }
  
                                      );
  

What to turn in (after demo in your lab section)

• Printouts of all Java files in your kwic.gui package.
• Some screenshots of your GUI in action to show us how your gestures work.

  To do a screenshot, arrange the screen as you wish and then hit Print Scrn, which is shift of a button near the top of your keyboard typically. This copies the image into a buffer. Then, open the Paint program from Start->Programs->Accessories and paste the image into Paint's canvas. Then print that canvas as usual.

  Be sure to include screenshots of extra-credit features.