Quickopen delay

[Sven Brauch]

I have two further ideas on how to enhance this without more CPU or
memory usage:
* Cache result sets if there's less than 100 items, or even better:
cache the first 100 items of every result set, display that
immediately, and recalculate the rest on-demand
* Measure the time really needed to filter items, and adjust the
amount of items that can be displayed without delay to that (I'd chose
20ms max or so).

The first one is fancy but probably not worth it because it requires
too much code to maintain. The second one would be a nice, tough.
Optimally, it would be user-configurable (do we have a file with
config entries that are not in the UI?).

Anyway, I'd be happy already if we would push that patch. It really
improves the situation by at least making outline smooth. :)

Greetings

Am 7. April 2012 15:42 schrieb Milian Wolff <mail at milianw.de>:
> On Saturday 07 April 2012 13:34:25 Olivier JG wrote:
>> On Thu 05 Apr 2012 10:33:28 PM CST, Sven Brauch 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
>>
>> I'm with you on this one Sven, the added delay is really bothersome.
>> 150 milliseconds just sounds equally randomly chosen, only bad. If
>> there's a better solution ready, or at least proposed, then fine, but
>> as it stands, even reverting counts as a fix IMO.
>
> Some background from my side:
>
> - to me, quickopen felt really sluggish before when typing in something or,
> more notably, when removing chars. since remember: after every key press it
> would reapply the filter. when removing a char it could not do any assumptions
> and would have to apply the filter to *every* item again
>
> - with the timer in place (note that this is a very common technique, check
> out e.g. kfilterproxysearchline.cpp which even sets a timeout of 300ms...), it
> feels much more natural to me. I type stuff and if I want to see the result I
> just wait for a fraction of a second. the timer is only there to prevent
> useless filtering when you'd type more chars afterwards anyways.
>
> i.e.: if I look for "foo" there is *no* need to search first for "f" and
> "fo"...
>
> so the common ground I found with Sven so far would be to disable the timer if
> there are less then X items in the list (see his updated patch on
> reviewboard). That has the positive sideeffect of having the filter getting
> applied immediately for e.g. outline and really small projects while keeping
> it smooth for large projects.
>
> bye
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>