Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1260924

semantics of minimumSize() and layout() not right

XMLWordPrintable

    • generic, sparc
    • generic, solaris_2.5

      For me, when components are laid out (say by a layout manager), there are three different component "sizes" that are of interest. First, there's the "actual size". This is one of the things that the layout manager determines. Second, there's the "user's preferred minimum size" (where "user" means the programmer attempting to use awt), which is the minimum size that the user wants the component to have in the layout. Third, there's the "physical minimum size", which is determined by the implementation of the component in the windowing system. Note that there may be more than one physical minimum size depending on the varying characteristics of the component (such as the label of a button, or the number of lines in a text widget). The physical minimum size is primarily of interest to the user--the user uses it to help determine the user's preferred minimum size--though if the user doesn't have a preferred minimum size, the layout should be determined by the physical minimum size.

      awt doesn't have a concept of "user's preferred minimum size", though the actual size sometimes reflects the user's preferred minimum size. The minimumSize() function returns either the physical minimum size (often using arbitrary characteristics) or the actual size. Which it returns varies depending on many arbitrary factors, such as whether a component's peer has been created yet, and which component type it is, and what the implementation of the peer is. Thus the semantics of these things are confused in awt. This needs to be fixed.

      In addition, I feel that it is very important that the concept of "user's preferred minimum size" be implemented. The class Component should have a "setMinimumSize()" function that allows the user to set a component's minimum size in pixels. The "minimumSize()" function should then return the user-set minimum size, or the physical minimum size given a preferred set of characteristics if the user has not set a minimum size. Every component should have a set of "calculateMinimumSize()" functions that would return the physical minimum size given a set of characteristics. For example, characteristics for a TextArea that could be used to calculate a physical minimum size would include the number of lines, the contents of those lines, and the font. In addition, some components should have variants of "setMinimumSize()" that set characteristics that determine the user's preferred minimum size. For example, TextArea should have a variant of "setMinimumSize()" in which the number of lines is specified; it would remember this number, and if the user doesn't specify a minimum size in pixels using the basic form of "setMinimumSize()", every time "minimumSize()" was called it would determine the preferred minimum size by calculating the physical minimum size using that number of lines.

      For all size-related functions, the documentation should specify the following: where the information comes from; whether the information is in whole or in part determined by the user; and how the information is used. For the functions described above:
      calculateMinimumSize(): information comes from the implementation of the component in the windowing system; it is not user-configurable except in the parameters supplied to calculateMinimumSize(); and the information is used by the user in determining a preferred minimum size or, if no such size has been set with setMinimumSize(), in determining the actual size when doing a layout.
      setMinimumSize() (pixel version): information comes from the user, perhaps using information returned by calculateMinimumSize; determines the size returned by minimumSize(), which is used when doing a layout.
      setMinimumSize() (component-specific version): information comes from the user; is only used if no preferred minimum size in pixels has been set with setMinimumSize; gives parameter(s) to calculateMinimumSize() used in calculating the preferred minimum size when minimumSize() is called, which is used when doing a layout.
      minimumSize(): returns the user's preferred minimum size; this is determined by: first, if setMinimumSize() (pixel version) has been called, by the size specified by that; second, if setMinimumSize() (component-specific version) has been called, the information set in that call is used to calculate the size; third, the size is calculated using calculateMinimumSize() with some set of default parameters. Usually this is only called by a layout manager.
      layout(): lays out components using their user preferred minimum sizes returned by minimumSize(); this information can be set using setMinimumSize(); the information is used in determining the actual size, which is then set with the resize() and reshape() functions.
      resize() and reshape(): sets the actual size of a component; usually only called by a layout manager; affects nothing except the actual size of a component; could be overridden by the layout manager at any time by subsequent calls to resize() or reshape().

      awt currently has two functions, preferredSize() and minimumSize(), that behave practically identically. I feel that preferredSize() should be abolished (or its semantics and implementation changed to do something useful).

            prssunw Prs Prs (Inactive)
            duke J. Duke
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: