Quickopen delay

[Milian Wolff]

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
-------------- 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: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120407/517276ea/attachment.sig>