<< Back to previous view

[SWINGX-1532] Improve usability for the autocomplete combobox Created: 30/Oct/12  Updated: 02/Nov/12

Status: Open
Project: swingx
Component/s: Autocomplete
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: robin_stevens Assignee: Karl Schaefer
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive samples.zip     Zip Archive samples20121031.zip    
Tags:
Participants: bobndrew, Karl Schaefer, kleopatra and robin_stevens

 Description   

Also see http://stackoverflow.com/q/13138266/1076463

The use-case is having an editable auto-complete combobox where you want to trigger a long-running task when the user has finished changing the selection. You do not want to trigger the long-running task when

  • the user is still typing
  • the user is navigating with the keyboard arrows
  • the user is navigating with the mouse

You do want to trigger the long-running task when

  • the user selects an item with the mouse
  • the user types an item and confirms with ENTER
  • the user selects an item using keyboard arrow navigation and confirms with ENTER

I did not manage to fulfill all these requirements. Attached to this issue 3 classes which show 3 approaches, but none of them work completely. The ImprovedApproach comes closest, but still requires an ENTER after mouse selection.

The last issue usability issue is editing of an existing item to a slightly different one. This is present in all 3 of the samples attached to this issue. You override way too easily the auto-completed part, e.g. in the ImprovedApproach sample do

The actual example which was reported by one of our users was the editing of //SERVER1/Data/... to /server/data/..., so having an option to switch off case-insensitive auto-completion is not enough.



 Comments   
Comment by bobndrew [ 31/Oct/12 01:56 PM ]

Running the OnlyConnectButton.java and the NaiveApproach.java example showed the same behaviour... because the same class was instantiated

OnlyConnectButton.java
...
  @Override
  public void run() {
    new NaiveApproach().show( "Button only" );
  }
...

I fixed that and added a new class WorksAsDesired.java to the samples20121031.zip file which works as you described in your use-case. I used an ActionListener on Button1 clicks (like kleopatra suggested on stackoverflow).

