[Semi-PATCH] Dolphin - Previews in Tooltips

[Simon St James]

Hi Peter,

On Monday 18 August 2008 06:45:26 you wrote:
> Hi Simon,
>
> Am Sunday, 17. August 2008 16:29:21 schrieb Simon St James:
> > May as well forward this to the list to get some more brains on it while
> > Fredrik recovers from flu :)
> >
> > I've tried to duplicate the KDE3 behaviour of using a very large image
> > for the actual preview, and a small one for when no preview is available:
> > a small preview is, in my experience, not very useful, and nor is a large
> > not-preview ;)
> >
> > This of course causes an issue with the tooltip possibly changing size
> > during its lifespan, which can cause it to go out of screen bounds (or
> > worse - appear under the cursor - try it and see what happens! ;)) as it
> > is currently simply re-drawn at the point at which it was originally
> > requested.
>
> In KDE 3 the tooltip changed its size as soon as the preview had been
> received, which is quite confusing in my opinion. I don't see it as an
> issue if we have a fixed size for previews in KDE 4. Sure: if no preview is
> available (e. g. for a directory) the increased size does not add any
> value, but it also does not harm.
>
> If we go for the approach that the tooltip size depends on the current size
> of the preview (= KDE 3 approach), then a resizing of the tooltip after it
> is already open cannot be prevented. This is because we cannot assure that
> generating of a preview can be done within the ~300 ms where the tooltip
> has been requested but not opened yet.
>
> This especially gets a problem with >= 8 megapixel JPEGs: at least on my
> computer (2 GHz Intel Core Duo) the preview of the JPEG cannot be done
> within the 300 ms (cold disk cache and preview has not been generated once
> -> loading the image from the harddisk is the bottleneck). Here we have the
> rare situation that the performance improvement of computers during the
> last years was slower than the increased size of a "typical photo" because
> of the megapixel-hype.
>
> I personally would prefer having a fixed size for previews to prevent a
> resizing of the tooltip.

Ok, fair enough :) The non-previews look a little pixellated, but as long as I 
get my large and useful tooltips, I'm happy :) There's still re-sizing 
happening, but it's strictly downwards (when the aspect of a preview isn't 
1:1).

The much simpler updated patch is attached: I've had to edit it manually to 
get rid of some other stuff I'm working on, and hope it hasn't got corrupted.  
I should probably look into git at some point :)

I actually implemented my "TODO" at the top of ToolTipManager::showToolTip(), 
and it made the feel much better, especially for already cached previews.  Of 
course, it also meant that preview tasks were started everytime we moved the 
mouse, so I reverted it ;) A happy medium is probably possible, here: 
something like 250ms hover-time to create the tooltip, and then another 250ms 
until it is shown, to give it a fighting chance to get its preview ready.  
The code and memory management will be more intricate, but I think it will be 
worth it to cut out the current jerkiness and flickering.  Any thoughts? I 
volunteer to do the work, of course :)

I also found a bug in the positioning algorithm that the larger previews 
exposed but which is also present without: in details view, with the right 
panel removed, it's possible for an item to take up most of the width of the 
screen, with the result that the tooltip appears half-offscreen all the way 
to the left in its attempt to avoid being drawn in m_itemRect.  I'll have a 
stab at fixing this, too.

Best Wishes,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dolphin-previews-in-tooltip.patch2
Type: text/x-diff
Size: 7708 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20080818/1bb9726a/attachment.diff>