Changed the behaviour of TableViewTextInput to loose focus on enter/return

[seventil]

Right now any TableViewTextInput (and TextInput/TextField in general) based elements rely on Accepted and EditingFinished signals to tie in backend logic. The issue with such an approach is that pressing enter fires both signals, while the focus remains in the element providing no visual feedback to the user that the input was accepted. Moreover, adding 'focus = true' in code might accidentally fire secondary EditingFinished signal.

This PR introduces a way to provide visual feedback to the user on enter/return pressed.
Behaviour of Accepted/EditingFinished is not changed: Accepted is fired on enter/return, EditingFinished is fired on enter/return or focus loss.

[AndrewSazonov]

I think this can be simpler. Instead of adding Keys.onReturnPressed and Keys.onEnterPressed, and manually calling accepted(), it should be enough to use:

onAccepted: focus = false

This keeps the default Enter/Return behavior from Qt, and should avoid possible validator-related issues from redefining accepted() manually.

[seventil]

onAccepted: focus = false

Such an approach results in calling EditingFinished twice, which might lead to issues in user-defined onEditingFinished.
The reason is that, by default, return/enter key fires Accepted followed by EditingFinished. But defocus also fires Editing Finished. So if we implement onAccepted: focus = false the EditingFinished is fired first from the return key, and then for the second time from the focus toggle in onAccepted.

But what possible issues might we have from validations in manually defined onEnter/onReturn?

[AndrewSazonov]

I see now what you mean. You mentioned this in the PR description, but I missed that point, sorry.

Here is a small example of the validation issue I was talking about:

EaElements.TextField {
    validator: RegularExpressionValidator {
        regularExpression: /^[0-9][0-9]$/
    }
    onAccepted: console.log("ACCEPTED:", text)
    onEditingFinished: console.log("FINISHED:", text)
}

Here the valid text must be exactly 2 digits. With normal Qt behavior, if the user types only 1 digit and presses Enter, it will not be accepted. With manually redefined onReturn/onEnter, however, it will be accepted, so this bypasses the default validation logic.

The more I think about it, the more I am in favor of not changing the default Qt behavior on Enter/Return, meaning not removing focus from the field. But I agree that giving no feedback to the user is also not nice UX.

So maybe the better solution is to keep the default behavior and provide only visual feedback on accepted, without changing focus or redefining key handling. For example, briefly flash the field border in a "success" color, such as the theme accent color.

[seventil]

Changed the logic to include validations. Confirmed correct onAccepted and onEditingFinished firing on defocus/enter/return. Validated with the following code:

EaElements.TextField {
    width: 200
    validator: RegularExpressionValidator {
        regularExpression: /^[0-9][0-9]$/
    }

    onAccepted:        console.log("TextField Accepted")
    onEditingFinished: console.log("TextField onEditingFinished")
}
EaElements.TextInput {
    width: 200
    validator: RegularExpressionValidator {
        regularExpression: /^[0-9][0-9]$/
    }

    onAccepted:        console.log("TextInput Accepted")
    onEditingFinished: console.log("TextInput onEditingFinished")
}

The incorrect field (with one digit) does not fire onAccepted or onEditingFinished, but toggles the warned property.