Bug 104935

  I was working on a new widget for doing autocompletion in readonly 
comboboxes but it's not done yet.  I know it's not the same idea, but it will 
also help.

Matt, could you provide more details on what you'd like here; perhaps with a mockup of the dialog. Why would you want the ability to search for existing vector names when you're creating a new one?

I think this should read 'searching for fields' not vectors.  In a 'typical' experiment data source, there can be hundreds of fields.  Finding the right one can be a pain with the current combo box.  

This fix should, if possible, be committed to KDE as a whole, because the same problem comes up with, eg, Konq dialogs searching for countries.

As I understand it we already have autocompletion in these read-only comboboxes (if I start typing the name of a field it will automatically display the name of the first matching field). Unless George meant something else by autocompletion then there is no work to be done here.

Would this feature to search for entries in a read-only combobox be useful in other areas (vectors, windows, plots, etc.)? 

The UI would have to be different from the data wizard as there the user is making a multiple selection, whereas for the combobox only a single selection makes sense.

SVN commit 428375 by arwalker:

CCBUG:104935 Concept of allowing user to search for scalars, vectors, fields, etc. Lack of feedback will be taken to indicate support. Currently only implemented for the scalar selector. Click on the ellipsis for a dialog that allows you to search for the desired scalar.

 M  +2 -0      Makefile.am  
 A             comboboxselection.ui  
 A             comboboxselection_i.cpp   [License: GPL (v2+)]
 A             comboboxselection_i.h   [License: GPL (v2+)]
 M  +38 -11    scalarselector.ui  
 M  +22 -0     scalarselector.ui.h  

On Thursday 23 June 2005 18:31, Andrew Walker wrote:
> SVN commit 428375 by arwalker:
>
> CCBUG:104935 Concept of allowing user to search for scalars, vectors,
> fields, etc. Lack of feedback will be taken to indicate support. Currently
> only implemented for the scalar selector. Click on the ellipsis for a
> dialog that allows you to search for the desired scalar.
>
>  M  +2 -0      Makefile.am
>  A             comboboxselection.ui
>  A             comboboxselection_i.cpp   [License: GPL (v2+)]
>  A             comboboxselection_i.h   [License: GPL (v2+)]
>  M  +38 -11    scalarselector.ui
>  M  +22 -0     scalarselector.ui.h


  A few comments:
- PNGs were placed in scalarselector.ui but we still need 3.1 compat
- The tab order is now backwards
- It should probably be matching case insensitive
- void selected(QString& str) { str = _selected; } is quite unorthodox, 
especially in KDE apps.  It's also not clear what it does, and can't be used 
as a Qt property (which we will do with scripting at some point).  It would 
be better to write this as QString selected() I think.
- Lack of feedback really doesn't indicate support and it's not appropriate.  
It's impossible to collaborate when working on such a basis.

  Anyhow, when I first saw this, what came to mind was the URL bar in 
Konqueror (or IE for those who don't use Konqueror).  It is a combobox that 
provides autocompletion via a dropdown box, case insensitive, and allows all 
the operations needed to be done in one widget without extra dialogs or 
buttons.  The user can still type in something that doesn't exist in the list 
too.  The tools for this are in libkdeui, and I think it would be a big 
usability improvement.

The combobox list in IE is really an MRU and not a comprehensive
list of all available sites. That said, we could use a similar approach
but I'm concerned about a few things:

1) making the edit field editable, which means that every dialog using
a scalar/vector selector will now need to validate the results of these
fields and refuse to close if an invalid selection is made
2) restricting the list to some subset of the entries based on user input.
I think comboboxes should always contain all valid choices
3) by making the edit field editable we lose auto-completion

Andrew

On Monday 27 June 2005 12:50, Andrew Walker wrote:
> ------- The combobox list in IE is really an MRU and not a comprehensive
> list of all available sites.


  Right - it's the UI that is in question.  We do a similar UI for the field 
