opening history dropdown marks line edits as modified

[ossi]

a minor issue that has bugged me forever:
in the file search dialog, i often open the dropdown on the "content" line edit to see whether what i want to search for is already there (*). when it isn't, i'll just close it again. however, that is sufficient to mark the previous content as modified, so i have to manually delete it first instead of just typing ahead.

(*) that's more of a lottery than i'd like it to be due to the history not being synced between concurrent instances, but that's another issue.

[zaytsev]

Andrew, what do you think? I am also sometimes bugged by this behaviour.

[andrew_b]

Replying to zaytsev:

Andrew, what do you think?

I think it should be fixed.

and's patch is not correct. If you open history using mouse, you get the same behavior. Patch doesn't fix that. In the current implementation, any key reset the initial state of input ("initial" means state before any key press) . For example, open copy dialog (press F5). You're in the "to" input line, and this input is in the initial state (has alter color). If you press the "left" key, initial state will reset, you can edit the text. With and's patch, left/right key movements keep the initial state, and if you try insert any letter, you clear the text.

The behavior of input completion is the same as described in the ticket description: press F5, press esc+tab to open completion window, close it. The initial state of input is reset. This should be fixed too.

So, there are two commands of input line that should be handled as special cases: CK_History and CK_Complete. If input line is in initial state and history or complete window was cancelled, initial state must be kept.

[andrew_b]

Branch: 4152_input_keep_first
changeset:d7cce5855947321adcb3328c08c17caab6df7a9e

[ossi]

thanks, works as expected. no opinion on code quality.

[andrew_b]

Merged to master: [840fc0a49b72a900cd0502885439e895cb805653].