Improvement of autocompletion

Milian Wolff mail at
Fri Nov 26 15:32:54 UTC 2010

David Nolden, 26.11.2010:
> 2010/11/26 Silvère LESTANG <silvere.lestang at>:
> >> 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" ;-)

Which needs documentation and/or some kind to make it known to new users. "Tip 
of the Day"? :D

Milian Wolff
mail at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the KDevelop-devel mailing list