WorksAsDesired.java
...
  @Override
  public void actionPerformed(ActionEvent e)
  {
    if ((e.getModifiers() & InputEvent.BUTTON1_MASK) != 0)
...

A new problem is that the CombobBox in your example is editable; because of that 3 action events are fired (mentioned here in the forum) after mouse-clicking. One empty and two events with the new selection. If the ComboBox is not editable only one event is fired.
I debugged and read through the org.jdesktop.swingx.autocomplete.AutoCompleteDocument.java code. Maybe the selecting flag should be true when entering the remove(int offs, int len) method?

I have no ideas regarding your "usability issue", sorry.

(tested on Windows 7 64bit, Java 1.7.0_07-b10)

Comment by bobndrew [ 31/Oct/12 02:15 PM ]

fixed and new example

Comment by Karl Schaefer [ 31/Oct/12 03:52 PM ]

The forum example (for three events) is invalid because the combo box is being used as a cell editor. The correct listener to use is a CellEditorListener on the ComboBoxCellEditor and not an ActionListener on the decorated JComboBox.

Furthermore, I don't understand the point of this bug. If you want to ensure that the user is done selecting, you need to give the user a way to specify that, such as a button.

Comment by robin_stevens [ 31/Oct/12 09:56 PM ]

@Karl Schaefer

I have a button, but it is very counter-intuitive that you have to click it after selecting an item from a combobox. Therefore I tried having all the possibilities: use the button, type + hit ENTER, mouse selection, keyboard navigation. But that is probably more a problem with a JCombobox then with the auto-completion.

However, there is still the 'editing an existing entry' usability issue as described above. I just logged this issue with the illustration on how I am using the auto-completed combo box, including all weird constructions trying to only trigger the connection when the user has finished editing. Might have been that I was using the component completely wrong ...

Comment by bobndrew [ 01/Nov/12 09:50 AM ]

@Karl Schaefer

The point of this bug is the attempt to make an auto-complete-ComboBox behave like the adress-/search-ComboBox-Field in recent internet browsers.

If you type a URL or a search term in Firefox you get matching adresses in a popup. If you hit enter or click an item the website is loaded. In Firefox there's is an (optional) tiny arrow button, like you mentioned, to give the user the possibility to start the webpage loading. But it's only visible if you typed something new; it's replaced with the "add to favorites" button, after the pages is loaded.

In Opera and Safari there is no "Go to URL now!"-button anymore: just enter-keying and mouse-clicking.

Comment by kleopatra [ 02/Nov/12 10:42 AM ]

Actually, we already support the WorksAsDesired - in the ComboBoxCellEditor The implemenation is different from the one I suggested on SO but to a similar effect.

  • install a ComboBoxCellEditor around the decorated comboBox
  • for commit-semantic notification, add a CellEditorListener to the editor
final JComboBox withEditor = new JComboBox( new String[]{
            "http://www.google.com",
            "http://java.net/jira/browse/SWINGX",
            "http://today.java.net/pub/a/today/2007/07"
              +"/19/adding-auto-completion-to-swing-comboboxes.html",
            "http://docs.oracle.com/javase/7/docs/api/",
            "http://java.net/jira/browse/SWINGX-940",
            "http://java.net/jira/browse/SWINGX-1264"
        } );
    withEditor.setEditable( true );
    AutoCompleteDecorator.decorate( withEditor );
    ComboBoxCellEditor editor = new ComboBoxCellEditor(withEditor);
    CellEditorListener listener = new CellEditorListener() {
        
        @Override
        public void editingStopped(ChangeEvent e) {
            connectToItem((String) withEditor.getSelectedItem(), outputArea);
        }
        
        @Override
        public void editingCanceled(ChangeEvent e) {
        }
    };
    editor.addCellEditorListener(listener);
    contentPane.add(withEditor, BorderLayout.SOUTH);




[SWINGLABS_DEMOS-1] SearchDemo: MatchingTextHighlighter cant cope with center/right alignement Created: 02/Sep/11  Updated: 26/Sep/11  Resolved: 26/Sep/11

Status: Resolved
Project: swinglabs-demos
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kleopatra Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive MatchHighlighterBugfixesAndDemo.zip    
Tags:
Participants: bobndrew and kleopatra

 Description   

reported (and tracked down) at

http://stackoverflow.com/questions/7273123/wrong-highlighting-while-using-a-jxtable-with-the-matchingtexthighlighter



 Comments   
Comment by bobndrew [ 06/Sep/11 02:33 PM ]

Some bugfixes for the (X)MatchingTextHighlighter:

  • Cell alignments left, right, center
  • JLabel with icon
  • Right to left component orientation
  • Highlight matches in viewed text AND in the ellipsis
  • Stable moving of the Highlighter while dragging the Column-width
  • Rows with different rowHeight

The 'SwingUtilities.layoutCompoundLabel()' Bug remains a mystery.

Comment by bobndrew [ 08/Sep/11 03:16 PM ]

Bugfix for:
If more then one character was matched in a string two or more highlighted regions could be coalesced. This resulted in a wrong highlighted ellipsis even if there was no matched character under the ellipsis.

Comment by kleopatra [ 26/Sep/11 10:57 AM ]

Great!

committed (finally, sorry for the delay!) your fix.

cheers
Jeanette





[DESIGNGRIDLAYOUT-50] Describe the limitation for indent() only working with LabelAlignment.LEFT Created: 08/Dec/11  Updated: 03/Feb/13  Resolved: 03/Feb/13

Status: Closed
Project: designgridlayout
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Minor
Reporter: bobndrew Assignee: jfpoilpret
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: javadoc website indent
Participants: bobndrew and jfpoilpret

 Description   

I was trying to indent some rows with the layout set to

layout.labelAlignment( LabelAlignment.RIGHT );

The indentation is only working with LEFT alignment.

This should be mentioned in:

In my opinion all examples with strings having the same length could benefit from changing them to 'real world' strings:

  • Example 3: row1, row2, row3 --> first name, surname, birthday
  • Indent-examples: Label 1, Label 2, Label 3 --> Address, Street, City

This would have shown me that the indent example was using LEFT alignment.



 Comments   
Comment by jfpoilpret [ 25/Dec/11 10:13 AM ]

Well, in fact, we cannot really say that indent() works only with left alignment. I'd rather say that it seems to work a bit differently when using right alignment.

The notion of indent is just extra space added on the left of a row, or more precisely, as mentioned in the javadoc, space added before the left most component of a row.

In the case of grids, the labels in the label column (the 1st column of the grid) are, initially, all forced to the same width (the max width of all labels in the column). Then extra space is added when rows are indented.

When you use right-alignment, the indent space most often won't clearly be visible to the end user.

However, there are situations where this indent will appear as expected:

layout.row().left().add(new JLabel("Address"), new JSeparator()).fill();
layout.row().grid(new JLabel("Street 1")).indent(1).add(new JTextField("Benjamin Franklin Bd"));
layout.row().grid(new JLabel("Zip Code")).indent(1).add(new JTextField("CA 1234"));

In the example above, when using right alignment, you will see that "Zip Code" is indented in comparison with "Address". You would see no indent at all when not using indent(1).

Comment by bobndrew [ 18/Jan/12 12:18 PM ]

I thank you for your reply. But I think to add a row out of the canonical grid to get an indent should not be the way to "solve" this for a user of this library.

I think the second line should also be starting at the postion where the first line is starting, if I use this example:

layout.row().left().add( new JLabel( "Out of the canonical grid..." ) );
layout.row().grid( new JLabel( "Label 1:" ) );
layout.row().grid( new JLabel( "Label 2:" ) ).indent( 4 ).add( new JTextField( "field 2" ) );
layout.row().grid( new JLabel( "Label 3:" ) ).indent( 4 ).add( new JTextField( "field 3" ) );
Comment by jfpoilpret [ 20/Jan/12 10:09 PM ]

For me, your last example gives the expected result.
The reason is that there is only ONE canonical grid, and all "grid()" rows belong to it.
Non-canonical grid rows (left, right, center and bar) share no dimension with grid rows and are completely independent of grid rows.
In a canonical grid, there is one specific label column, which size is fixed and equal to the max width of all labels in that column,
plus the max indents added to grid rows.

Hence, in your example, the first column of the first grid row ("Label 1:") is the same width as 1st column of grid rows "Label 2: " and "Label 3:" which are indented 4 times.
Now, since the alignment of labels is right, "Label 1:" will be right-aligned in this column and will thus appear indented, compared with the 1st row, out of the canonical grid.

Comment by jfpoilpret [ 20/Jan/12 10:12 PM ]

Not an improvement to DGL library but rather a task to improve the documentation.
Considered minor, because I don't think many people will see the observed behavior problematic when using indent() with right alignment for labels.

Comment by jfpoilpret [ 03/Feb/13 05:42 PM ]

Documentation updated on SVN trunk (rev. 520).

Comment by jfpoilpret [ 03/Feb/13 09:43 PM ]

Documentation fixed in release 1.10





[APPFRAMEWORK-65] TextActions.updateTextActions throws IllegalStateException Created: 14/Mar/08  Updated: 15/Jul/11

Status: Open
Project: appframework
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: haraldk Assignee: appframework-issues
Resolution: Unresolved Votes: 6
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 65
Tags:
Participants: appframework-issues, bobndrew, haraldk and Karl Schaefer

 Description   

Currently, TextActions.updateTextActions does not catch the
IllegalStateException that is sometimes thrown from
Clipboard.isDataFlavorAvailable (when the clipboard is currently unavailable).
This typically happens on Windows, when other applications are writing to the
clipboard, as far as I understand. I've never seen it on the Mac.

The exception is documented, but one could argue that this is a bug in the JDK.
Both as there is no way to check if the clipboard is available, and there is
nothing the programmer can do to guard against it (the exception should at least
be checked, to be consistent with other JDK code, even though I personally don't
particularly like checked exceptions).

In any way, the exception must be caught, to guard the EDT. I don't really know
the appropriate action to take in such case, but maybe try again at a later time?

More info on the bug can be found here:
http://bugs.sun.com/view_bug.do?bug_id=4444868 (same problem in NetBeans, now
fixed), and here: http://bugs.sun.com/view_bug.do?bug_id=4464162 (JDK).

