Toggldesktop: Autocomplete is eating keystrokes (home, end), destroying typed message

[donquixote]

💻 Environment

Platform: Linux
OS Version: Ubuntu MATE 18.04
Toggl Version: 7.4.528

🐞 Actual behavior

Autocomplete list opens.
home and end keys navigate in the autocomplete list, and DESTROY MY TYPED TEXT!
Escape closes the autocomplete (temporarily) but sometimes modifies the text, e.g. adding a space.

💯 Expected behavior

home and end keys should navigate in the text itself, not in the autocomplete.
This is useful to e.g. select the rest of the text (shift + end), or to jump to the front or end.

🔨 Steps to reproduce

Click into the text field at the top to edit the tracking message.
Start typing until the autocomplete list appears.
Hit home (pos1), end keys while typing, with and without shift.
Also try Escape to get out of the autocomplete list.

📦 Additional info

This was ok in a previous version of TogglDesktop.

[donquixote]

This problem makes the desktop client really painful to use.
Using the wrong keystroke (up, down, home, end) while the dropdown is open wipes the typed text.

[michondr]

@donquixote also question for you - if you try to autocomplete, does it work?

_userstory_
I create task, go to its detail to set project. lets say I have projects portal, polo and nasa.
if I try to set portal, I type por and hit enter with expectations that it will autocomplete portal and set it.
that is not the case. although, if I type po and navigate with arrow keys to portal or polo, it will autocomplete and set

[donquixote]

if you try to autocomplete, does it work?

Not sure how you define "work".
For me the autocomplete suggestion will be inserted immediately when I use up/down keys, no confirmation needed. It replaces whatever I typed manually before, with no way to restore it. This is way too aggressive.

I create task, go to its detail to set project.

The issue was originally about the textfield at the top to enter the tracking message.
However, I confirm that the same problem applies to the field where you select the project.

As you say, up/down will immediately replace what you typed, with no recovery. E.g. if you hit down, then hitting up afterwards will _not_ restore your typed text.

Using the client feels like playing mikado sticks. It defies all that I learned in usability class.

[MartinBriza]

The problem in this case is using navigation keys affects the autocomplete dropdown and not the text edit field. I'll work on keeping the previously typed text in memory while the user is navigating inside the dialog so we can restore it after they will have pressed the Escape key.

[donquixote]

@MartinBriza If you work on this, a good idea would be to check other tools with autocomplete and compare the behavior. E.g. google search field.

[donquixote]

@MartinBriza A good UX could be like this:

• arrow left/right, home, end, all move the text cursor.
• combined with shift, they allow to select text.
• up, down, pgup, pgdown move in the autocomplete list.
• (not sure) using up or pgup to move to the top leaves the autocomplete list, so you can continue typing.
• navigating in the autocomplete list does NOT replace the currently typed text.
• TAB and/or ENTER inserts the selected autocomplete entry in the textfield (but we might want TAB to move around between form elements).

[donquixote]

Also check this
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_datalist

[MartinBriza]

Thanks for the suggestion, to be honest, some of the things you're listing didn't really occur to me when writing this (I had to reimplement a LOT of the basic combobox functionality to have what we want/need in Toggl).
I think the arrow keys work mostly as expected and text selection works as expected too.
Now Home/End keys navigate to the top/end of the list which is probably not what the users expect so I'll change this to work with the text cursor.
Page Up and Page Down seem to work as expected.
I think Tab should stay as it is, just moving to the next item (BUT not destroy what the user had typed).
Enter works as expected.
Escape, same as Tab should not destroy what the user had typed.
Leaving the list with (Page) Up/Down should not destroy what the user had typed.

Do you agree?

[donquixote]

I think this one is important:

navigating in the autocomplete list does NOT replace the currently typed text.

[donquixote]

Another problem:
Currently the autocomplete blocks other UI elements in the widget. E.g. you cannot click the "Done" button as long as the autocomplete is open. This is counter-intuitive, because there is no dark overlay or anything that would tell you you are in a special "mode".
(and rather than adding an overlay, you should simply make it non-freezing)

[MartinBriza]

Another problem:
Currently the autocomplete blocks other UI elements in the widget. E.g. you cannot click the "Done" button as long as the autocomplete is open. This is counter-intuitive, because there is no dark overlay or anything that would tell you you are in a special "mode".
(and rather than adding an overlay, you should simply make it non-freezing)

As for this, that's pretty much intended, the popup is actually a separate window. The fact it doesn't have a shadow is entirely dependent on your window manager.

[donquixote]

As for this, that's pretty much intended

