Summary: | blur: dragging the preview image removes the target frame and leaves only the source frame | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Nadav Kavalerchik <nadavkav> |
Component: | Usability-Drag&Drop | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 0.10.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 0.10.0 | |
Sentry Crash Report: |
Description
Nadav Kavalerchik
2009-01-25 18:24:56 UTC
It's intentional. I let's Andi give more info here... I have set this behaviours in code. Gilles Caulier We set it this way because blur can be very time consuming (30 seconds and more, depending on the image size and the zoom level). Many users were annoyed that moving the slider or the preview image immediately resulted in the preview calculation. So we removed the automatic calculation so that the user can select the preview window and the filter settings and hit "try" to finally see the results. Since the preview is only calculated for the preview window, moving the frame "deletes" the target view, since this data is simply not present. Andi you are so right ! thanks :-) If the zoom level is quite big, it is fast (like in Gimp, the preview seems to be zoomed to 100%). Maybe we will add something similar like in Gimp, where you have this "Preview" checkbox. We will see. For 0.11 we are planning to re-implement the editor preview widget. Andi great idea. thow, you do not want to make too small ;-) The plan is not to copy Gimp's plugin dialog, I only meant the checkbox feature :-) We'll see what will happen, don't know if the others have plans in mind already. Andi |