swingx
  1. swingx
  2. SWINGX-1163

LayoutPainter: missing api to adjust to ComponentOrientation

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.6
    • Fix Version/s: None
    • Component/s: Painter
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      split off from Issue 157 (JXTitledPanel not completely bidi-compliant)

      The part that's still open is the background gradient (if set). As the title
      area is a JXPanel and the JXPanel is supposed to do background gradient (or any
      other, could be an image as well) painting by way of a Painter, the issue boils
      down to supporting CO-aware painters. The panel itself can't (IMO) as it doesn't
      know anything about the type of the painter (wouldn't want to mirror an image,
      f.i., while doing so for a horizontal gradient is the thing to do).

      AbstractLayoutPainter has enums for defining Alignments which aren't strong
      enough: they are fixed left/right, top/bottom. Need to enhance with
      leading/trailing (or startOfLine, endOfLine),
      what's-the-equivalent-for-vertical? See BorderLayout.

      I think this is a defect (not an enhancement) as CO compliance is considered
      important in SwingX

      Cheers
      Jeanette

        Issue Links

          Activity

          Hide
          Karl Schaefer added a comment -

          There is no way for the Painters to do something appropriate in all cases. It
          is not the correct location. The component in question must reinitialize the
          painter with the correct gradient when the orientation changes.

          I could see us adding a specialized compound painter that checks the component
          orientation before delegating the the correct child; the others left
          unpainted. However, auto-orientation is right out.

          Marking won't fix. It is up to the component to handle the painter
          initialization.

          Show
          Karl Schaefer added a comment - There is no way for the Painters to do something appropriate in all cases. It is not the correct location. The component in question must reinitialize the painter with the correct gradient when the orientation changes. I could see us adding a specialized compound painter that checks the component orientation before delegating the the correct child; the others left unpainted. However, auto-orientation is right out. Marking won't fix. It is up to the component to handle the painter initialization.
          Hide
          kleopatra added a comment -

          Karl,

          "There is no way for the Painters to do something appropriate in all cases" -
          ack, but same holds for any of the layout hints, f.i. left/right aligned stars
          or something. Gradients are just particularly nasty because they are so utterly
          low-level.

          The point is that the painter api is inconsistent:
          either we support "layout" then we must do it completely, support both absolute
          (left/right) and relative (leading/trailing) positioning
          or we admit defeat and drop layout support altogether

          CU
          Jeanette

          Show
          kleopatra added a comment - Karl, "There is no way for the Painters to do something appropriate in all cases" - ack, but same holds for any of the layout hints, f.i. left/right aligned stars or something. Gradients are just particularly nasty because they are so utterly low-level. The point is that the painter api is inconsistent: either we support "layout" then we must do it completely, support both absolute (left/right) and relative (leading/trailing) positioning or we admit defeat and drop layout support altogether CU Jeanette
          Hide
          Karl Schaefer added a comment -

          The Painter API is low-level, not high-level. The reason that the layout
          painter uses only static layout types is because there is no way to do dynamic
          types. That is not a shortcoming of the Painter API, but a strength.

          It is the responsibility of higher-level APIs to do the right thing with
          respect to relative layouts. The alignment constants in AbstractLayoutPainter
          are shorthand for positioning the contents in some fix way. Higher-level APIs
          that handle relative orientations can alter the low-level API as required. In
          some cases, that might mean passing an AffineTransform with a -1 scale to
          invert the painting or switching the horizontal alignment from left to right.

          Since, you seem to have a strong opinion that something is missing; give me an
          idea on how we solve this problem in a generic way.

          Show
          Karl Schaefer added a comment - The Painter API is low-level, not high-level. The reason that the layout painter uses only static layout types is because there is no way to do dynamic types. That is not a shortcoming of the Painter API, but a strength. It is the responsibility of higher-level APIs to do the right thing with respect to relative layouts. The alignment constants in AbstractLayoutPainter are shorthand for positioning the contents in some fix way. Higher-level APIs that handle relative orientations can alter the low-level API as required. In some cases, that might mean passing an AffineTransform with a -1 scale to invert the painting or switching the horizontal alignment from left to right. Since, you seem to have a strong opinion that something is missing; give me an idea on how we solve this problem in a generic way.
          Hide
          kleopatra added a comment -

          Karl,

          actually I don't see where you expect a problem - so could well be I'm missing something.
          Here is what I want:

          /**

          • An enum which controls horizontalAlignment alignment
            */
            public static enum HorizontalAlignment { LEFT, CENTER, RIGHT, TRAILING, LEADING }

          Then simply respect the trailing/leading if painting on a J/Component, otherwise treat
          them the same as the absolute left/right.

          That would need one or two additional methods to check for absolute positioning and use
          that when calculating the x/y. Or add the target object to paint on as parameter in calculateLayout.

          CU
          Jeanette

          Show
          kleopatra added a comment - Karl, actually I don't see where you expect a problem - so could well be I'm missing something. Here is what I want: /** An enum which controls horizontalAlignment alignment */ public static enum HorizontalAlignment { LEFT, CENTER, RIGHT, TRAILING, LEADING } Then simply respect the trailing/leading if painting on a J/Component, otherwise treat them the same as the absolute left/right. That would need one or two additional methods to check for absolute positioning and use that when calculating the x/y. Or add the target object to paint on as parameter in calculateLayout. CU Jeanette
          Hide
          Karl Schaefer added a comment -

          It feels more broken to have partially-supported relative constants than to not
          have them at all. If we can come up with a more general way to make relative
          constants work regardless of the object type, then I'm all for it.

          Show
          Karl Schaefer added a comment - It feels more broken to have partially-supported relative constants than to not have them at all. If we can come up with a more general way to make relative constants work regardless of the object type, then I'm all for it.
          Hide
          kleopatra added a comment -

          well, this type of "brokeness" holds for several of the concrete painter implementations
          (they type-check for JComponent Anyway, I think that the whole stack of the Painter
          hierarchy is severly broken. So add a bit more doesn't matter so much.

          See your point but still disagree (surprise, surprise <g>)

          CU
          Jeanette

          Show
          kleopatra added a comment - well, this type of "brokeness" holds for several of the concrete painter implementations (they type-check for JComponent Anyway, I think that the whole stack of the Painter hierarchy is severly broken. So add a bit more doesn't matter so much. See your point but still disagree (surprise, surprise <g>) CU Jeanette
          Hide
          Karl Schaefer added a comment -

          Perhaps your final comment is better addressed in the forums, but what is the
          problem that you have with the Painter stack?

          Show
          Karl Schaefer added a comment - Perhaps your final comment is better addressed in the forums, but what is the problem that you have with the Painter stack?
          Hide
          kleopatra added a comment -

          nasty me could say: search the forum for the abandoned painter api review <g>
          Not sure, though, if we ever got as far as the hierarchy ... so simply look at
          what which level adds in functionality and how/often/completely subclasses
          service super's contract. Last time I looked most didn't. Aware that you did
          some cleanup recently, didn't check what exactly

          CU tomorrow (hungry like a wolf now
          Jeanette

          Show
          kleopatra added a comment - nasty me could say: search the forum for the abandoned painter api review <g> Not sure, though, if we ever got as far as the hierarchy ... so simply look at what which level adds in functionality and how/often/completely subclasses service super's contract. Last time I looked most didn't. Aware that you did some cleanup recently, didn't check what exactly CU tomorrow (hungry like a wolf now Jeanette
          Hide
          Karl Schaefer added a comment -

          After thinking about this, we can do relative constants if we add a sense of
          locale to the layout painter. ComponentOrientation provides a lookup by
          locale. I think Issue 1346 will need to ensure properly handle this type of
          use-case.

          Show
          Karl Schaefer added a comment - After thinking about this, we can do relative constants if we add a sense of locale to the layout painter. ComponentOrientation provides a lookup by locale. I think Issue 1346 will need to ensure properly handle this type of use-case.

            People

            • Assignee:
              rah003
              Reporter:
              kleopatra
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: