swingx
  1. swingx
  2. SWINGX-145

JXTable cells don't change orientation according to the tables orientation

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.9.0
    • Fix Version/s: 0.9.0
    • Component/s: Authentication
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      145

      Description

      In BiDi languages read from right to left the UI is converted to a mirror
      representation of the current UI. This is supported by AWT using the
      ComponentOrientation method.
      However, while the table gets assigned a component orientation, the cells do not
      change their orientation. This is easy to fix by adding this line:
      stamp.setComponentOrientation(getComponentOrientation());
      Into JXTable.java:

      public Component prepareRenderer(TableCellRenderer renderer, int row,
      int column) {
      // JW PENDING: testing cadavers ... check if still needed
      // Object value = getValueAt(row, column);
      // Class columnClass = getColumnClass(column);
      // boolean typeclash = !columnClass.isInstance(value);
      // TableColumn tableColumn = getColumnModel().getColumn(column);
      // getColumnClass(column);
      Component stamp = super.prepareRenderer(renderer, row, column);
      stamp.setComponentOrientation(getComponentOrientation());
      if (highlighters == null)

      { return stamp; // no need to decorate renderer with highlighters }

      else

      { // MUST ALWAYS ACCESS dataAdapter through accessor method!!! ComponentAdapter adapter = getComponentAdapter(); adapter.row = row; adapter.column = column; return highlighters.apply(stamp, adapter); }

      }

        Activity

        Hide
        vprise added a comment -

        My initial fix was to the ColumnHeaderRenderer as such, I ownly added a test for
        component orientation and moved that on to the component. However this didn't
        solve the sort Icon problem since it is implemented as a border... I tried
        fixing this and only got in deeper, technically there is a mistake in that code
        that relies on EAST/WEST rather than LEADING/TRAILING. But when I tried to fix
        that I caused other problems I'll keep trying.

        public Component getTableCellRendererComponent(JTable table, Object value,
        boolean isSelected, boolean hasFocus, int rowIndex, int columnIndex) {
        Component comp = configureDelegate(table, value, isSelected, hasFocus,
        rowIndex,
        columnIndex);

        if ((table instanceof JXTable) && (comp instanceof JComponent)) {
        // We no longer limit ourselves to a single "currently sorted
        // column"
        Sorter sorter = ((JXTable) table).getSorter(columnIndex);

        Border border = UIManager.getBorder("TableHeader.cellBorder");
        if (sorter != null)

        { iconBorder.setIcon(sorter.isAscending() ? upIcon : downIcon); Border origBorder = ((JComponent) comp).getBorder(); border = new CompoundBorder(origBorder, iconBorder); ((JComponent) comp).setBorder(border); }

        }
        if(comp.getComponentOrientation() != table.getComponentOrientation())

        { comp.setComponentOrientation(table.getComponentOrientation()); }

        return comp;
        }

        Show
        vprise added a comment - My initial fix was to the ColumnHeaderRenderer as such, I ownly added a test for component orientation and moved that on to the component. However this didn't solve the sort Icon problem since it is implemented as a border... I tried fixing this and only got in deeper, technically there is a mistake in that code that relies on EAST/WEST rather than LEADING/TRAILING. But when I tried to fix that I caused other problems I'll keep trying. public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int rowIndex, int columnIndex) { Component comp = configureDelegate(table, value, isSelected, hasFocus, rowIndex, columnIndex); if ((table instanceof JXTable) && (comp instanceof JComponent)) { // We no longer limit ourselves to a single "currently sorted // column" Sorter sorter = ((JXTable) table).getSorter(columnIndex); Border border = UIManager.getBorder("TableHeader.cellBorder"); if (sorter != null) { iconBorder.setIcon(sorter.isAscending() ? upIcon : downIcon); Border origBorder = ((JComponent) comp).getBorder(); border = new CompoundBorder(origBorder, iconBorder); ((JComponent) comp).setBorder(border); } } if(comp.getComponentOrientation() != table.getComponentOrientation()) { comp.setComponentOrientation(table.getComponentOrientation()); } return comp; }
        Hide
        vprise added a comment -

        Created an attachment (id=23)
        Fix for correct bidi alignment of the sort icon

        Show
        vprise added a comment - Created an attachment (id=23) Fix for correct bidi alignment of the sort icon
        Hide
        kleopatra added a comment -

        changed priority to p2

        fix must address editors as well?

        Show
        kleopatra added a comment - changed priority to p2 fix must address editors as well?
        Hide
        vprise added a comment -

        Good call, yes editors need to be fixed as well. Do you want me to submit a patch?

        Show
        vprise added a comment - Good call, yes editors need to be fixed as well. Do you want me to submit a patch?
        Hide
        kleopatra added a comment -

        Added support for adjusting CO of renderers/editors by default. That's done
        similar to the suggested patch in JXTable prepareRenderer/-Editor by calling
        adjustComponentOrientation(comp), which in turn calls applyCO on the given comp
        if apropriate. The related #150-swingx is solved along the same line
        (https://swingx.dev.java.net/issues/show_bug.cgi?id=150).

        Actually, I think it's a core swing issue in DefaultTableCellRenderer/(-Editor
        ?) which doesn't care about CO (as DefaultCellRenderer, DefaultTreeCellRenderer
        do). And maybe forcing the CO might not be the correct thing to do in all
        use-cases, different columns might represent different orientation (f.i. in
        translation apps).

        Anyway, I'll close this as fixed for now because there's not much else we can do
        in swingx to serve the majority of contexts (core swing should make the
        renderer/editor respect CO always, then we can remove the forced appliance in
        swingx and custom renderers can choose to deliberately not respect CO) The
        minority contexts have several options:

        • subclass JXTable and override adjustComponentOrientation to check a custom
          property
        • or use a highlighter which explicitely sets CO to whatever is needed
          (highlighters are called after forcing CO)

        Jeanette

        Show
        kleopatra added a comment - Added support for adjusting CO of renderers/editors by default. That's done similar to the suggested patch in JXTable prepareRenderer/-Editor by calling adjustComponentOrientation(comp), which in turn calls applyCO on the given comp if apropriate. The related #150-swingx is solved along the same line ( https://swingx.dev.java.net/issues/show_bug.cgi?id=150 ). Actually, I think it's a core swing issue in DefaultTableCellRenderer/(-Editor ?) which doesn't care about CO (as DefaultCellRenderer, DefaultTreeCellRenderer do). And maybe forcing the CO might not be the correct thing to do in all use-cases, different columns might represent different orientation (f.i. in translation apps). Anyway, I'll close this as fixed for now because there's not much else we can do in swingx to serve the majority of contexts (core swing should make the renderer/editor respect CO always, then we can remove the forced appliance in swingx and custom renderers can choose to deliberately not respect CO) The minority contexts have several options: subclass JXTable and override adjustComponentOrientation to check a custom property or use a highlighter which explicitely sets CO to whatever is needed (highlighters are called after forcing CO) Jeanette

          People

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

            Dates

            • Created:
              Updated:
              Resolved: