Version: 1.0.0-beta2 (rev.: 984512M) (using 4.2.90 (KDE 4.2.90 (KDE 4.3 Beta2)), Kubuntu packages) Compiler: cc OS: Linux (x86_64) release 2.6.28-13-generic Like the other tools, also the crop tool remembers the settings selected by the user when it is opened again. This is a very useful feature when one wants to crop to a particular region on several similar images. Unfortunately, it is not working as expected: When one opens the tool after having cut an image, the previously used parameters (x,y, width, height, aspect ratio) are recalled correctly. But the placement of the selected region is wrong, it seems that this region is always centered at some default location. So the area drawn in the preview does not represent the displayed parameters. Moreover, when editing one of the parameters, the others suddenly change; I think they adapt to the hidden default settings. By the way, it would be cool to have the crop tool in the batch queue manager, too.
Yes, I can confirm the movement of the sliders. This is due to the recalculation of the range for the sliders. It looks weird though and maybe we can find a better solution. The purpose of this is the following: When you move the selection widget on the X-axis, the width needs to change so that you can not set a wider selection than the remaining space would allow to. We could add a timer so that only on releasing the mouse those ranges are re-calculated. About the settings: I already checked that and it should work, but I will take another look later. Andi
SVN commit 989672 by aclemens: Read settings correctly, but now the selection widget is flickering again. I need to add some mechanism to avoid this. CCBUG: 197386 M +8 -5 ratiocroptool.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=989672
SVN commit 989673 by aclemens: To avoid flickering while reading the settings of the RatioCropTool, we need to change the constructor of the ImageSelectionWidget a little bit. We need a flag that turns off selection drawing, and it needs to be set during construction, a simple setter call is not enough. CCBUG:197386 M +36 -15 imageselectionwidget.cpp M +11 -0 imageselectionwidget.h M +14 -7 ratiocroptool.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=989673
The input widgets are totally messed up. Try entering a value for width or height! As soon as you begin to type, its value will be set to zero. Gilles, I don't think we should always change the range here, this is really unusable, you can't enter values nor change the sliders correctly. Maybe we should just set a fixed range (0-10.000 or more) and let the user enter whatever he wants to enter. The widget itself knows what's valid, so it either draws the new selection or just keeps it as it is. What do you think? Andi
This widget is driving me crazy ;-) Right now it is simply impossible to apply the settings. Some work, but orientation is not. It's funny how user opinions differ: For me loading the old settings is not needed and annoying, others again like it. This is one of the tools I would rather suggest to have a "Save settings" checkbox or similar, so that settings are only saved when the user wants to. Right now orientation is applied according to the original orientation of the image. So when you had set the croptool to "portrait", but open up a landscape image, the tool will be set to landscape and ignore your previously saved "portrait" settings. Actually this is good, because I don't want to change orientation all the time, mostly I crop in the orientation the original image is in. So what to do here? Personally I don't like the settings to be read, but this is just me. Reading all settings is not possible at the moment and might be more annoying then helpful. Maybe we should wait until we redesign the imageeditor, and even revert the changes I made above?
@1, Andi Does digiKam really need to prevent inserting incorrect values? This is often driving me crazy: digiKam remembers values from old operation and applies them automatically to new image. I want to insert some values for new operation and cannot because they are impossible in remembered position. Had to reposition crop area and only later change settings. My proposition: don't restrict user input but if operation leads to crop area outside of image change its color to red, or make it blinking. When user tries to crop give dialog with info: "Crop area outside of image" and refuse. Don't know if it helps or make things more complicated :)
That's why I don't like the fact that remember any settings by default. I don't know any program that does this. This is why I disabled that for freeRotation completely. Gimp or Photoshop has the ability to set the currently set values as default values, this is the best way I guess. You just set them if you want to, and if you like the old ones again, you can reset them to the defaults. Settings are remembered during a session, but if you restart the application, they are gone. I think digiKam should act like this, too. This is definitely one important point when discussing the new editor interface. Right now the default saving of settings is driving me crazy, too :D (well sometimes).
@7, Andi +1 for that. Saving of settings should be done on per plugin level and by default turned off.
For me, it was very useful once that settings were remembered by the plugin, because I had a large number of similar images to crop to the same selection. Since this is not yet possible to do in the batchqueue manager, I liked this option. Apart from that, I cannot quite see why remembering settings is bad from a usability point of view. Apparantly it causes trouble from the developer point of view at the moment, but why is it more annoying for a user to adjust his selection from the previous one instead of from a default selection?
Every image has different dimensions, so a selection that was valid for photo A must not be valid for photo B. Maybe it is smaller, maybe it is portrait instead of landscape orientation. Much worse when using rotation for example. You set an angle for the first image, maybe 20 degrees, and you open another one. Now it becomes rotated 20 degrees, although you don't even know if it needs to be rotated. So you reset first and then set the new angle. And so on... there were a lot users complaining that settings are always remembered, and I can confirm that this is annoying in most cases. So we need something that allows saving if the user wants to, but the default should be to not save them.
I prefer that the crop settings be saved. I take hundreds of photos of record albums at a time using a tripod. I position each record the same, within a fraction of an inch. If all goes well, every crop will be exactly the same. I crop each photo using a 1:1 aspect ratio and set the size so that most of the background is removed. Digikam saves the aspect ratio setting, but I must re-do the position and size settings hundreds of times. That's ANNOYING! :) It's also time consuming. And since I'm doing this as part running my business, I guess you can say it's costly. A 'Save Settings' checkbox seems like a no-brainer -- I look forward to seeing this feature in an upcoming release.
Andi, What's missing to implement in this file to close it ? Gilles Caulier
Gandalf, This file still valid using digiKam 2.x serie ? Gilles Caulier
(In reply to comment #13) > Gandalf, > > This file still valid using digiKam 2.x serie ? Seems to be fixed now, thanks! Gandalf