Version: 0.10.0-beta8 (using 4.1.96 (KDE 4.1.96 (KDE 4.2 RC1)), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.26-1-amd64 starting a blur effect, i get the screen divided into target and original frames moving the upper-right preview image removes the target frame. i think they both used to change (slide) together and reflect the place of the moving selection in the main image. pressing "try" button places the frame back with the result. looks like a bug but might be intentional ?
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