Stack trace:

java.lang.IllegalStateException: cannot open system clipboard
at sun.awt.windows.WClipboard.openClipboard(Native Method)
at
sun.awt.datatransfer.SunClipboard.getClipboardFormatsOpenClose(SunClipboard.java:315)
at
sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:175)
at
org.jdesktop.application.TextActions.updateTextActions(TextActions.java:132)
at org.jdesktop.application.TextActions.access$400(TextActions.java:47)
at
org.jdesktop.application.TextActions$ClipboardListener.flavorsChanged(TextActions.java:108)
at
sun.awt.datatransfer.SunClipboard$1SunFlavorChangeNotifier.run(SunClipboard.java:427)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



 Comments   
Comment by Karl Schaefer [ 02/Apr/09 09:45 AM ]

This bug crept up in a post over at SwingLabs/SwingX:
http://forums.java.net/jive/thread.jspa?threadID=59633&tstart=0

SAF should catch the IllegalStateException. Simply keeping the paste action
disabled is a fine solution and doesn't propagate this clipboard ugliness to
the client.

Karl

Comment by bobndrew [ 15/Jul/11 03:34 PM ]

Since work on the Swing Application Framework has stopped at Version 1.03 the only fix for this problem is the use of the BetterSwingApplicationFramework (http://kenai.com/projects/bsaf/).

It is backwards compatible. Our program just worked after the replacement of the Jar.





Generated at Sun Apr 20 02:39:16 UTC 2014 using JIRA 4.0.2#472.