Re: Thumbnail Bar

Le Friday 22 February 2008 19:04:47 Ilya Konkov, vous avez écrit :
> > The selection should probably look more square and shouldn't show the
> > "speed bar" (the bar which appears when one moves the cursor over a
> > thumbnail).
>
> I am not sure what do you mean by square selection. Do original thumbnails
> have such selection? Imho selection hardly can be square if thumbnail has
> size like 100x300, using scale to height. Or do you mean rounded edges?

I meant the rounded edges. For some inspiration you can have a look at 
lightroom interface. Here are two screenshots I googled:
http://www.brandspankingnew.net/img/screenshots/adobe_lightroom.jpg
http://www.leroch.org/images/lightroom/Adobe-lightroom-1.jpg

> Is speed bar/file ops context menu executed by ThumbnailViewHelper? In that
> case we can't use the same helper as for normal thumbnailview. Or probably
> add option to thumbnailview, that will be checked in showContextMenu()?

Speed bar is handled by the item delegate. Context menu is handled by the 
ThumbnailViewHelper.

> > We can't rely on the mouse wheel only for scrolling. There should be
> > another way to scroll: either a thin scroll bar or scroll buttons on the
> > left and right edges of the widget.
>
> Agree. I thought about buttons on edges and about elements which scroll
> just on mouse hover. What do you advice to use for scroll buttons,
> QToolButton? I'd prefer to avoid using scrollbar, but how thin do want to
> use? Something like this: http://eruart.at.nsu.ru/gwenview-thumb-hsb.png
> But possibly with more contrast colors?

Using a separate item delegate would make it possible to remove most of the 
spacing around items, especially on top and bottom. This way the bar remains 
thin even with a scrollbar.

> > ## Fullscreen mode
> > Having two fullscreen bars is confusing, especially since they do not
> > appear the same way: the top bar appears whenever you move the mouse,
> > while the bottom bar appears when you get your mouse close enough to the
> > bottom border. I'd rather merge the two bars to create a layout similar
> > to this (ASCII art):
> >
> > (X)(<)(>)[ 20s ](c) |*** | ** |****|*** | ** |
> > Meta info text      |  **|****| ** |  **|*  *|...
> >
> >                     `-----------v---------------------'
> >                             Thumbnails
>
> Fair enough. But I am not sure if understood ASCII art correctly.
> 1) http://eruart.at.nsu.ru/gwenview-fs-thumb1.png
> 2) http://eruart.at.nsu.ru/gwenview-fs-thumb2.png
> I guess it's 2) screenshot but without large empty black space below meta
> info text, right? If yes, then should it be one widget or two placed near
> to each other?

Yes, it's 2). It should be one big screen-wide bar IMO.

>
> > ## Thumbnail generation
> > We need a way to cache thumbnail generation: right now it seems both
> > views request thumbnails together, meaning the thumbnails are generated
> > twice.
>
> But if a thumbnail is already generated, it won't be generated again?
> Assuming that we use the same thumbnail view helper for both views. Also I
> think we should use this cache to generate thumbnails for those pictures
> that are near current one. For example we have pictures: 1* 2* 3* ... 13*
> 14 15 .. 77 |78| 79 ..
>        '*' -- generated, |N| - current.
> If we have scrolled straight to 78, most possibly thumbnails will be
> generated for 14..77, rather than for 77, 78, 79 ... rest images.

Hum... thinking about it more, I am not sure I didn't misinterpreted the way 
the code would behave. Will check to make sure I am not wrong.

Aurélien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/