[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nebula-dev] Search and auto-complete widgets
- From: Jeremy Dowdall <jeremyd@xxxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 08:15:36 -0600
- Delivered-to: email@example.com
- User-agent: Thunderbird 220.127.116.11 (X11/20060609)
Thank you for the follow up Sascha, with so much to keep tabs on it is a
The generalized use-case for the "complete-in-place" style
auto-completion is for navigating very simple choices by very
"un-computer-savvy" personnel. The choices may (and likely will be) as
simple as "did I file them under Accountant, or Accountants?", and the
average user would, 1. not remember to press ctrl-space to bring up a
list of options, and 2. would be startled by a list automatically
popping up, and (most importantly, and unfortunately, IMHO) 3. not take
the time to learn any of this.
The actual handling of the text, selection, and cursor (and mouse)
movements of the complete-in-place was more of a headache than I
anticipated, but nothing compared all of the lower level functionality
that field assist appears to provide. In the coming weeks I'll be
looking at it more closely and will probably provide my additional
function on top of field assist.
If others find they could use this type of auto-complete, I can always
resubmit it (whatever its new form will be) as a contribution in the future.
Sascha Zelzer wrote:
> Hi Jeremy,
> as far is I understood it, the jface field assist package is all about
> opening a popup with proposals for completing a given content (plus all
> the stuff like auto-activation keys, filtering, proposal navigation and
> so on). I think it was designed to generalize the "code completion"
> functionality, like it is present in JDT and the
> "auto-complete" scenario is just a special case.
> I am not very familiar with the OpenOffice autocompletion, but
> completing the word in place (without showing any popup at all) seems to
> me only appropriate if there is just one possible completion (or given
> an ordering of the proposals according to their relevance, the first one
> being significantly higher relevant then the others). Anyway, completing
> in place could be implemented rather easily, compared to all the other
> issues which are linked to using a popup - but please correct me if I am
> As for your second question, I guess you can. According to the Javadoc
> of ContentProposalAdapter:
> * Indicates that the contents of the control should not be modified
> when a
> * proposal is chosen. This is typically used when a client needs more
> * specialized behavior when a proposal is chosen. In this case, clients
> * typically register an IContentProposalListener so that they are
> * when a proposal is chosen.
> public static final int PROPOSAL_IGNORE = 3;
> Another thing which I find quite useful is, that the proposals shown to
> the user do not have to reflect the actual contents of the proposal. You
> just present a label for the proposal.
> Note also that for the auto-completion case, there have been some issues
> which did not make it into 3.2, but will likely be backported (see
> Hope this helps,
> Jeremy Dowdall wrote:
>> ditto :)
>> can I use it to do auto-completion similar to OpenOffice.org (best
>> example I can think of) where, rather than dropping a selection list, it
>> completes the word in place?
>> can I also use it with multiple, character delimited, fields per text
>> Chris Gross wrote:
>>> Hi Sascha,
>>> You bring up a good point. I wasn't aware of the new field assist added
>>> to JFace.
>>> Sascha Zelzer wrote:
>>>> I am very excited about the Nebula project and am looking forward to
>>>> some great contributions.
>>>> The only thing which irritates me is the constant mentioning of
>>>> "auto-complete" widgets, be it text-fields, combos or others. I am
>>>> just not sure if the creators of such widgets (and the Nebula team)
>>>> are aware of the package org.eclipse.jface.fieldassist which allows,
>>>> in a very general way, to attach auto-complete functionality to any
>>>> I do not want in any way to diminish the efforts of people who
>>>> implemented such widgets themselves, but for the sake of consistency
>>>> and not duplicating functionality, these "widgets" can (at least now
>>>> in Eclipse 3.2) easily by implemented by programmers themselves.
>>>> If those widgets should be available for Eclipse < 3.2 then, of
>>>> course, one has the create them "by hand".
>>>> Just some thoughts...
>>>> nebula-dev mailing list
>>> nebula-dev mailing list
>> nebula-dev mailing list
> nebula-dev mailing list