Problems with combo + editable=false

[rodo]

As previously discussed in #409 and #6156 it'll be usefull to have a readonly attribute on combo fields.

These feature is clearly described in TaggingPresets and will be very interesting for external presets in some project like HOT.

[jttt]

Isn't editable property what you're looking for? I didn't actually try it but it's there and it should allow to only select value from list, not enter your own value in edit box.

[rodo]

I've try these attribute, it works, but the value is not shown and I'm afraid it's not enough user-friendly for non techies people.

[simon04]

Patch attached. I don't see a reason why to use a custom ListCellRenderer for combo boxes …

[bastiK]

Replying to simon04:

I don't see a reason why to use a custom ListCellRenderer for combo boxes …

It is for extended description e.g. for SAC_scale. This feature seems to be broken ([4340] ?).

[simon04]

There seems to be some problem when using a <combo> element with editable="false". This is somehow related to the dummy entry which is returned on index -1.

[skyper]

What is the status of this ticket ?

editable=* is available for combo. Is it still broken ?

[Don-vip]

Yes. There are some weird problems with combo + editable=false, like incorrect values displayed, correct value displayed only when clicking on the combo...

[Klumbumbus]

also the text is cut off:

[Klumbumbus]

Ticket #11024 has been marked as a duplicate of this ticket.

[Klumbumbus]

Ticket #18714 has been marked as a duplicate of this ticket.

[shr]

JComboBox height for an editable combobox is max(max(element_height), editor_height).
You can see that by diving down into combobox.reinitialize() > combobox.getPreferredSize() with IntelliJ IDEA.
On my machine this evaluates to max(14, 20) -> 20 for an editable combobox
But for a non-editable combobox this is just max(element_height) -> 14
That's why a non-editable combobox looks squashed.

[shr]

here's a quick fix

[skyper]

Cannot reproduce the cut off. Probably, different "look and feel".

But I can reproduce the wrong display of values, probably, one reason editable is not present in defaultpresets.

[skyper]

I added the broken status and a link to the wiki, please, remove when fixed: wiki:TaggingPresets?action=diff&version=157

[skyper]

condensed sample preset derived from /Presets/MastAndTower

[skyper]

screenshot

[skyper]

See attached example preset​ where the screenshot was taken of.

OS: Debian 10 (buster)

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-03-30 07:18:28 +0200 (Mon, 30 Mar 2020)
Revision:16220
Build-Date:2020-03-30 23:25:33
URL:https://josm.openstreetmap.de/svn/trunk

[shr]

That's a different OS. When the cut off issue is present, height is calculated with JosmComboBox.getPreferredSize() which calls to this.ui.getPreferredSize() and this.ui is an instance of WindowsComboBoxUI

[skyper]

Replying to shr:

That's a different OS. When the cut off issue is present, height is calculated with JosmComboBox.getPreferredSize() which calls to this.ui.getPreferredSize() and this.ui is an instance of WindowsComboBoxUI

Right, I have added the information.

[Klumbumbus]

@simon04: While you are in the flow ;) could you have a look at the small patch after comment:14?

[simon04]

In 16565/josm:

fix #6157 - Presets: UI problems with combo + editable=false (patch by shr, modified)

[simon04]

@Klumbumbus: There is some way to go, still, see report/8.

[Klumbumbus]

Thx, yes :)

[skyper]

The patch did address only one problem but there is at least one more, see my comment (comment 18):

Donvip in comment 8:

Yes. There are some weird problems with combo + editable=false, like incorrect values displayed, correct value displayed only when clicking on the combo...

skyper in comment 16:

Cannot reproduce the cut off. Probably, different "look and feel".

But I can reproduce the wrong display of values, probably, one reason editable is not present in defaultpresets.

[Klumbumbus]

I can confirm the height is fixed and the other problems (comment:8) are still there.
Also the text in the combo is bold when closed, which is not the case for "normal" combos and even for the ones with extended description.

[Don-vip]

should be fixed with #21319

[Don-vip]

In 18221/josm:

fix #21319 - Refactoring of class hierarchy around JosmComboBox / AutoCompComboBox (patch by marcello):

• Code reuse: JosmComboBox now uses a JosmTextField as editor
• Code reuse: AutoCompComboBox now uses AutoCompTextField as editor
• JosmComboBox uses more of the original L&F
• JosmComboBox lists now expand all the way to the bottom or the top of the screen
• Variable height items in combobox lists now work, see #19321
• Autocomplete uses different algorithm, fix #21290
• editable="false" comboboxes in Presets now work, fix #6157 see #11024 see #18714
• The user may toggle LTR-RTL script in JosmTextField (menu and ctrl+space)
• LTR-RTL automatically toggles according to key in AddTag and EditTag dialogs, fix #16163

[Don-vip]

Milestone renamed

[idrizza]

Hello, it seems to me that there's still some bizarre behaviour with this. When I have "editable=false" in a combo, the first value of the list doesn't show up in the field even when clicked on it. Moreover, the value of one field can appear in all the other combo fields of the form. It's only a visual glitch though, because the real values for the keys are still there underneath.

[skyper]

@idrizza:
Please, create a new ticket, mentioning this one, with a complete description how to reproduce. Thanks.