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

List:       kde-core-devel
Subject:    Re: Completion (Was: Key management)
From:       Carsten Pfeiffer <carpdjih () cetus ! zrz ! TU-Berlin ! DE>
Date:       1999-11-26 17:41:49
[Download RAW message or body]

On Thu, Nov 25, 1999 at 06:56:43PM -0500, Dawit Alemayehu wrote:

Hi,
 
> I think this is a great idea.  I think it is even better to do it this way. 

that's what I think, too :)

> Infact, there was a KURLCompletion in kfm that allowed KLined to have
> similar features except KLined had all the key hard coded.  Anyway the problem

There is a KURLCompletion in kdeui.

> 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.
 
> 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.

> 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?

Cheers,
Carsten Pfeiffer
-- 
http://www.geocities.com/SiliconValley/1632/

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