GUI: combobox enter make submit form, not to open the box (alt-down)

[e3rd]

1. Go to combobox
2. Select a value
3. Hit enter
4. Combobox re-open

It should submit the form. (If you are in the 'foo2' field, hitting enter will submit the form.) Investigate why.

#!/usr/bin/env python3
from dataclasses import dataclass
from typing import Callable, Literal
from mininterface import run
from mininterface.settings import GuiSettings

@dataclass
class Env:
    foo1: Literal["one", "two", "three"]
    foo2: str

m = run(Env, settings=GuiSettings(combobox_since=0))

[u2slow]

Hi,
I’d like to work on this issue if that’s okay.
I’ve been looking into the combobox behavior and have some ideas on how to fix it.

[u2slow]

Hi,

I’ve been looking into this issue and found a line in _tk_interface/select_input.py (line 196) that, as far as I understand, causes the current behavior:

python
widget.bind("<Return>", lambda _: "break")  # override default enter that submits the form

Interestingly, it looks like this line was originally added to prevent exactly what the issue describes.

I also wanted to ask — should the form be submitted even if foo2 is empty, or only when it has a value?

[e3rd]

Haha, nice discovery! Let's make it submit when it has a value. The first enter opens the box, and when it has a value, it submits. (If you agree this is the best expected behaviour. :) You might have a better idea.)

[u2slow]

When opening the form, there’s no asterisk "*" next to foo1, which implies it’s not required. However, if you try to submit via foo2 without selecting a value for foo1, the form reopens and shows that foo1 is actually required — and now there’s an asterisk displayed.

This could be slightly confusing for users, because visually it initially looks like foo1 isn’t required, but the code doesn’t explicitly mark it as such in the dataclass:

@dataclass
class Env:
    foo1: Literal["one", "two", "three"]
    foo2: str

It might be worth discussing whether the UI should consistently indicate which fields are required. Additionally, it could be helpful if there were a way to configure in the code which fields are required and which aren’t, so the visual indicators and the actual validation behavior are aligned.

this is before

this is after

[u2slow]

Hi, just a small reminder — do you have any thoughts on my comment above?

My suggestion would be to first fix the original issue as described, and handle the asterisk/required-field behavior separately in a new issue, since that seems like it would require a larger change.
If you agree, I can prepare a PR for the original fix.

[e3rd]

Thanks for pinging me, sorry for the delay! :)

The asterisk indicates rather the fields that failed validation. You just omit the dataclass default value to make the field required. IMHO it works well and predictable now but if you want, I agree to open another issue for the discussion as I don't see these dependent (or are they?).

[u2slow]

I noticed that foo2 still behaves as if it’s not required. For example, if foo1 has a value selected (e.g., "one") and the cursor is in foo2, which is empty, pressing Enter will submit the form. In contrast, if foo1 is empty, pressing Enter does not submit.

I mention this because I’m currently working on the Enter handler for foo1 and want to take into account whether foo2 should be considered required or not.

[e3rd]

Will you please pull request the partial solution so that I take a look? :)