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

List:       kde-core-devel
Subject:    Re: Completion (Was: Key management)
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-11-26 22:25:29
[Download RAW message or body]

On Fri, 26 Nov 1999, Carsten Pfeiffer wrote:
> On Thu, Nov 25, 1999 at 06:56:43PM -0500, Dawit Alemayehu wrote:
[snipped]
> There is a KURLCompletion in kdeui.

Ah ha ... it got moved to kdeui from kfm.  I guess I could not find it because I
did not look hard enough :)

> > here is that QComboBox which is used by almost everything now has its own
> > auto-completion feature.  I do not know whether or not this feature is
> > implemented as flexiable in QT as your approach.  Infact it seems to me that
> > only QComboBox has the auto completion feature so it is perhaps local to it
> > only.
> 
> Yes. You can call QComboBox::setAutoCompletion( bool ) for editable
> boxes and whenever you type something that matches an item in the
> combobox, it is auto-completed. So it would be easy to make a KComboBox
> using KCompletion and caring about auto/manual completion issues.

Right. I will do this. I will default to QComboBox's auto-completion if user
wants auto-completion and emit a completion signal for a manual-completion. 
The two types of completions would be mutually exclusive.

> > Hmmm... why would a completion feature require an abstract class and specific
> > implementations for each kind ?  IMHO it should not matter what you are
> 
> No, KCompletion is not abstract at all. KCompletion does just the
> completion-work (i.e. storing all the completable strings, comparing them
> and emitting matches). The new KURLCompletion sits on top of that, reads
> directories or urls and feeds the entries to KCompletion.

Ahhh... I see.

> > mean the content of the QStringList can be a "method signature" or a "list of
> > email addresses" etc... Hence all you would have to do is try to find a match in
> > the list and return that or a NULL if no match is found. Is this right or am I
> > not getting something here ?
> 
> No, this is absolutely correct :) This is what KCompletion does.
>  
> > BTW, I am going to implement a KComboBox which is a simple wrapper around
> > QComboBox that provides "manual" feedback among other features.  So What I
> > think I will do is provide the two signals just link KLined does (completion()
> > and rotation() ) that allows you to connect it to something like KCompletion ...
> 
> Yes, that would be nice. However, I'd rather not have a "rotation" signal,
> but previousMatch() and nextMatch() (see the kcompletion.h I posted, it
> has exactly those slots). Why should the user only be able to rotate in
> one direction?

Okay.  I did not realize until after I posted my response that the reason for
the "rotation" signal in KLined was because it inherited from QLineEdit which
is a simple widget without a drop down box like QComboBox.  Hence, some
function was need to be able to rotate through the list without the need for
drop-down boxes.  Hmmm ... you just gave me an idea.  I will modify KLineEdit
to support this feature as well.

Regards,
Dawit A.

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