Click on a photo to open it in preview mode (F3). The thumbbar is very tall. I try grabbing the handle and scaling it down, but it only lets me scale it up. Workaround: click-drag on the left end of the thumbbar to detach it, and then re-attach it where it was. Now you can scale it down. https://minus.com/m8KXl7Q8D/3f
I'm also experiencing this bug. After re-docking the toolbar, it can be free resized. The current default takes too much room on a small (ish) screen (17").
This problem doesn't appear to be there in the 2.6.0 beta 3 version, that is - it can be scaled down without doing the trick.
That's a negative, I'm running 2.6.0-beta3 and this bug is still present. I didn't mention because I thought it was obvious but perhaps I should explicitly state: the thumbbar has to be horizontal to experience the bug.
Hello, You mean when you initially start digikam and open a photo in preview mode [with horizontal thumbbar at the bottom] you are not able to size it down right ? I am sorry, I am not able to reproduce the problem here. Need someone to confirm this. Varun Herale
That's correct. I can record a screencast for you if you wish, but you got it. To size it down I need to detach it and reattach it, then it can be scaled. (In reply to comment #4) > Hello, > > You mean when you initially start digikam and open a photo in preview mode > [with horizontal thumbbar at the bottom] you are not able to size it down > right ? > > I am sorry, I am not able to reproduce the problem here. Need someone to > confirm this. > > Varun Herale
Ah I uploaded a screencast already in the first post.
Bug still present in 2.6.0-rc I recorded a new screencast for you: http://minus.com/m8KXl7Q8D/4 (click on Download (38.4 MB) if the flash doesn't play) Watch out for the following: 1- I still cannot shrink the thumb bar's height at first. 2- If I detach it by clicking on the left ░ border it floats. I drop it somewhere. Now when I click on the left ░ border I cannot move it around the screen, it will only shrink horizontally. Update: I actually found after recording this new screencast that there seems to a 1 pixel wide edge somewhere in that left ░ border which, when I click on it, allows me to move the window, but you can't expect anybody to hunt for an invisible 1 pixel wide spot to click on to move it! 3- I cannot re-attach it since I cannot move it. 4- The only way to reattach it, as I found by accident, is to double-click on that left ░ border 5- Now that it's re-attached, I can shrink the thumb bar's height. 6- I found another way of shrinking the thumb bar's height - change the widget style from whatever it currently is to anything else. This is NOT a solution (the Oxygen widget style is NOT the problem) because if I change it to anything else and restart digiKam, I again wont be able to shrink the thumb bar vertically - I still need to either detach-and-reattach it, or change the widget style to something else than what it currently is. You can see this in the new screencast: I restarted digiKam and couldn't shrink the thumb bar vertically, so I changed widget styles to anythnig else from what it was (it was Oxygen, I changed it to Cleanlooks) and now I could shrink it. I restarted digiKam and although it was using Cleanlooks, it wouldn't let me resize it. I changed the widget style back to Oxygen and now I could resize it. Again, after restarting, I cant resize it.
Hello, I am sorry, I still can't reproduce it here. http://min.us/mSbN67GX Smit, can you try and check if this problem is there for you ?
Hello No. I cant reproduce it here. I am using digikam-2.6.0-rc.
I can reproduce exactly as the original poster describes. digiKam Version 2.5.0 Using KDE Development Platform 4.8.3 (4.8.3)
Widgets, workspace appearance and theme - Oxygen. digiKam version 2.6.0-rc Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: external shared library LibExiv2: 0.21.1 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.8.1 (4.8.1) LibKExiv2: 2.1.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.0.1 LibLCMS: 119 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.11.32 - external shared library LibPNG: 1.5.10 LibQt: 4.8.1 LibRaw: 0.14.4 LibTIFF: LIBTIFF, Version 4.0.1 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.12.97 (0.13 Release Candidate 2) Parallelized demosaicing: Yes Database backend: QSQLITE LibKface: 2.0.0 LibKipi: 1.3.0 LibOpenCV: 2.3.0 Libface: 0.2
There's custom code which adjusts the minimum size (can't size smaller than 64px thumbs) // Adjust minimum and maximum width to thumbnail sizes. if (flow == TopToBottom) { int viewportFullWidgetOffset = size().width() - viewport()->size().width(); setMinimumWidth(del->minimumSize() + viewportFullWidgetOffset); setMaximumWidth(del->maximumSize() + viewportFullWidgetOffset); } else { int viewportFullWidgetOffset = size().height() - viewport()->size().height(); setMinimumHeight(del->minimumSize() + viewportFullWidgetOffset); setMaximumHeight(del->maximumSize() + viewportFullWidgetOffset); } where some lines like kDebug() << del->minimumSize() << viewportFullWidgetOffset may shed some light on the issue, but without any of the devs being able to reproduce it (which means they can play with it and fix it) it's difficult to fix.
Bug still present in 3.0.0.
Hello Sir Gilles , This bug is actually normal working of the dock widget , which when clicked at edges , is scaled, but not moved. This is why it appears as a bug. For resolving it , there can be two solutions, Either we can increase the width of the handle provided to move the dock , or we can provide a lable bearing "Drag to repostion " , which has a sufficient width , that the chances of clicking at the edge are reduced.
Aman please read the whole issue, I did not mistake anything for a bug, that should be clear from my written descriptions. Pity the screencast links no longer work. All points in comment 7 are now fixed. As for the main issue for this report - not being able to shrink it vertically without doing a detach-reattach trick - it appears to be fixed now, but I'm wary to rush into actually saying "fixed". The reason is that not long ago I found that if I move the strip from the bottom to the top then I can actually shrink it and have digiKam remember that it's shrinked when I restart it, so that's what I did. I don't remember with certainty which version of digiKam I used the last time I reproduced this issue, either 3.0.0 or 3.1.0. I also deleted ~/.kde4 and recreated it, just to make sure it wasn't some Oxygen setting I did, and after that I could still reproduce the bug. This was a few weeks ago. Today I got an email about activity in this bug and tried moving the strip to the bottom and restarting digiKam to reproduce the bug. I couldn't; now the strip works correctly, I can immediately shrink it without detaching it first. So I'm not sure whether it's actually fixed in the code, or whether the fact that I kept it at the top somehow made it "fix itself". I suppose you could mark this as fixed, and I will report back if I ever notice it again.
Sir , Yes Sir , it is right that The solution I provided is actually for the points , 2 and 3 in comment 7.As there was a problem, along with scaling , that we can't move it to re-attach it , which also appeared as a bug and it is still in digikam 3.2 beta version.
DrSlony, It's still valid using digiKam 3.5.0 ? Gilles Caulier
Cannot reproduce in 3.5.0. Thank you for fixing this.