I don't think this is good for UX. Have you done any user tests?
Normally an autocomplete should be helper, but it should not disrupt the flow.
IF you introduce a special "mode" (which I don't think you should) it has to be visible, and the way to get in and out of the mode have to be clear and obvious.

I think a good way for user interface design is to mimic something existing (e.g. the html5 datalist), and then refine from there. This way you benefit from familiarity, and from user testing already done by others. Whenever you do something new and "creative" you could do some user testing.
Also think about the different actions a user might perform at any given time: keyboard, mouse, interaction with other UI elements, switching to other windows..

(I don't know if this project is funded by toggl or only community-driven. In the latter case perhaps you don't have access to professional user testing)

the popup is actually a separate window.

This explains the erratic behavior I get sometimes (Mate desktop, but I think I also had it elsewhere).
If I have multiple monitors connected, on one of them the autocomplete appears in the corner of the screen, instead of under the textfield.
This is not your fault, I also have this sometimes for menus and other things in other applications.

The fact it doesn't have a shadow is entirely dependent on your window manager.

Just to be clear, by "overlay" I mean something that covers all the UI elements that are frozen/blocked.
Maybe Linux window managers are too fragile to rely on for stuff like this?

[MartinBriza]

Thanks for the valuable input. I have started working on this and there are some fruits of that in the fix/linux-autocomplete-eating-text branch. If you want to, you can check it out.

Anyway, I know you don't really care as the end user, I gotta say I was not implementing this from the ground up and the behavior with overwriting user input is the default Qt behavior. If you look into the code, you'll see I just force the lineEdit element inside the ComboBox to just stop listening to the highlighted signal coming from the dropdown (and I'm doing that by using a pretty ugly hack, that's to be fixed, hopefully). But that doesn't mean that's _good_ behavior for this particular element by any means, you're right this should be fixed.

As for the "overlay" issue and darkening/blocking the underlying elements, there's really not much I can do, this is the default and as far as I can tell from other applications, pretty much expected that when you open a ComboBox, you can click outside it to close it but this click won't affect other elements. Again, nothing I personally implemented but that's the part of the ComboBox worfklow in most desktop environments from what I can tell.

[donquixote]

perhaps combobox is not the right tool. perhaps you can find alternatives.
https://stackoverflow.com/questions/24248606/how-to-accomplish-drop-down-word-suggestions-in-qt

Martin Bříza [e-mail] schrieb am Do., 28. Nov. 2019,
19:52:

Thanks for the valuable input. I have started working on this and there
are some fruits of that in the fix/linux-autocomplete-eating-text
https://github.com/toggl-open-source/toggldesktop/tree/fix/linux-autocomplete-eating-text
branch. If you want to, you can check it out.

Anyway, I know you don't really care as the end user, I gotta say I was
not implementing this from the ground up and the behavior with overwriting
user input is the default Qt behavior. If you look into the code, you'll
see I just force the lineEdit element inside the ComboBox to just stop
listening to the highlighted signal coming from the dropdown (and I'm
doing that by using a pretty ugly hack, that's to be fixed, hopefully). But
that doesn't mean that's good behavior for this particular element by
any means, you're right this should be fixed.

As for the "overlay" issue and darkening/blocking the underlying elements,
there's really not much I can do, this is the default and as far as I can
tell from other applications, pretty much expected that when you open a
ComboBox, you can click outside it to close it but this click won't affect
other elements. Again, nothing I personally implemented but that's the part
of the ComboBox worfklow in most desktop environments from what I can tell.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/toggl-open-source/toggldesktop/issues/3384?email_source=notifications&email_token=AABEUECZOXMYH2A5QSBG5ALQWAHM7A5CNFSM4I4T7FE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFNJASY#issuecomment-559583307,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABEUECVVNF52PHNOBB4RP3QWAHM7ANCNFSM4I4T7FEQ
.

[MartinBriza]

That's literally what we use though, with a custom list model filtering the results as you type: https://github.com/toggl-open-source/toggldesktop/blob/b8501123d75eb397478e42bbcd88401b4671e26b/src/ui/linux/TogglDesktop/autocompletecombobox.cpp#L9

[MartinBriza]

QComboBox is basically just a glorified QLineEdit with a button.

[michondr]

Thank you @MartinBriza for handling this issue :) when do you think this might be part of a release with a .deb package?

[MartinBriza]

https://github.com/MartinBriza/toggldesktop/releases/tag/v7.4.600 You can try the packages listed in this release once the build finishes.
Not a final release but a work-in-progress. Input would be highly appreciated.

[donquixote]

Hi,
sorry I did not have time to test this yet. But I appreciate the progress! Thanks for working on this!
(I have TogglDesktop installed from my Linux package manager, so it does not always give me the latest version)