Progressive Typing

[seasoned_geek]

Before we had a mouse we had progressive typing drop-list fields. When you entered the field and hit a key a list of potential matches appeared below it. When you hit the next keystroke the list adjusted containing only entries having the first two. Each character was added to the selection criteria for the list shown. When there was only one it would either auto-complete or you could tab complete it. Even back in the days of DOS, every UI library I used operated in this manner.

Today's UI libraries make it impossible to have good design. When you are in a combobox (or other type of list) they employ one & done keystroke support. Please allow me to provide a small example. Say you need to purchase a Carburetor. When you tab to the part selection list/combobox you start by typing "c".

In today's world a list of all things starting with C appears. Same thing happens in the world of good design.

Now you type "a"

In today's world a list of all things starting with A appears. In the world of good design the list now has only entries containing "ca." (Some designs require it be in the beginning and other designs allow for it to be anywhere in the word.)

Now you type "r"

In today's world a list of all things starting with R appears. In the world of good design the list now has only entries containing "car."

When you get down to a list of one, some shops would autocomplete, most shops would still require the user to TAB out because if you autocomplete they can't backspace to fix a spelling error.

I would like to see the following properties/settings added to all widgets having lists and entry fields so good design can happen out of the box without having to sub-class then gut private class code not exposed to the user for general override.

• Enable progressive typing

• case sensitive/insensitive text match for list construction

• Beginning of word match

• Contained in word match

• Auto-complete if only 1

I didn't go digging through the documentation to see if case sensitive already existed. Was involved in a discussion about how one cannot do proper form and screen design with today's UI libraries and decided to make the request here.

Perhaps a whole new widget so those who like the way the combobox currently works won't be offended?

QListBox or QListEntry?

Has all the properties requested above but appears (and is) a QLineEdit with additional property optionally requiring entry be in the list currently attached (allows for new data if not). When a user navigates to it the thing drops down (or pops above depending on screen position and remaining space) Re-use QListView or whichever existing list widget that can be most easily connected to a database table for data source if developer needs/wants.

Let the team think on this a bit.

[barbara]

QComboBox currently has built in functionality to support these two items.

(a) case sensitive/insensitive, the default is “case insensitive”
(b) beginning of word match

It sounds like you are interested in knowing how to use a QComboBox and have the display be limited by what the user has typed. We will post a working example towards the end of next week.

Barbara

[seasoned_geek]

Yes, I would really be interested in seeing that because what currently happens is, assuming a user wants to find "Fred" in the combobox

1) User types f and all of the F entries show up
2) User types r and all of the R entries show up not all the Fr entries.

[barbara]

We have uploaded a new CS Journal entry with a full working example and CMake build files. This example explains how to display a subset of the values in a QComboBox based on the text entered by the user in the line edit portion of the combo box.

CopperSpice Journal - Gui Example 45
https://journal.copperspice.com/?p=2589

Barbara