KItemListKeyboardSearchManager and QApplication::keyboardInputInterval()

[Tirtha Chatterjee]

On Wed, Mar 28, 2012 at 2:10 AM, Peter Penz <peter.penz19 at gmail.com> wrote:
> On 03/27/2012 08:15 PM, Frank Reininghaus wrote:
>>
>> Hi everyone,
>>
>> in Dolphin, when you press a letter on the keyboard (like "a"),  the
>> first file with a name starting with that letter will be the new
>> current item. If you then press "b", the first file whose name starts
>> with "ab" will be the new current item, and so on.
>
> [...]
>
>> I see two possible solutions at
>> the moment:
>>
>> 1. Replace the use of QApplication::keyboardInputInterval() in
>> KItemListKeyboardSearchManager by some longer interval.
>>
>> 2. Maybe better: don't consider a keyboard search as finished when a
>> hardcoded time interval has passed, but when the user presses a
>> non-letter key to change the current item or when a mouse button is
>> pressed.
>>
>> Any thoughts about this?
>
>
> Hm, I'm a little bit skeptical regarding 2: Personally I use the feature
> only by pressing one key. As soon as I need to search something like "abc*"
> I use the filter-bar, so going for 2. would require an additional keypress
> for me and then I don't see a big benefit anymore in comparison to the
> filter-bar...
>

+1 on not implementing 2. I think there is always the filter bar if
you want such control.

> What I had in mind is to show a kind of preview of the typed letters in the
> e.g. upper-right corner including a kind of "timeout-line" that indicates
> when the pressed keys get reset.
>
> E.g. if someone presses 'a' + 'b' within the interval the following preview
> is shown (sorry for the bad ASCII-art):
>  +--------+
>  |   ab   |
>  | ====== |
>  +--------+
>
> The === represents the "timeout-line" and it decreases when no key is
> pressed:
>
>  +--------+
>  |   ab   |
>  | ====   |
>  +--------+
>
>  +--------+
>  |   ab   |
>  | =      |
>  +--------+
>
> If the "timeout-line" is 0, the preview disappears and typing a new
> afterwards (e.g. 'x') will result in:
>
>  +--------+
>  |   x    |
>  | ====== |
>  +--------+
>
> So currently I'd tend to go for 1 and increase the timeout, but also enable
> a kind of preview with this "timout-line" to give a visual hint for the
> user.
>
> Is just a basic idea and I'm not sure whether it works well, but I think it
> would be worth trying it (is of course a lot more work ;-)).

I think this idea will work well, and worth giving a try. Anyways, my
vote goes for a longer keypress and a timeout bar.

>
> Best regards,
> Peter
>
>>
>> Best regards,
>> Frank
>
>



-- 
Regards
Tirtha Chatterjee
KDE developer
http://wyuka.co.cc/