[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [dolphin] [Bug 297458] dolphin in KDE 4.8.2 keyboard search cannot be reset easily as before
From:       Hans Chen <hanswchen () gmail ! com>
Date:       2013-02-27 0:04:50
Message-ID: bug-297458-17878-ZYdxaOZQok () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=297458

--- Comment #28 from Hans Chen <hanswchen@gmail.com> ---
(In reply to comment #27)
> The problem is that QApplication::keyboardInputInterval() is actually
> supposed to mean something completely different, namely, the time after
> which a long key press is interpreted as multiple key presses. I think that
> there is no reason to assume that the value which is good for that delay is
> also the right value for the keyboard search timeout. I really don't
> understand why QAbstractItemview's keyboard search apparently does assume
> that - I guess the engineer who wrote the code just thought that
> "keyboardInputInterval" sounds like it's doing the right thing and did not
> look up what the setting actually means.

Aha, didn't know that. Well for me the default value is about perfect.

> Adding a second setting for the "keyboard search timeout" might make sense
> if it was used everywhere in KDE, but the problem is that everything that
> uses Qt's itemviews (including combo boxes and most lists) uses the keyboard
> search code from QAbstractItemView which uses
> QApplication::keyboardInputInterval().
> 
> Unless we find a way to add a "keyboard search timeout" setting that is
> respected everywhere in KDE, I think that we should probably not make any
> further changes for the time being. Before the timeout was extended, we
> regularly got reports that it is far too difficult to search with multiple
> letters (in fact, many users didn't even know that they can type multiple
> letters because the timeout was so short). I see that the change is less
> helpful for users like you who type fast, but I believe that there are more
> users who benefit from the change, and considering that the search can also
> be aborted by pressing Esc, I consider the issue raised in the original
> report fixed and say that we should close this report.

Yes, I agree that the change is helpful for some users and that the timeout
shouldn't be changed back and forth. Personally I would be happy with a hidden
option to set the delay (e.g. in dolphinrc), but from what I understand you
don't like that (reference: a forum post that I can't find at the moment), and
that's perfectly understandable. So here's another idea:

Introduce a "Filter when typing text" option. When enabled, typing text will
open the filter bar and put that text in the filter textbox. To make it work
better, two changes are needed for how filtering works:
1. It should automatically select the first match.
2. When pressing Enter, open the file or folder. If it's a folder, reset the
filter textbox and hide the filter bar.

This would work as a nice alternative for people who type slower and/or want to
see what they type, while keeping the old way of navigating quickly with the
keyboard for people who prefer that. If filtering seems too different from the
current behavior, just selecting with a textbox (like e.g. Nautilus) is fine as
well - as long as it's an option, or I'll have to patch Dolphin in the
future... ;)

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]