[kde-guidelines] Drop-down list and Combo box

[Thomas Pfeiffer]

On Wednesday 12 June 2013 10:54:53 Aurélien Gâteau wrote:
> On Tuesday 11 June 2013 22:07:54 Thomas Pfeiffer wrote:
> > On Friday 07 June 2013 17:28:26 Heiko Tietze wrote:
> > > IMHO we should distinguish between simple, read-only drop downs and
> > > combo
> > > boxes. But some of the underlying ideas, and probably the code as well,
> > > are
> > > very similar. So I put both into the old ComboBox article.
> > > 
> > > http://techbase.kde.org/Projects/Usability/HIG/Combo_Box
> > 
> > Agreed! The problem is that common naming and Qt naming collide here. In
> > Qt, afaics, both a drop-down / select box and an actual combo box are a
> > ComboBox, one with "editable" set to "false", the other with it set to
> > "true". And then there is a KComboBox, which is an extended ComboBox that
> > among other things has an "autocomplete" option.
> > 
> > If now we refer to the same widget with an option set to one value or
> > another with different names (one being the same that Qt uses) could lead
> > to confusion among developers.
> > On the other hand, I don't know how the respective Plasma Components (or
> > Qt
> > Desktop Components, for that matter) are or will be called. Looks like
> > confusion all over the place.
> > Developers, can you help us here?
> 
> Plasma components comes with a ComboBox item. It wraps a KComboBox, but does
> not expose the "editable" property, making it always read-only for
> QML-based code (C++ based code can still access and change this property).
> 
> QtQuick controls also comes with a control named "ComboBox", which is always
> read-only.

Oh dear, so ComboBox in the QML world is exactly the opposite of what most 
usability people (including Heiko and me) mean by ComboBox (which is always 
editable). Holy confusion...
 

> > copy some bullets to comment on here:
> > > Use a drop-down list for single selection of one out of many items.
> > > For a single selection out of a large number of items, use a list view.
> > 
> > What's the exact distinction here? Personally, I'd distinguish mainly
> > based
> > on available space. If there is enough vertical space for a tall list box,
> > it works better for single selection because you can see more options at
> > once. If you don't have the vertical space, you have to use a drop-down
> > anyway. Not sure if that is a sufficient criterion for distinction,
> > though.
> 
> +1. Additionally, when you have enough vertical space and a long list to
> pick from, you can make use of a KListWidgetSearchLine, a widget provided
> by kdelibs to easily add a filter-as-you-type lineedit on top of your list.

Oh yes, this should indeed be included!

> > > Enable vertical scrollbar for drop-down lists with more than eight
> > > items.
> > 
> > Devs: Does this have to be enabled explicitly or does it appear
> > automatically?
> 
> The scrollbar is automatically enabled. What you can control is the number
> of visible items. See:
> 
> http://qt-project.org/doc/qt-4.8/qcombobox.html#maxVisibleItems-prop

Hm okay, so we should recommend to set the number of visible items to 8 then.
 
> > > Do not add controls to the drop-down (e.g. check boxes for each item).
> > 
> > Devs: Is this even possible technically?
> 
> It is possible, but it's not trivial: the widget which appears to show items
> when you click on the button is a QListView, the widget used to do all list
> views. QComboBox API allows you to replace this widge with your own.

If it's possible, then we indeed should explicitly discourage it, because it 
would never work well.

> > > Provide autocomplete for the whole string and not for only the last
> > > letter,
> > 
> > i.e. ABC must not go to the first entry starting with "C".
> > 
> > Devs: Does the autocomplete option of KComboBox provide that
> > automatically?
> 
> I think QComboBox behaves as one expects it to.
> 
> Given the following item lists:
> 
> - bike
> - boat
> - car
> 
> If one types "b", QComboBox selects "bike".
> If one (rapidly) types "bo", it selects "boat".
> If one types "c", it selects "car".
> 
> This behavior is independant of the "editable" property. When "editable" is
> true, the combobox lineedit marks the completed part of the item as
> selected, making it easy to change the completion. That is, if I type "b",
> the lineedit looks like this:
> 
> b*ike*
> 
> "ike" is selected.
> 
> Additionally, when "editable" is false, one can repeatedly type a letter to
> cycle through items starting with this letter. In my example, after typing
> "b", "bike" is selected. If I type "b" again, "boat" is selected. If I type
> "b" again, "bike" is selected again.

Okay, so if that works automatically and cannot be changed, I don't think 
we'll need a guideline about it.

> KComboBox autocompletion is a bit weird: it works on a different list than
> the combobox items.
> 
> To confuse you a bit further: kdelibs also comes with another widget:
> KHistoryComboBox :) This widget is not really meant to be used as a combo
> box, but rather as a line edit which remembers what you typed before.

Well, that's a different beast then, which probably needs its own HIG.