[OSM-talk] JOSM user interface

[David Earl]

On 10/10/2007 10:14, Frederik Ramm wrote:
> Hi,
> 
>>> My suspicion is that it's something to do with the edit control and
>>> Windows automatically clearing it when you start typing because of the
>>> highlight. Maybe on linux AWT has to do the clearing itself and knows
>>> not to in this case?
>>>
>>> Basically on linux you get an incremental search behaviour and
>>> everything works lovely ;-)
>>
>> I just compared the two and it is exactly that. In Windows (or Windows
>> Classic) mode it selects the whole of the item after typing, so replaces
>> it on typing another character; whereas the Metal on only selects the
>> remaining characters.
> 
> Should we then, instead of making the auto-complete a user preference, 
> automatically disable it when the "windows" look and feel is selected, 
> and enable it otherwise? Or does that sound too much of a hack?

That would make it more usable but seems overkill.

Is the bug really in Windows so unfixable, or is there a subtle JOSM bug 
that only shows up in the Windows style?

The relevant code is this, in tools/AutoCompleteComboBox.java, yes?

    if (item != null) {
      // remove all text and insert the completed string
      super.remove(0, getLength());
      super.insertString(0, item.toString(), a);
      // select the completed part
     JTextComponent editor = 
(JTextComponent)comboBox.getEditor().getEditorComponent();
     editor.setSelectionStart(offs + str.length());
     editor.setSelectionEnd(getLength());
   }


The javadoc for setSelectionStart says "constrained to the selection 
end", so is it possible, for example, that the remove and insertString 
sets the end selection to zero, and setSelectionStart then (correctly) 
fails to move the selection start to beyond the zero position (in the 
Windows LAF). If the setSelectionStart and setSelectionEnd were 
reversed, do you think it might then work?

David