Bug 203594

I also think this is a very useful option, and I think there's a quite elegant solution to this: making the thumb bar detachable like the toolbars, so that the user can place it either on top, bottom, left, right or make it float.

This can be quite easily accomplished by wrapping the thumb bar in a QDockWidget. I just tried to do this with the thumb bar in the Light Table and it is all quite straightforward. The only change to the ThumbBar class is that a method is added to change the orientation on the fly.

By the way, it is already possible to hide the thumb bar. Just click on the "Show Thumbnails" option in the view menu.

Created attachment 36238 [details]
Make thumbbars dockable

The attached patch implement this idea for the image preview, the image editor, the lighttable and showFoto. The thumbnail bars here can be dragged to any side of the relevant window or floated above it. These states are saved between digiKam sessions.

There turned out to be a few benefits using this approach, apart from the extra freedom it grants the user. It is no longer required to change the orientation in the settings menu, and a restart is no longer required after changing the setting. Also, I think it puts bug 173746 to rest (no more splitters are used and I can't reproduce the problem described there with this patch applied).

This method does however raise the question of where the thumbnail bars should be placed in regard to the other widgets. I implemented the following behavior, which seemed the most logical to me:
- The image and its "metadata siderbar" are considered to be a single entity. A vertical thumbbar is not placed in between these two. A horizontal thumbbar pushes up/down both the image and its sidebar.
- The left sidebar in the main preview window is regarded separate from the image. A vertical thumbbar is placed between the it and the image. A horizontal thumbbar will not push up/down the sidebar.

This patch adds a small support widget for the thumbnail bars, ThumbBarDock which inherits from QDockWidget, which has a similar drag handle as a toolbar.

Pieter,

First, Thanks you very much for your patch. It's very appreciate.

Note : use svn diff > foo.patch to generate patch file, else it will include diff with temp files generated by Qt, as digikamconfig.cpp

You patch do not includes changes for showfoto. It's not very complicated to change. There is also an option in showfoto setup to change thumbbbar orientation, which will become obsolete.

All the rest must be fine. I will test it now...

Thanks in advance for the help

Gilles Caulier

Showfoto do not compile with your patch :

Scanning dependencies of target showfoto
[ 75%] Building CXX object digikam/showfoto/CMakeFiles/showfoto.dir/main.o
In file included from /home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/main.cpp:45:
/home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/showfoto.h:93: error: invalid covariant return type for‘virtual Digikam::ThumbBarView* ShowFoto::ShowFoto::thumbBar() const’
/home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/../utilities/imageeditor/editor/editorwindow.h:171: error:   overriding ‘virtual Digikam::ThumbBarDock* Digikam::EditorWindow::thumbBar() const’
make[2]: *** [digikam/showfoto/CMakeFiles/showfoto.dir/main.o] Error 1
make[1]: *** [digikam/showfoto/CMakeFiles/showfoto.dir/all] Error 2
make: *** [all] Error 2

Do you use code from svn trunk ?

Gilles Caulier

Pieter,

Tested with Album View, Editor and Light Table. Few problem appear :

1/ On LT, thumbbar disappear. No way to restore it.
2/ Editor vertical thumbbar is fine, but horizontal cannot be placed under canvas without to break right sidebbar (as the previous behavior)
3/ With Album view, It's the same than editor : horizontal thumbbar cannot be placed under preview as well.
4/ Default thumbbar place is as toolbar. At least it must follow old setting from rc file and set dockable thumbbar at the right place in layout.
5/ At the first time, after top apply patch, if thumbbar is not displayed from settings file, layout is broken : typically sidebar take whole size.

Best

Gilles Caulier

Screenshots :

http://farm3.static.flickr.com/2468/3832946575_9b21eb58ce_o.png
http://farm3.static.flickr.com/2468/3832945947_98694b529c_o.png
http://farm3.static.flickr.com/2456/3832945803_cc9ac89bc7_o.png
http://farm4.static.flickr.com/3531/3832945655_cb00f7ff4c_o.png

Gilles Caulier

Gilles, for some reason the changes I made in showfoto weren't included in the patch, and that causes the compilation error. I'll look into the other issues and post a new patch soon.

(In reply to comment #4)
> Showfoto do not compile with your patch :
> 
> Scanning dependencies of target showfoto
> [ 75%] Building CXX object digikam/showfoto/CMakeFiles/showfoto.dir/main.o
> In file included from
> /home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/main.cpp:45:
> /home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/showfoto.h:93:
> error: invalid covariant return type for‘virtual Digikam::ThumbBarView*
> ShowFoto::ShowFoto::thumbBar() const’
> /home/gilles/Documents/data/devel/SVN/trunk/graphics/digikam/showfoto/../utilities/imageeditor/editor/editorwindow.h:171:
> error:   overriding ‘virtual Digikam::ThumbBarDock*
> Digikam::EditorWindow::thumbBar() const’
> make[2]: *** [digikam/showfoto/CMakeFiles/showfoto.dir/main.o] Error 1
> make[1]: *** [digikam/showfoto/CMakeFiles/showfoto.dir/all] Error 2
> make: *** [all] Error 2
> 
> Do you use code from svn trunk ?
> 
> Gilles Caulier

(In reply to comment #5)
> Pieter,
> 
> Tested with Album View, Editor and Light Table. Few problem appear :
> 
> 1/ On LT, thumbbar disappear. No way to restore it.
Gilles, I can't reproduce this no matter what I try. Does restarting digiKam
fix this issue? If not, can you send me your digikamrc?

> 2/ Editor vertical thumbbar is fine, but horizontal cannot be placed under
> canvas without to break right sidebbar (as the previous behavior)
> 3/ With Album view, It's the same than editor : horizontal thumbbar cannot be
> placed under preview as well.
If I understand your remarks correctly, this was my question: I think it makes
more sense to tie the metadata bar to the image, and so make it scale in the
same way as with the image view. Apparently, you think it shouldn't :) I will
change that.

> 4/ Default thumbbar place is as toolbar. At least it must follow old setting
> from rc file and set dockable thumbbar at the right place in layout.
The new location is not stored as a neat string, but a base64 encoded string
from QMainWindows's saveState(). I can add some code to apply the old state and
after that delete it from the config file, but this introduced extra 'cruft' in
the code. Please let me know if this is what you want.

> 5/ At the first time, after top apply patch, if thumbbar is not displayed from
> settings file, layout is broken : typically sidebar take whole size.
I don't understand. Can you post a screenshot?

> 
> Best
> 
> Gilles Caulier

Thanks Pieter,

if your patch it included in the next release, I would be happy. The screenshots from Gilles look nice:)

Created attachment 36274 [details]
Where is LT thumbbar ?

To pieter, #8, point 1/

Created attachment 36275 [details]
digiKam rc file with dockable thumbbar bar applied

To pieter, #8, point 1/

To pieter, #8, 

1/ : Note : restarting digiKam do not fix the problem...

2/

>If I understand your remarks correctly, this was my question: I think it makes
>more sense to tie the metadata bar to the image, and so make it scale in the
>same way as with the image view. Apparently, you think it shouldn't :) I will
>change that.

I think no, because this will break compatibility with small screen (eepc for example. At least your patch must follow old behavior to not lost users. Please just set dockable place around preview view (album gui) and canvas (editor) : on top, left, right and bottom. We will see later with users feedback if this can be improved...

4/ 

>The new location is not stored as a neat string, but a base64 encoded string
>from QMainWindows's saveState(). I can add some code to apply the old state and
>after that delete it from the config file, but this introduced extra 'cruft' in
>the code. Please let me know if this is what you want.

Yes, something like that. We remember a lots of problem with splitter size settings to save/restore from rc file, which break layut everywhere. I hope to not see back these problem with your patch. Marcel has working hard to hack these dysfunction. I would to see Marcel's viewpoint here...

5/ I cannot reproduce now. nevermind...

Gilles Caulier

Created attachment 36306 [details]
Make thumbbars dockable

Ok, here's an improved patch (I still didn't use the svn diff trick, will figure that out later. But it should be clean).

Changes:
- The changes to showFoto are included.
- Dock areas are now placed directly around the image views, so the sidebars get full height.
- Old settings for image editor and showFoto regarding thumbnail bar orientation are followed and then removed from config file.

I can't reproduce the error where the thumbnail bar stays hidden in the lighttable window. If I set the "Show Thumbnails" setting in the config file to false, it is hidden (as it should be), but I can get it back by selecting "Show Thumbnails" from the menu. Gilles, can you tell me how you lost it?

Pieter

Pieter,

I just started LT as well. nothing more, LT appears with thumbbar

I will test your new patch soon...

Gilles

Pieter,

I just started LT as well. nothing more, LT appears with NO thumbbar... I want mean...

Gilles

Pieter,

This new patch is really better. all work fine now excepted 2 point :

In editor, when you resize right side bar, splitter do not work very well, and canvas + horizontal thumbbbar is not resized.

In LT, thumbbar do not exist because option to show it is not enabled by default.

That all.

I would to include your patch in 1.0.0-beta4.

Gilles

Created attachment 36328 [details]
broken layout in editor with horizontal thumbbar

Look empty space between right side bar and canvas

SVN commit 1014730 by cgilles:

apply patch from Pieter Edelman to make thumbbar dockable everywhere.
BUG: 203594


 M  +1 -0      CMakeLists.txt  
 M  +37 -65    digikam/albumwidgetstack.cpp  
 M  +7 -4      digikam/albumwidgetstack.h  
 M  +38 -11    digikam/digikamview.cpp  
 M  +1 -0      digikam/digikamview.h  
 M  +29 -14    libs/widgets/common/thumbbar.cpp  
 M  +2 -1      libs/widgets/common/thumbbar.h  
 M  +0 -9      showfoto/setup/setupeditor.cpp  
 M  +50 -51    showfoto/showfoto.cpp  
 M  +1 -1      showfoto/showfoto.h  
 M  +6 -19     utilities/imageeditor/editor/editorwindow.cpp  
 M  +2 -2      utilities/imageeditor/editor/editorwindow.h  
 M  +68 -51    utilities/imageeditor/editor/imagewindow.cpp  
 M  +2 -1      utilities/imageeditor/editor/imagewindow.h  
 M  +48 -25    utilities/lighttable/lighttablewindow.cpp  
 M  +1 -0      utilities/lighttable/lighttablewindow.h  
 M  +5 -2      utilities/lighttable/lighttablewindow_p.h  
 M  +2 -0      utilities/lighttable/lighttablewindowui.rc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1014730

Another issue with the dockable thumbbar:
If you cycle through the images (by pressing the keyboard shortcuts or clicking on the thumbnails in the thumbbar), the thumbbar gets randomly closed. This happens at least in the iconview (where the thumbbar can be hidden).

Gilles, I noticed that you changed the default behavior for the thumbbar in the Lighttable to on, so I regard this issue as fixed now.

I'll look into the empty space problem. I have a hard time reproducing it, but the one time I noticed it, it was gone when I resized the sidebar. I believe it has something to do with restoring the splitter state while from a previous session, so maybe it's not directly fixable. In that case, I think it's best to write some code to detect if this is a transition and if it is, fall back to a sensible default regarding the sidebars.

Andi, I'll notice the same behavior, but I'm certain it worked before. I'll see if I can figure out the cause.

Created attachment 36421 [details]
Keep thumbbar visible/hidden when cycling through photos

This patch should fix the issue that Andi describes, that the thumbbar is hidden (or shown) when cycling through images in the preview view.

SVN commit 1015287 by cgilles:

apply patch to fix thumbbar visibility when cycling through photos.
CCBUGS: 203594



 M  +1 -2      digikam/digikamview.cpp  
 M  +2 -2      libs/widgets/common/thumbbardock.cpp  
 M  +10 -6     libs/widgets/common/thumbbardock.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1015287

Gilles,
I see some layout issues when using the config file from a splitter based digiKam in the dock-based version (which should be fixed), but I can only reproduce the issue with the gap when going the other way around: using the config file from a dock based digiKam in an older, splitter based version.

Do you still remember the version you made the screenshot of?

(In reply to comment #17)
> Created an attachment (id=36328) [details]
> broken layout in editor with horizontal thumbbar
> 
> Look empty space between right side bar and canvas

The rc file have generated with current code from svn, but have an history based on old releases. I don't have cleaned this file for a while. So, it's a typical case which can be found in users area...

Gilles Caulier

Pieter,
there is still an issue with the thumbbar: It doesn't seem to load its state correctly. See the following screenshot:
http://farm3.static.flickr.com/2482/3881294309_055d67424e_o.jpg

I had the thumbbar turned on, restarted digiKam and now it is gone, although the checkbox is set in the menu.

Gilles, Marcel,

somehow I think the action has a bad name, "Show Thumbnails" sounds confusing, some users might think the thumbnails are the items in the iconview. Maybe "Show Filmstrip" or something like that would be more clear?

Andi

>"Show Filmstrip" or something like that would be more clear?

Agree. This must be done in Preview, LT, and Editor. "Show Thumbbar" ?

Gilles

Created attachment 36798 [details]
Convert splitter based thumbbars to dockwidgets

I can only reproduce the reported problems if I alternately use the production version of digiKam with the SVN version. This makes sense: the production version writes a splitter state with three widgets next to each other (thumbbar, main window, and right sidebar), the SVN version then loads this state and applies it to the two widgets and consequently sets the size of the thumbbar to the main widget and such (incidentally, this bug was also present when switching from vertical to horizontal thumbbar, but is solved by using a floatable widget).

This patch detects (in the editor window and showFoto) whether the saved splitter state has three windows, and if so, removes the first size from the list (the thumbbar). This means that the SVN version loads a config file from an older version correctly, but not the other way around. So migrating from an older version to the SVN version shouldn't be a problem, but using an older version after having used the SNV version might screw up the layout.

(In reply to comment #25)
> Pieter,
> there is still an issue with the thumbbar: It doesn't seem to load its state
> correctly. See the following screenshot:
> http://farm3.static.flickr.com/2482/3881294309_055d67424e_o.jpg
> 
> I had the thumbbar turned on, restarted digiKam and now it is gone, although
> the checkbox is set in the menu.
> 

Hi Andi,

I can't reproduce this, so I have two questions:
- Did you use the SVN version both of the times?
- What happens if you click the "Show Thumbnails" button again two times (to hide and then show)?

Pieter

Well since I'm a developer, I always use the SVN version ;-)
I can reproduce this all the time, especially when displaying an image, showing the thumbbar and then switching to another album.
Most of the time the thumbbar then is not visible anymore, although the checkbox is set.

> - What happens if you click the "Show Thumbnails" button again two times (to
> hide and then show)?

It is shown again...

You're right, with these steps I can reproduce it too. I will look into it.

(In reply to comment #29)
> Well since I'm a developer, I always use the SVN version ;-)
> I can reproduce this all the time, especially when displaying an image, showing
> the thumbbar and then switching to another album.
> Most of the time the thumbbar then is not visible anymore, although the
> checkbox is set.
> 
> > - What happens if you click the "Show Thumbnails" button again two times (to
> > hide and then show)?
> 
> It is shown again...

There might be a chance that this bug even existed before your patch. Although I have not recognized it before.
I will checkout some earlier version and use "git bisect" to check for the faulty commit (if there is anyone in a time range of 5 months).

After doing some checks, it is clear that the problem occurred with applying the patch:
http://websvn.kde.org/?view=rev&revision=1014730

Before this commit it is working as expected.

(In reply to comment #26)
> >"Show Filmstrip" or something like that would be more clear?
> 
> Agree. This must be done in Preview, LT, and Editor. "Show Thumbbar" ?
> 
> Gilles

I'll go with "Show Thumbbar" now, it should be clear enough.

Created attachment 36829 [details]
Fix random hides of thumbbar

This patch should fix the problem described by Andi.

SVN commit 1021750 by aclemens:

Apply patch by Pieter Edelman: Fix random hides of thumbbar

CCBUG:203594

 M  +1 -1      digikam/albumwidgetstack.cpp  
 M  +0 -12     libs/widgets/common/thumbbardock.cpp  
 M  +9 -12     libs/widgets/common/thumbbardock.h  
 M  +1 -1      utilities/imageeditor/editor/editorwindow.cpp  
 M  +1 -1      utilities/imageeditor/editor/imagewindow.cpp  
 M  +1 -1      utilities/lighttable/lighttablewindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1021750

The patch seems to work fine, thanks.
I hope we can finally "close" this report now :D

Andi

Well, almost :)
Could you also have a look at patch 36798 to convert configs from the splitter based layouts to dock widget versions?

Thanks,
Pieter

Andi,

do you see previous message from Pieter ?

Gilles

I can look at it, but I don't have any old config files anymore.
From a quick look I would say the patch is ok ;-)

Andi

Pieter, 

as you hae now your svn account, you can apply yourself the patch (:=)))

Gilles

This is a duplicate of bug #192415, so you can close that one, too.

Hmmm since this is the thread where we discussed patches, I will mark your other post as duplicate (although it is older). This one here has also been added to the NEWS file, so I will revert my last commit.

*** Bug 192415 has been marked as a duplicate of this bug. ***

Pieter,

Patch #36798 still in your todo list ?

Gilles Caulier

SVN commit 1024511 by pieteredelman:

Convert (old) splitter based configuration for thumbbar position in the rc files to the (new) dock window based version.
CCBUGS: 203594

 M  +45 -0     editorwindow.cpp  
 M  +1 -1      imagewindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1024511

There, done :)
That should be the end of this bug.

Created attachment 38155 [details]
LT dysfunction again with thumbbar

Pieter,

I'm back there...

In LT, after to update digiKam to 1.0.0-beta6 on my wife computer, when i run LT, i can see that :

http://farm3.static.flickr.com/2590/4082288653_218272c8c6_b.jpg

digikamrc file content is given as attachment

Gilles Caulier

Hmm...seems as though it isn't docked by default. I'll look into it.

Pieter

SVN commit 1046757 by pieteredelman:

Make thumbnail bar in editor en lighttable docked by default instead of floating.

CCBUGS: 203594

 M  +1 -0      digikam/albumwidgetstack.cpp  
 M  +1 -0      utilities/lighttable/lighttablewindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1046757

I tested this with a fresh digikamrc...the thumbbar should be docked by default now.

yes, i confirm.

Gilles

I've tried this out in 1.0.0-beta5 and I'm having problems with moving
the thumb-bar in the image preview. The concept is great, just what I
wanted (in bug #192415), but once the thumb-bar is floating, I find it
is very hard to move it again. When I put the cursor over the "handle"
at the edge of the thumb-bar, I have to position it over the innermost
pixel to make it move, otherwise it just resizes.

Over that "handle", the mouse cursor shows a hand (with a pointing
finger), but it does not differ between resizing and moving. However,
if I move the mouse over the thumbnails, it shows a resizing cursor
(two arrows, with no line between them, though) with either a horizontal
or vertical orientation depending on whether I entered the floating
thumb-bar from the side or the top. If the thumb-bar is docked, I just
get a normal (arrow) cursor, but when I move the mouse to the edge, I
get a resizing cursor, which is OK, but it has a line between the
arrows, so it is different to the one I get when the thumb-bar is
floating.

The problem I reported in comment #52 is still prevalent in RC1.