Re: Thumbnail Bar

Hello, 

> But I must confess I had a hard time applying them and I am not sure I have 
> it correctly set up. Can you provide a single diff for all changes? (You 
> can include new files in the diff by adding them with "svn add" before 
> running "svn diff".)
Sorry for that. Will take it into account.


> 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?
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()?


> 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?
Btw this panorama is lesser (948K), but still causes bug: 
http://img442.imageshack.us/img442/8871/view2fl2.jpg (in case if you need it)


> ## View mode
> I don't think autohiding is the way to go...
Yes, autohiding is not the best solution. I thought about deactivating the widget when using a tool and then activating it back, but "film strip" button is better.

> ## 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?


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


> That's all for now. I hope you don't mind all these remarks. This is
> great work despite all I said about it! I believe when it's in we can
> remove the "Preview" mode.
That's ok, I expected something like this.

--
Ilya Konkov

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