JDK-5102490 : Lead Selection index is not shown in JFileChooser on GTK LAF
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_3.0
  • CPU: x86
  • Submitted: 2004-09-15
  • Updated: 2006-11-06
  • Resolved: 2005-03-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6
5.0u3Fixed 5.0u4Fixed 6 b28Fixed
Description
Lead Selection index is not shown in JFileChosser on GTK LAF. 
Steps to reproduce:
-------------------
1) Open SwingSet2 demo on Linux or JDS. 
2) Change the look and feel to GTK. 
3) Goto JFileChooser demo and click show plain FileChooser. 
4) Notice that the focus is in the TextField. 
5) Press Shift+Tab. The Focus is in File List. But you cannot see. 
6) To confirm that the focus is in FileList panel, press down arrow key. you will notice  that the second file is chossen. (If there is any). 
This was observed in Mustang PIt of 14th Sept with the following version:

java version "swing-jcg-linux-02-2004-09-13-int.mustang"
Java(TM) 2 Runtime Environment, Standard Edition (build swing-jcg-linux-02-2004-09-13-int.mustang)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b03, mixed mode)

In Tiger b63, the behaviour is little different. on B63 when u execute the Step#6, the first file will be selected. This looks like a General selection issue with JList. You can reproduce this with the JList Demo also. 
Select any item in the JList and press ctrl+Space, there is no lead selection.

---
Note also that the same problem occurs with JTable. Additionally, the focused cell in JTable is painted in grey if it isn't selected. This also seems weird.
###@###.### 2004-09-16
Comments
EVALUATION Commit to mustang and 1.5.0_02. ###@###.### 2004-09-16 Note: The difference between b63 of tiger and mustang is a non-issue. It's an intended change to selection logic. The only issue here is in regards to the lead not showing the focus border. ###@###.### 2004-09-16 The problem is in GTKPainter.ListTableFocusBorder.paintBorder(). It calls engine.paintFocus() and the state is always SELECTED. This is not always true: a focused cell may or may not be selected, and we should use different colors for these two cases. Now we're painting the unselected cell with foreground color of a selected one, which makes it white on white. Unfortunately it's not easy to determine state of the component. All we have in paintBorder() is the renderer component which does not carry this information. ###@###.### 2005-2-01 14:25:42 GMT So passing into paintBorder() information about whether an item is selected is difficult. We could for example set a client property on the renderer. Or we could compare renderer background color with list.getSelectionBackground() and decide based on this. These are hacks that may not even always work correctly. So i suggest we assume that the item is always unselected (currently we assume the opposite). This way, a selected item will have focus border painted using the correct foreground color. An unselected item will still be distinguishable because it will have different background. There may still be problems when several items are selected and one of them focused. However, i've checked all the themes installed on my JDS system, and the focus indication never turned invisible. This problematic scenario is also less frequent because it never occurs with single selection lists. I believe the 'reversed' assumption is a safer one, though this is not exactly what GTK does. ###@###.### 2005-2-02 14:46:59 GMT A better solution was implemented: we install different focus borders on cell renderers dependent on whether cells are selected or not. The change was made to DefaultListCellRenderer and DefaultTableCellRenderer since it was backward compatible, so LAFs other than GTK may take advantage too. There're two LAF properties now: - focusSelectedCellHighlightBorder is used for selected cells. - focusCellHighlightBorder is used for unselected cells. For compatibility, it is also used for selected cells if the first one is undefined. ###@###.### 2005-03-02 13:47:19 GMT
02-03-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon mustang
24-09-2004