Better behaved previews

[Rafael Fernández López]

On Saturday 19 January 2008 17:47:17, Peter Penz wrote:
> Hi Rafael,
>
> I'm not sure whether you've read my reply/concerns to your previous changes
> of kdiroperator (see attached mail), I've got no answer yet :-(

Oh I don't check the @gmail account anymore... didn't see it, sorry.


> I've just tried your new patch, but it still contains the performance
> regression by generating a preview on each hovering. Beside the performance
> regression there is also a usability regression: it is not possible anymore
> to hover an item and reach the "OK" button without generating a preview
> from another accidently hovered item.

The performance regression should have gone away. Try the latest please. :)

> I think we should stay consistent with the hover behavior of previews ->
> I'd propose to revert the changes in kdiroperator completely and only leave
> the animation effect of kimagefilepreview (I like the effect very much).

For the effect to be done right, almost all changes at kdiroperator were 
needed.

> > - Hover an element: its preview is triggered (we give more preference to
> > the hover events).
>
> Wasn't this the case before also (I mean before the previous committed
> patch of kdiroperator)?

Yes. No change here with the older implementation.

> > - Unhover the element and go to the blank part of the view: the current
> > index preview is triggered again ! (if there were no current index
> > selected, then the last hovered element is kept, this is specially good
> > when previsualizing videos, because you can go to the control bar of it).
>
> This would not be necessary with the old code of kdiroperator: accidently
> previews have not been generated by mouse-moves...

Not "accidental". You have an item selected with the keyboard, and when you 
move your mouse you just see the other items previews. If you leave the 
viewport or it does not hover any other element (blank part) the selected 
item preview is triggered.

On the older solution, you could select an item with keyboard, hover an 
element, unhover it, and have the item selected with a wrong 
previsualization, since the previsualization shown was the last hovered item 
=> confusing.

> > - Clear selection by clicking on the blank part of the view: preview
> > gone.
>
> Why should someone want to clear the preview?

It had a method before I touch anything called "clearPreview()", I just use 
it... :)

> Please don't get me wrong: I'm open for any improvements and changes, but I
> think we should keep this consistent with the way Dolphin does previews
> (this for sure also means that I'm open to adjust Dolphins behavior to the
> file dialogs behavior). 

Dolphin previews don't need to be touched. The changes are for the preview 
widget.


Bye and thanks Peter,
Rafael Fernández López

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080119/9656ae17/attachment.sig>