KItemListKeyboardSearchManager and QApplication::keyboardInputInterval()

Frank Reininghaus frank78ac at googlemail.com
Wed Mar 28 14:40:43 BST 2012


Peter and Tirtha,

thanks for your feedback!

Am 27. März 2012 22:40 schrieb Peter Penz:
> On 03/27/2012 08:15 PM, Frank Reininghaus wrote:
>>
> [...]
>
> 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 ;-)).

you have convinced me, an increased hardcoded timeout is probably better.

I've just looked at what Nautilus does: they have a hardcoded timeout
of 5 seconds (a #define in
libnautilus-private/nautilus-icon-container.c) and show a line-edit in
the bottom right corner of the view as soon as a letter is typed,
which may come in quite handy if the user wants to edit the search. No
visual feedback is given concerning the time left until the search is
cancelled. Esc can be used to cancel the search manually.

I think that this is quite nice, and adding a "timeout line" would
make it even better. However, I think that such a change should better
not go into a 4.8.x release because of the risk of regressions and
because it's really rather a new feature.

So I would suggest to split this into two parts:

1. Bug fix part: Increase the timeout to a larger value (Nautilus' 5
seconds seem quite reasonable to me) in the 4.8 branch.

2. New feature part: Provide visual feedback about the search string
and possibly also the timeout. Note that the 'repeated key search'
feature does probably not make much sense any more then, I think it's
impossible to combine that with visual feedback without causing
confusion. But I don't know if users use this feature or even know
about it anyway ;-) The reason why I suggested to implement the
repeated key search in the first place was that QAbstractItemView also
has it.

I might look into the visual feedback at some point, but probably not
in the near future, so if some other volunteer shows up, I don't mind.

What do you think about this?

Best regards,
Frank




More information about the kfm-devel mailing list