[Semi-PATCH] Dolphin - Previews in Tooltips

Peter Penz peter.penz at gmx.at
Mon Aug 18 19:13:50 BST 2008


Hi Simon,

[...]
> > 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 :)

If the non-previews look pixelated, we just have to assure to use the correct 
icon size for the non-previews and center them within the available area. I 
have not tried your patch yet, but I think this should be straight forward to 
fix :-)

> There's still re-sizing
> happening, but it's strictly downwards (when the aspect of a preview isn't
> 1:1).

Does resizing make sense at all? From my point of view the problematic point 
with resizing is that the position of the text changes:
- I hover an item where I'm interested in the permissions.
- The tooltip appears and my eyes try to find the "permissions" text.
- Before I can check the permissions, the tooltip gets downsized because the 
aspect of the preview isn't 1:1 -> have to search "permissions" again...

Do I miss here something (as said: I did not try your patch yet)?

> 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 :)

Great :-) From my point of view you can commit the patch (for sure only if 
Fredrik agrees on the changes of KToolTip and KFormattedBallonTipDelegate). 
Before commiting: Please always add a copyright header for new files like 
DolphinToolTip including your name.

> 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 :)

In the Information Panel a similar approach is used like you suggest:
* when hovering an item, a timer is started
* if the timer exceeds, the preview job is started
* if another item is hovered during the timer is not exceeded the timer gets 
stopped and restarted
* if another item is hoverd during the preview has already been started, the 
old preview just gets skipped

> 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.

Thanks in advance!

>
> Best Wishes,
> Simon





More information about the kfm-devel mailing list