Quickopen delay

[Sven Brauch]

I'd also like that, but milian probably won't, because you'll still
suffer from lags while typing. And that, after all, was the reason the
timer was introduced.

There seems to be different ways using quickopen, but for my way of
using it, the 150ms delay, although short, is a great hinderance.

Cheers

Am 7. April 2012 20:26 schrieb Aleix Pol <aleixpol at kde.org>:
> On Thu, Apr 5, 2012 at 4:33 PM, Sven Brauch <svenbrauch at googlemail.com> wrote:
>> Hi there!
>>
>> Since a while, we have this 150ms delay for quickopen: only if you
>> type nothing for 150ms or more, the list gets updated. The change was
>> introduced because for large projects, the UI gets sluggish when the
>> list is updated on every keypress.
>>
>> I don't like this change. Especially the outline widget felt much more
>> responsive before, and there the change is totally unnecessary because
>> of the low item-count.
>>
>> The reasons why I find it annoying in particular are:
>>
>>  * If you type something that has no matches. Depending on how fast
>> you type, you may well type four or five more chars before the list
>> gets updated (remember, the timer is reset each time you press a
>> key!), just to see that you need to delete them again. (example: type
>> "foobar" into any document's outliner. I can type the whole word
>> before the list turns empty, telling me there's no matches)
>>
>>  * If you want to continuously delete a part of the expression until
>> more matches appear. It is substantially harder to stop at the right
>> place with the delay. (example: type anything into any file's outliner
>> and try to quickly delete chars at the end until more items appear in
>> the quickopen list, while stopping as soon as that happens)
>>
>> My proposed change is to make the delay depend on how many items need
>> to be searched: https://git.reviewboard.kde.org/r/104486/
>> Milian doesn't like it, arguing that the timeouts are just randomly
>> choosen and that a 150ms delay is unnoticeable anyways (that's why I
>> write this mail, to ask for more opinions).
>>
>> Please, try the two versions (with the patch and without it)
>> side-by-side. It's very hard to imagine the difference if you've been
>> using either version for a while. Some user at IRC yesterday also
>> stated the delay is totally unnoticeable, until he tried the patched
>> version and agreed it feels noticeably smoother with it.
>>
>> Greetings,
>> Sven
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
> Well, I think that here what should happen (and I think it's already
> happening) is just to make sure that after 150ms of the first key
> press the UI should be updated, but not immediately.
>
> 150ms is not too much time.
>
> Aleix
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel