Floating Assistants

Olivier JG olivier.jg at gmail.com
Wed Nov 10 01:38:50 UTC 2010


On 11/09/2010 10:38 PM, David Nolden wrote:
> 2010/11/9 Olivier JG<olivier.jg at gmail.com>:
>> On 11/09/2010 07:15 PM, David Nolden wrote:
>>> Regarding the "ignoring": Maybe it would be nice if the assistant system
>>> could remember whether the assistant was hidden, and from then on only show
>>> a mini-float somewhere at the border of the editor, which can be restored
>>> using alt-0.
>> That would certainly be good, though I'd prefer to think about that after
>> this is set.
> The problem is that, if we move the assistants more into the focus of
> the user, we should also at the same time consider how the user could
> get them out of the way. We shouldn't push them on the user, because
> sometimes the assistants may even be wrong, and anyway the user might
> get annoyed.
I was only referring to the assistant remembering to stay hidden. It 
already stays out of the way at least as well as it used to.
>> One of the ideas in doing this was to simplify the information shown right
>> off, I think the tooltips are adequate for when the user wants to see
>> exactly what will happen. Don't you think?
> Tooltips require the mouse, and the switch between mouse/keyboard is
> quite annoying. Maybe we could have 3 assistant-modes:
> - Full: Vertical layout, with the short action-description and button
> on the left, and the long description on the right.
> - Short: Horizontal layout, with only short action-description buttons
> and full description in the tooltips (what you showed)
> - Hidden: Just a little light-bulbish thing at the side
>
> And we could use "ALT +" and "ALT -" (together with according buttons)
> to reduce/increase the amount of info. Then on automatic popups we
> should use "Short" or "Hidden" mode, depending what the user used
> last. What do you think?
Let me start off with saying that I don't think the tooltips will get 
much use at all. I don't think the usual use case will be to study 
generated code that's shown in the tooltip for the 
MissingDeclarationAssistant or the SignatureAssistant. It's there if you 
feel the need to take a look, but usually it's just information 
overload, and it takes up a lot of space for some assistants. I don't 
personally think that it needs to be keyboard accessible.
Now, on the other hand, I'm uncertain about this cursor following thing. 
I'm very open to a better solution. Perhaps I should just take what I've 
done and stuff it over in the bottom-right corner of the screen, and 
then add a stay fscking hidden feature... /me also thinks about: 
http://api.kde.org/4.3-api/kdelibs-apidocs/interfaces/ktexteditor/html/classKTextEditor_1_1ViewBarContainer.html


All said, I prefer your solution to what I have with two caveats:
One is that unless a specific assistant was hidden (rename a specific 
decl, sig assist for a specific sig, specific problem, etc), it should 
by default have the actions immediately accessible (not hidden). I'm not 
sure how much work that will be... I know at least the sigassist would 
need a bit of love to work like this.
The other is that its difficult for me to envision the full view getting 
much use, also, how would it be called up? IMO a tooltip is good enough, 
though perhaps an instant tooltip rather than a pause-tooltip.

-Olivier JG




More information about the KDevelop-devel mailing list