[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: completions
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-08-29 17:48:07
[Download RAW message or body]

On Sun, 29 Aug 1999, Cristian Tibirna wrote:
> On Tue, 24 Aug 1999, Troy Unrau wrote:
> 
> > Shift-Tab cycles backwards through frame focus, and no, an autocomplete
> > feature should not breaK other controls.
> 
> What about netscape-like completion? I thought Qt does it somehow
> automatically for some widget (sorry, didn't touch the Qt docu in a
> while).

This is true for QT 2.x.  However, the bug report that initiated this
discussion is on kfm from KDE 1.1.1.  In fact, the last time I checked konqy
uses the QComboBox's auto completion feature.  So this is not a problem in the
HEAD branch. 

> Sure, this doesn't give much advantage when multiple items have long
> initial matching contents (like in the case of files in the same
> directory) but then what about this:
> 
> 0) empty lined
> 1) type 1-2 chars => lined completes to the first encountered match,
> displays it and activates the selection on it excluding from the selection
> the 1-2 chars typed before

> 2a) if another char (other than \013 <ENTER>) is typed, go back to 1.

> 2b) if \013 is hit, restrain the active selection zone to the part of the
> currently displayed match that is unique (not present in any other match
> corresponding the the first matched chars)
> 
> 	3a) if any char (besides \013) is typed now, go to 1
> 
> 	3b) if a \013 is hit, currently displayed URL is accepted 
> 
> This amounts to:
> 
> In bash:   types <TAB> ... <ENTER>
> In klined: types <ENTER> ... <ENTER>
> 
> What do you say?

Ummm...  I see people did not read my post :-(

I see that your idea is to have a variation on the automatic completion
feature.  I have two suggestions/comments on it.  First, the patch I posted for
the KLined allows the key bindings it uses for rotation and completion to be
changed at any time, thus making it completely customizable.  So the key
binding can be changed to whatever you like with some discretion ( you cannot
use modifier+modifier, ex ALT-ALT or CTRL-ALT etc ).

My second comment is actually a problem I see with what you are proposing
First it is bound to one key <ENTER> for which people will most certainly
complain specially if they cannot turn it off or change the key bindings that
allows them to do that.  Actually the latter one is a very valid complaint (see
below).  But I think the solution I mentioned above could help remedy this 
problem.

The other issue is how you are going to deal with event handling.  Both KLined
and the browser need to know about <ENTER> key events. KLined needs it so that
it can do the completion or at least test for it and the browser in order to
open the user input (URL).   To me this would mean that you cannot at anytime
consume the <ENTER> key event in KLined, even when KLined handled the event, so
that the browser can determine whether it needs to open URL or not.  I am
thinking that programming for this can get complicated very quickly.  Am I
wrong ??

Moreover,  many users would be royally confused that the <ENTER> key or
any other key combination for that matter does multiple jobs.  Users normally
have come to expect that press the <ENTER> key would led to the execution of
something.  Thus, IMHO this proposal might even complicate the issue further
for them.

I think the auto completion as suggested by Reginald in combination with the
existing manual-completion and the ability for the user choose whichever
one they like is the best route ...  

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]