list in the vector dialog.

> That said, we could use a similar approach 
> but I'm concerned about a few things:
>
> 1) making the edit field editable, which means that every dialog using
> a scalar/vector selector will now need to validate the results of these
> fields and refuse to close if an invalid selection is made


   You can have a flag that says if the user should be allowed to create new 
entries or not.  I don't see any reason to create new scalars in the scalar 
editor window.  It probably shouldn't allow the user to do anything except 
change the name - there should be no completion and it should only warn if 
that new name is already in use if the name was changed.

> 2) restricting the list to some subset of the entries based on user input.
> I think comboboxes should always contain all valid choices


   It's not a combobox - it's a completion box.

> 3) by making the edit field editable we lose auto-completion


   There's no auto-completion there now - anywhere.  An editable field is the 
only type of field that has completion in KDE at the moment.  KstComboBox is 
supposed to be a read-only combobox with traditional autocompletion, but it 
is very low on the priority list right now, so it's incomplete.

   We have autocompletion in two other places in Kst though - vector dialog 
and data wizard.  They don't support it for read-only comboboxes though, and 
that's what I had hoped to change at some point.

The read-only comboboxes that I use in Kst have auto-completion. As an example, open the New Vector dialog and select the Field or column combobox. You can't enter text into this combobox (so it is read-only) but if I type into it, the selected item changes to give the closest match to what has been typed. Is this not auto-completion?

On Wednesday 20 July 2005 18:02, Andrew Walker wrote:

> ------- The read-only comboboxes that I use in Kst have auto-completion. As
> an example, open the New Vector dialog and select the Field or column
> combobox. You can't enter text into this combobox (so it is read-only) but
> if I type into it, the selected item changes to give the closest match to
> what has been typed. Is this not auto-completion?


  No, it's list search.  Auto completion would be like what happens in 
Konqueror, where a drop-down list appears.  The idea Barth and I had thrown 
around was to have a drop-down (combo) that shows all the matches but still 
only allows you to select or type in a valid match.

Matt, could you provide some feedback on which approach you think might work best here. There is an example of the approach I was thinking of in the "New equation" dialog for the scalar selection. Just hit the ellipsis button.
Hopefully, George's approach has been described in enough detail that you can envision how it would work. 

What I don't like about the ellipsis button is that it is a little cumbersome to use (instead of just typing and the equivilant thing appears, like what I *believe* George is describing in his idea), as well as the fact that until you told me to go looking there, I would not have clicked on the ellipsis to search for scalars.  

I think what I originally (and still) wanted (want) is what George is describing, but which doesn't yet exist.  Perhaps this wishlist item should be put on the backburner for a bit.  

Should be fixed for 1.2.1 release

George, you indicated some time ago that you were "...working on a new widget for doing autocompletion in readonly comboboxes..." Is this work still underway or should we go ahead and implement Matt's original suggestion of a search button that pops up a small dialog?

On Thursday 22 June 2006 13:28, Andrew Walker wrote:
> ------- George, you indicated some time ago that you were "...working on a
> new widget for doing autocompletion in readonly comboboxes..." Is this work
> still underway or should we go ahead and implement Matt's original
> suggestion of a search button that pops up a small dialog?


  It's not done yet.  I don't see any point in adding more features that we 
know we'll remove though.  We can easily live without another dialog in the 
meantime.

Created attachment 18947 [details]
Completion combo patch

This is a modified readwrite KComboBox that uses validation on certain events
to masquerade as a readonly box.

SVN commit 621866 by treat:

* Create new psuedo readonly combobox with completion

BUG: 104935



 M  +66 -312   kstcombobox.cpp  
 M  +39 -497   kstcombobox.h  
 M  +2 -1      matrixselector.ui  
 M  +2 -1      scalarselector.ui  
 M  +0 -1      scalarselector.ui.h  
 M  +2 -1      stringselector.ui  
 M  +2 -1      vectorselector.ui