Improvement of autocompletion

[David Nolden]

2010/11/26 Silvère LESTANG <silvere.lestang at gmail.com>:
>>
>> The things you have to compare are only the upper completion box in
>> KDevelop
>> with the box you see in Qt-Creator. The rest, below, is just normal code
>> completion.
>
> In KDevelop, the above completion pop-up appears only when we press
> Ctrl+space, I think it will be better if it was always displayed. But then
> it's need
> to be smaller than the actual one if we want it to be more useful than
> disturbing
> for the users.
> I suggest that I implement firstly a tooltip like in Qt Creator, where you
> can select the parameters that you want with arrow down and up, and the
> actual parameters in bold. The actual pop-up would be still here if we press
> Ctrl+space.
> If you don't thinks its a good solution, I can make the actual pop-up
> display
> all the time, and then modify it to display only useful information.

Showing the argument-hints always would be easy, however it was simply
too heavy for that until now. The problem is that this all is
implemented in kate, and connected to KDevelop through an interface,
so you cannot simply "show a tooltip instead".

However I agree that it would be nice if we had a very simply popup
above in autocempletion mode, but it should look similar to the
argument-hints in normal code completion for consistency. We show
information which Qt-Creator does not show or even know (how well the
parameters match for example), and this should stay that way.

I think it would be ideal if we would only show the best-matching
argument hint (similar to what Qt-Creator does), and eventually a
selectable "Show more argument hints" button. This is already nearly
implemented. Here's how it could be easily achieved:
- Add a "bool isAutomaticCompletion" argument to
MoreArgumentHintsCompletionItem::resetMaxArgumentHints
- In resetMaxArgumentHints, set the maximum number of argument hints
to 1 if "isAutomaticCompletion == true"

The only remaining issues would be some styling issues that have to be
solved in kate (see kdelibs/kate/completion/kateargumenthinttree.h).
You could style the list in a way so that it looks more like a
tooltip, and make sure that the blue header is not displayed somehow.

>>
>> So, if we compare those two, what's the issue exactly? I'd personally say:
>> The KDevelop solution is too crowded and it looks too similar to the rest
>> of
>> the completion item, even though you cannot execute them.
>>
>> So indeed, we might want to improve this situation by changing the visuals
>> of
>> the pure-informatic items in the group. The question is how, as far as I
>> know
>> the internals it will be quite some work... Afaik it's all in a model and
>> maybe the group-index of the information list could get some flag set that
>> makes it clear that it's pure-informatic.
>>
>> And of course the question is: What's better? The item should still be
>> expandable via the keyboard (so you can read documentation etc. pp.), just
>> like you do know. If we break the visual association, users might not know
>> they can do this...
>>
> How do you expand and collapse item with the keyboard? Left and right arrows
> doesn't work, they make the cursor move.

Try the ALT key (short press for toggling, long press for peeking into
the documentation, ALT+direction for navigation, ALT+enter to execute
something). This works everywhere in the IDE (in the editor window,
quickopen, etc.), it's called "The Magic Modifier" ;-)

Greetings, David