home *** CD-ROM | disk | FTP | other *** search
/ PC World 1998 October / PCWorld_1998-10_cd.bin / software / prehled / inprise / JHELP.Z / CHANGES.txt < prev    next >
Text File  |  1998-05-08  |  23KB  |  705 lines
  1.      
  2.           CHANGES SINCE THE PREVIOUS RELEASE
  3.  
  4. This file summarizes changes made since Swing 0.7.  Most bug fixes,
  5. javadoc improvements, and look-and-feel cosmetic changes are not listed
  6. here.
  7.  
  8. For the latest, detailed information about Swing, be sure to check our
  9. Web site, The Swing Connection:
  10.  
  11.     http://java.sun.com/products/jfc/swingdoc-current/
  12.  
  13.  
  14. ===================
  15. Swing API Stability
  16. ===================
  17.  
  18. This release contains some minor API changes, which are detailed
  19. in the sections below.  A few of these were incompatible with the
  20. Swing 0.7 API; see the "JComponent", "Action", "Keyboard Navigation",
  21. "UIManager", and "Event Package" sections.
  22.  
  23. As of Swing1.0 the entire API has been frozen less a few important
  24. exceptions: 
  25.  
  26. - The look and feel implementation classes in the swing.plaf and
  27. subpackages of swing.plaf have not been frozen.  To write
  28. a new look and feel one needs to extend the classes in the swing.plaf
  29. packages.  New applications and components that do so will
  30. need to upgrade when the final version of the look and feel
  31. classes is released.  We expect to do so when Swing ships
  32. with the final version of JDK1.2.
  33.  
  34. - The classes in the swing.preview package are not frozen.  The
  35. JColorChooser and JFileChooser classes will be revised for the next
  36. Swing release.  
  37.  
  38. - Serialized Swing 1.0 objects will not be compatible with
  39. future swing releases.  The current serialization support is appropriate 
  40. for short term storage or RMI between Swing1.0 applications.  It will
  41. not be possible to load serialized Swing1.0 objects with future releases
  42. of Swing.  The JDK1.2 release of Swing will be the compatibility
  43. baseline for the serialized form of Swing objects.
  44.  
  45.  
  46.  
  47. ==========
  48. JComponent
  49. ==========
  50.  
  51. Removed the get/setClientProperties() methods from the JComponent
  52. API.  The clientProperty (note: singular) property is now bound.
  53. That is, putClientProperty() fires PropertyChangeEvents.
  54.  
  55. Moved setOpaque() to JComponent.  JComponent.isOpaque() still
  56. returns false by default, as before.  JComponent subclasses that
  57. used to define setOpaque() and had made the default value of this
  58. property be true now rely on BasicXXXUI to call setOpaque(true) in
  59. installUI().
  60.  
  61.  
  62. =======
  63. JDialog
  64. =======
  65.  
  66. Support for Modality
  67. --------------------
  68. In prior releases of Swing, creating a modal JDialog resulted in a
  69. dialog where calls to show() would block but input was still active
  70. in other windows (hence these were not really AWT "modal"
  71. dialogs).  This swing "fake" modality in JDialog was implemented to
  72. get around an AWT 1.1 limitation where Windows cannot be parented
  73. directly from Dialogs.  (Hence, Swing components such as JPopupMenu
  74. and JComboBox that created Window objects would not be operable
  75. when placed inside real modal dialogs because input would be
  76. blocked to those "popup" Windows).
  77.  
  78. Unfortunately, not only did this JDialog workaround fail to truly
  79. block input to other windows (the real definition of "modal"), but
  80. this workaround also caused applet security exceptions since it
  81. required direct access to the system event queue.
  82.  
  83. For the above reasons, we have changed JDialog to use true AWT
  84. modality for the final release.  To get around the problem where
  85. swing components containing popups (JPopupMenu, JComboBox,
  86. JMenuBar) are inoperable in modal dialogs, we have constrained
  87. these components to ALWAYS use lightweight popup menus when placed
  88. inside modal dialogs.  This creates the following caveats:
  89.  
  90. 1. Modal dialogs containing swing popup components (JPopupMenu,
  91.    JComboBox, JMenuBar) should be large enough to display the
  92.    entire popup, else the popup may be clipped when shown, since
  93.    it is entirely lightweight.
  94.  
  95. 2. If you mix AWT heaveyweight components with swing popup
  96.    components (JPopupMenu, JComboBox, JMenuBar) within a modal
  97.    dialog, popups may be obscured when shown since the heavyweight
  98.    components will always be on top of the lightweight popups.
  99.  
  100. Note: These restrictions will be removed from the swing release
  101.       which ships with JDK1.2 because in AWT 1.2, Windows and
  102.       Dialogs can be created with Windows as owners (no longer
  103.       restricted to Frames). This means Swing's popup components
  104.       can create their popups with the modal Dialog as the parent,
  105.       which will ensure proper popup operation.
  106.  
  107. Additionally, we have removed the method from JDialog which
  108. implemented swing's 'fake' modality:
  109.  
  110.     protected void blockingShow()
  111.     
  112. Note: Due to a bug in the AWT, modal dialogs can ONLY be created by
  113.       passing "true" as the modal parameter in the constructor 
  114.       (setModal() will not work).
  115.  
  116.  
  117. =================
  118. RootPaneContainer
  119. =================
  120.  
  121. Added a RootPaneContainer interface.  JFrame, JDialog, JWindow,
  122. JApplet, and JInternalFrame implement this interface by delegating
  123. to getRootPane().  Also, we regularized checking and exception
  124. throwing in add() and setLayout() for all of these classes.  Note
  125. that checking is disabled by the constructor and updateUI().
  126.  
  127.  
  128. ===========
  129. JTabbedPane
  130. ===========
  131.  
  132. In response to overwelming demand, a number of features were added
  133. to the TabbedPane for this release:
  134.  
  135. o A "tabPlacement" property that allows placement of the tabs to be
  136.   on the TOP, LEFT, BOTTOM, or RIGHT of the content area:
  137.   
  138.       public JTabbedPane(int tabPlacement)
  139.       public void setTabPlacement(int tabPlacement)
  140.       public int getTabPlacement()
  141.   
  142. o The ability to set whether or not an individual tab is enabled
  143.   or disabled:
  144.   
  145.       public void setEnabledAt(int index, boolean enabled)
  146.       public boolean isEnabledAt(int index)
  147.       
  148. o The ability to set foreground/background color on individual tabs:
  149.  
  150.     public void setForegroundAt(int index, Color foreground)
  151.     public Color getForegroundAt(int index)
  152.     public void setBackgroundAt(int index, Color foreground)
  153.     public Color getBackgroundAt(int index)
  154.     
  155. o The ability to get the current bounds of a particular tab:
  156.  
  157.     public Rectangle getBoundsAt(int index)
  158.     
  159. o The ability to get the current number of tab runs being displayed
  160.   in the TabbedPane:
  161.   
  162.       public int getTabRunCount()
  163.       
  164.  
  165. =======
  166. JButton
  167. =======
  168.  
  169. Added a "defaultButton" property.  L&Fs that care to will render
  170. default buttons differently.
  171.  
  172.  
  173. =======
  174. Borders
  175. =======
  176.  
  177. MatteBorder: added dynamic insets based on image
  178. EtchedBorder: added raised/lowered styles
  179.  
  180.  
  181. ============================================
  182. JTable and Associated Classes
  183. ============================================
  184.  
  185. The following policies resulted in changes to the JTable and its
  186. associated classes. The changes are very minor compared to the
  187. complete overhaul that the JTable API went through between 0.6.1
  188. and 0.7 and are mainly modifications that enable the new
  189. keyboard navigation facilities to work consistently in all of
  190. the JTable's selection modes.
  191.  
  192. #1. Remove the DefaultCellRenderer and replace it 
  193.     with a subclass of JLabel that just renders 
  194.     Strings and Icons. This makes sublcassing 
  195.     the new DefaultTableCellRenderer easier for common 
  196.     cases, like having differerent colored cells on 
  197.     different rows. It also brings it more in 
  198.     line (though not enough) with the renderers 
  199.     of the JList and JTree. Make this new default 
  200.     renderer indicate focus. [The old implementation 
  201.     DefaultCellRenderer has been moved to the 
  202.     pending area as a porting aid]. 
  203. #2. Encourage all renderers to indicate focus. This 
  204.     aligns the TableCellRenderer interface with 
  205.     the ListCellRenderer and TreeCellRenderer 
  206.     interfaces. 
  207. #3. Remove all transient state from UI in preparation 
  208.     for expansion of keyboard navigation facilities. 
  209.     Use the anchors in the selection models as the 
  210.     state required in keyboard navigation. 
  211. #4. Keep setShowGrid() but add independent controls 
  212.     for the drawing of horizontal and vertical lines. 
  213. #5. Remove the selection mode that dynamically 
  214.     switched between row and column based modes. 
  215.     This means that the anchors of the selection 
  216.     models can be used for keyboard navigation. 
  217.     This leads to a stateless UI (for #3) and 
  218.     a unified approach for handling mouse and keyboard 
  219.     events in the UI. 
  220. #6. In "getSelectedRow()" and "getSelectedColumn()", 
  221.     return the anchor rather than the lead from the 
  222.     selection models. 
  223.  
  224. Swing and Table Packages
  225. ------------------------
  226. DELETE (#1)
  227.  
  228. swing.DefaultCellRenderer
  229.  
  230. ADD (#1)
  231.  
  232. swing.table.DefaultTableCellRenderer
  233.  
  234.  
  235. TableCellRenderer
  236. -----------------
  237. CHANGE (#2)
  238.  
  239. FROM:
  240.     Component getTableCellRendererComponent(JTable table, Object value,
  241.                         boolean isSelected, 
  242.                         int row, int column);
  243.  
  244. TO:
  245.     Component getTableCellRendererComponent(JTable table, Object value,
  246.                         boolean isSelected, 
  247.                         boolean hasFocus, 
  248.                         int row, int column);
  249.  
  250.  
  251. BasicTableUI
  252. ------------
  253. Change all methods that can be overridden indirectly 
  254. from protected to private for backward compatible 
  255. performance tuning in subsequent releases. 
  256.  
  257. CHANGE (typo)
  258.  
  259. FROM:
  260.     public    void drawRowInClipRect(int row, Rectangle rect, 
  261.                      Graphics g) 
  262. TO:
  263.     protected void drawRowInClipRect(int row, Rectangle rect, 
  264.                      Graphics g) 
  265.  
  266. DELETE (#3)
  267.  
  268.     transient protected boolean hasPress;
  269.     transient protected int hitRowIndex;
  270.     transient protected int hitColumnIndex;
  271.     transient protected TableColumn hitColumn;
  272.  
  273.     transient protected boolean controlKeyDown;
  274.     transient protected boolean isSelecting;
  275.     transient protected int anchorRowIndex;
  276.     transient protected int anchorColumnIndex;
  277.  
  278. JTable
  279. ------
  280. CHANGED (typo)
  281.  
  282. FROM:
  283.     protected void createDefaultRenders() 
  284.  
  285. TO:
  286.     protected void createDefaultRenderers() 
  287.  
  288.  
  289. CHANGED (#4)
  290.  
  291. FROM:
  292.     protected boolean        showGrid;
  293.  
  294. TO:
  295.     protected boolean        showHorizontalLines;
  296.     protected boolean        showVerticalLines;
  297.  
  298.  
  299. DELETE
  300.     public boolean getShowGrid() 
  301.  
  302. ADD
  303.     public void    setShowHorizontalLines(boolean b) 
  304.     public boolean getShowHorizontalLines() 
  305.  
  306.     public void    setShowVerticalLines(boolean b) 
  307.     public boolean getShowVerticalLines() 
  308.  
  309. CHANGE (misname)
  310.  
  311. FROM:
  312.     public int editingRow() 
  313.     public int editingColumn() 
  314.  
  315.  
  316. TO:
  317.     public int getEditingRow() 
  318.     public int getEditingColumn() 
  319.  
  320. DELETE (#5)
  321.     protected boolean           isRowSelected
  322.  
  323. Changed (implementations) (#6). 
  324.  
  325.     public int getSelectedRow() 
  326.     public int getSelectedColumn()
  327.  
  328.  
  329. ==========================
  330. Java Look and Feel - Metal
  331. ==========================
  332.  
  333. Based on developer and user feedback, we have decided to make
  334. the Metal look and feel the default cross-platform look and feel
  335. in Swing.  Organic L&F, previously a part of the Swing release,
  336. will now be available separately.  For more information on the
  337. new Metal L&F and on how to get Organic, please visit the Swing
  338. Connection web site:
  339.  
  340.     http://java.sun.com/products/jfc/swingdoc-current/
  341.  
  342. The Metal classes are in swing.jar, rather than being in a
  343. separate jar file.
  344.  
  345. Metal-Specific UI Client Properties
  346. -----------------------------------
  347. Swing supports setting client properties on components which can be
  348. used by their corresponding UI objects to display an alternate form
  349. of the component.  If a property is not supported by a look and
  350. feel, it will simply be ignored and the component displayed as
  351. usual.
  352.  
  353. In Metal, the components that currently support properties include:
  354.  
  355. JSlider
  356.  
  357. Normal (default):
  358.     mySlider.putClientProperty( "JSlider.isFilled", Boolean.FALSE );
  359. Filled:
  360.     mySlider.putClientProperty( "JSlider.isFilled", Boolean.TRUE );
  361.  
  362. JToolBar
  363.  
  364. Normal (default):
  365.     myToolBar.putClientProperty( "JToolBar.isRollover", Boolean.FALSE );
  366.     
  367. Rollover Buttons (All regular buttons in the toolbar):
  368.     myToolBar.putClientProperty( "JToolBar.isRollover", Boolean.TRUE );
  369.  
  370. JTree
  371.  
  372. No Lines:
  373.     myTree.putClientProperty("JTree.lineStyle", "None");
  374.  
  375. Angled Lines from Parent to Child:
  376.     myTree.putClientProperty("JTree.lineStyle", "Angled");
  377.  
  378. Horizontal Lines between Root Nodes (default):
  379.     myTree.putClientProperty("JTree.lineStyle", "Horizontal");
  380.  
  381. Metal Internal Frame UI
  382. -----------------------
  383. To set the color of the 'notch' in the upper right corner underneath
  384. the title bar:
  385.  
  386.     myInternalFrame.getContentPane().setBackground(fillColor);
  387.  
  388. To add a JScrollPane to an internal frame, do not add it to the
  389. existing content pane, use setContentPane() instead.
  390.  
  391. Metal Themes
  392. ------------
  393. Themes provide an easy way to change certain parts of a look and
  394. feel, such as colors and fonts, without creating a whole new
  395. look and feel.  Currently Metal and Organic support themes.
  396. Swing 1.0 includes a demo called Metalworks that demonstrates
  397. how to create your own custom themes.
  398.  
  399.  
  400. ===================
  401. The Text Components
  402. ===================
  403.   
  404. Major rework of the way formatting of styled text is done.  The
  405. most significant difference is that now weights are used to
  406. determine best break positions.  The user-level effect is that now
  407. breaks will occur on whitespace boundries unless no whitespace
  408. can be found; also, forced breaks are now handled.
  409.  
  410. An additional benefit of this change is that views are reused
  411. and formatting no longer involves the view factory.  This can
  412. improve performace substantially in some cases, and makes it
  413. much easier to write non-breaking views that will be contained
  414. in a container that breaks (e.g. ParagraphView).
  415.  
  416. Added line-wrap support to JTextArea and fixed StyleContext deadlock
  417. problem.
  418.  
  419. Styled text tab handling integration.  This adds support for
  420. RTF-style tab handling. 
  421.  
  422. Removed a couple of methods on JTextPane that were implemented to 
  423. throw an error; improved the javadoc a little. 
  424.  
  425.  
  426. ===================
  427. Keyboard Navigation
  428. ===================
  429.  
  430. Changed getKeyAccelerator/setKeyAccelerator to getMnemonic/setMnemonic
  431. respectively.
  432.  
  433. Added setAccelerator().
  434.  
  435.  
  436. ======
  437. JLabel
  438. ======
  439.  
  440. Renamed displayedKeyAccelerator to displayedMnemonic.
  441.  
  442. The labelFor property is now bound to the displayedMnemonic property.
  443. As a result, if the keyboard accelerator associated with the
  444. displayedMnemonic property is typed, the JLabel instance attempts
  445. to give keyboard focus to the Component identified by the labelFor
  446. property.
  447.  
  448.  
  449. =======
  450. JSlider 
  451. =======
  452.  
  453. Changed the default slider behavior to snap-to-ticks.
  454.  
  455.  
  456. ======
  457. Action
  458. ======
  459.  
  460. In this release, get/setText and get/setIcon were collapsed into
  461. one pair of methods, get/setValue.  This was done to alleviate
  462. complaints that Actions were less flexible than they could be.
  463. It is now easier to use the existing Action interface with
  464. attributes of types other than String or Icon, instead of having
  465. to extend the interface.  It should be noted that the key/value
  466. pairs for all Action attributes are now in the same name space,
  467. which means that while it was previously possible to have both
  468. text and icon with the same key, these now clash.
  469.  
  470. ===================
  471. AbstractAction.java
  472. ===================
  473.  
  474. In this release, the key/value lookup has been implemented so
  475. that it now works to have more than one text or icon attribute
  476. (subject to the above).  It should be noted that the current
  477. implementation with a HashTable will be replaced with a more
  478. lightweight version in the next release.  (This will not affect
  479. the API.)
  480.  
  481. The current implementation is out of line with the spec in than
  482. getValue can currently return null.  Remember to test the values
  483. returned by Action.getValue before using them!
  484.  
  485.  
  486. =====
  487. Menus
  488. =====
  489.  
  490. There have been several fixes to Menu bugs for this release.  In 
  491. addition, there have been some small changes to the APIs.
  492.  
  493. Accelerators and Mnemonics
  494. --------------------------
  495. The get/setKeyAccelerator methods have been replaced with
  496. get/setMnemonic and get/setAccelerator.  Mnemonics are used to
  497. choose menu items when navigating the menu hierarchy with the
  498. keyboard.  Accelerators (hot-keys) are used to invoke a menu
  499. item's actionListeners without needing to traverse the menu
  500. items with the keyboard; the menu is never brought up, but the
  501. actionListeners for the menu item are invoked.
  502.  
  503.  
  504. Bugs Fixed
  505. ----------
  506. 1. Heavyweight menus now popup the first time on Solaris.  This
  507.    is for the most part fixed, although certain timing issues
  508.    can still lead to its happening.
  509. 2. Events over non-MenuItems on lightweight PopupMenus no longer get
  510.    dispatched to the underlying components.  
  511. 3. Recycling heavyweight PopupMenus no longer causes problems if
  512.    you use multiple JFrames.  
  513. 4. BasicMenuMouse* listeners are now Serializable.
  514.  
  515. Remaining Known Bugs
  516. --------------------
  517. 1. Lightweight menus get clipped by heavyweight components in
  518.    the invoking frame. This is because of the known restrictions
  519.    on mixing heavyweight and lightweight components in the AWT.
  520.    It is now easier to work around this, if you need to mix
  521.    heavyweight and lightweight components, by calling
  522.    JPopupMenu.setDefaultLightWeightPopupEnabled(false).
  523.  
  524. 2. On Solaris, placement and selection of lightweight
  525.    JPopupMenus may be wrong after resizing the invoking Frame to
  526.    the top and/or left.
  527.  
  528. 3. JPopupMenus in JApplets may display the Warning--Applet tag.
  529.  
  530.  
  531. ==========
  532. JPopupMenu
  533. ==========
  534.  
  535. The following API changes have been made to JPopupMenu:
  536.  
  537. 1. The constructor which takes an invoker has been removed,
  538.    because too many people thought that this would automatically
  539.    make the popup menu come up when the popup trigger was
  540.    pressed over the invoker.  You should replace calls to this
  541.    constructor with a call to one of the other constructors, and
  542.    then call setInvoker().
  543.  
  544. 2. Certain methods intended only for internal use in the Menu
  545.    implementation have been made private or package private.
  546.    These are:  isPopupMenu(), getRootPopupMenu().
  547.  
  548.  
  549. =================
  550. JCheckBoxMenuItem
  551. =================
  552.  
  553. The get/setAction() method has been removed to be consistent
  554. with other AbstractButton subclasses.
  555.  
  556.  
  557. ========
  558. JToolBar
  559. ========
  560.  
  561. In this release, we added is/setFloatable to the JToolBar API.
  562. Also, the drag-out code listens only for mouse dragged rather
  563. than mouse pressed, so that it is easier to avoid accidental
  564. drag-out.  The code for dragging has been tuned so that the
  565. performance is significantly better on Unix, and somewhat better
  566. on Windows.
  567.  
  568.  
  569. =============
  570. Accessibility
  571. =============
  572.  
  573. The AccessibleTable.java and AccessibleLayout.java interfaces
  574. are pending and we welcome your comments.  Please send your
  575. comments on these interfaces to access@sun.com.
  576.  
  577. The following properties are now defined in AccessibleContext:
  578.  
  579. ACCESSIBLE_NAME_PROPERTY, ACCESSIBLE_DESCRIPTION_PROPERTY,
  580. ACCESSIBLE_STATE_PROPERTY, ACCESSIBLE_VALUE_PROPERTY,
  581. ACCESSIBLE_SELECTION_PROPERTY, ACCESSIBLE_TEXT_PROPERTY,
  582. ACCESSIBLE_VISIBLE_DATA_PROPERTY
  583.  
  584. The following properties are now defined in AccessibleText:
  585.  
  586. ACCESSIBLE_TEXT_CONTENTS_PROPERTY, ACCESSIBLE_TEXT_CARET_PROPERTY
  587.  
  588.  
  589. Property change events for the following properties are now
  590. fired to listeners of the AccessibleContext associated with the
  591. following Swing Components:
  592.  
  593. AbstractButton: ACCESSIBLE_VISIBLE_DATA_PROPERTY, ACCESSIBLE_STATE_PROPERTY
  594.  
  595. JComponent: ACCESSIBLE_STATE_PROPERTY
  596.  
  597. JLabel: ACCESSIBLE_VISIBLE_DATA_PROPERTY
  598.  
  599. JList: ACCESSIBLE_VISIBLE_DATA_PROPERTY, ACCESSIBLE_SELECTION_PROPERTY,
  600.        ACCESSIBLE_STATE_PROPERTY
  601.   
  602. JPopupMenu: ACCESSIBLE_VISIBLE_DATA_PROPERTY
  603.  
  604. JProgressBar: ACCESSIBLE_VISIBLE_DATA_PROPERTY, ACCESSIBLE_STATE_PROPERTY
  605.  
  606. JScrollBar: ACCESSIBLE_STATE_PROPERTY, ACCESSIBLE_VALUE_PROPERTY
  607.  
  608. JSlider: ACCESSIBLE_STATE_PROPERTY, ACCESSIBLE_VALUE_PROPERTY
  609.  
  610. JTabbedPane: ACCESSIBLE_STATE_PROPERTY, ACCESSIBLE_SELECTION_PROPERTY,
  611.              ACCESSIBLE_VISIBLE_DATA_PROPERTY
  612.  
  613. JTree: ACCESSIBLE_STATE_PROPERTY, ACCESSIBLE_SELECTION_PROPERTY,
  614.        ACCESSIBLE_VISIBLE_DATA_PROPERTY
  615.  
  616. JTextComponent: ACCESSIBLE_SELECTION_PROPERTY, 
  617.                 ACCESSIBLE_TEXT_CARET_PROPERTY, 
  618.                 ACCESSIBLE_TEXT_CONTENTS_PROPERTY
  619.  
  620. In addition, AccessibleContext will fire property change events
  621. for these properties:  ACCESSIBLE_NAME_PROPERTY,
  622. ACCESSIBLE_DESCRIPTION_PROPERTY.
  623.  
  624.  
  625. =========
  626. UIManager
  627. =========
  628.  
  629. Setting the L&F
  630. ---------------
  631.  
  632. The default look and feel has been changed.  It is now the 
  633. cross platform "metal" look and feel, previously it was
  634. the system look and feel - e.g. motif on Solaris.
  635. To restore the original behavior put the following statement
  636. at the beginning of your app:
  637.  
  638.    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
  639.  
  640. The getSystemLookAndFeelClassName() method returns the
  641. name of the motif or windows LookAndFeel subclass, depending
  642. on the platform.
  643.  
  644.  
  645. Swing Properties
  646. ----------------
  647. Renamed the swing properties file (defined in UIManager.java)
  648. from "uimanager.properties" to "swing.properties".  Renamed all
  649. of the properties in this file to be consistent with the other
  650. JDK lib/*.properties files:
  651.  
  652. DefaultLookAndFeel => swing.defaultlaf 
  653. AuxiliaryLookAndFeels => swing.auxiliarylaf 
  654. MultiplexingLookAndFeel => swing.multiplexinglaf
  655.  
  656. Added a new property called "swing.installedlafs" whose value
  657. must be a comma-separated list of L&F names.  Used like this:
  658.  
  659. swing.installedlafs=motif,windows
  660.  
  661. swing.installedlaf.motif.name=CDE/Motif
  662. swing.installedlaf.motif.class=com.sun.java.swing.plaf.motif.MotifLookAndFeel
  663.  
  664. swing.installedlaf.windows.name=Windows
  665. swing.installedlaf.windows.class=com.sun.java.swing.plaf.windows.WindowsLookAndFeel
  666.  
  667. Installed L&Fs
  668. --------------
  669. Restored some of the support for keeping track of a list of
  670. installed look and feels in UIManager.  A look and feel is
  671. "installed" if it appears in the
  672. <java.home>/lib/swing.properties file.  The format of this file
  673. needs to be added to the UIManager class javadoc.  The new
  674. UIManager methods are:
  675.  
  676. public static LookAndFeelInfo[] getInstalledLookAndFeels();
  677. public static void setInstalledLookAndFeels(LookAndFeelInfo[]
  678. infos); public static void installLookAndFeel(LookAndFeelInfo
  679. info); public static void installLookAndFeel(String name, String
  680. className);
  681.  
  682. Currently these methods do not rewrite the swing.properties
  683. file.
  684.  
  685. There's also a new class, UIManager.LookAndFeelInfo, that's
  686. little more than a glorified name,className struct for
  687. LookAndFeels.
  688.  
  689.  
  690. ==============================
  691. JFileChooser and JColorChooser
  692. ==============================
  693.  
  694. JFileChooser and JColorChooser and their supporting files were
  695. moved into the swing.preview package.  Their APIs are not frozen,
  696. but they may be used on an as-is, subject-to-change basic.
  697.  
  698.  
  699. =============
  700. Event Package
  701. =============
  702.  
  703. Some event files that used to live outside of swing.event were
  704. moved into swing.event.
  705.