Image adjustment after cropping

[Dmitry Kazakov]

Hi, Sven!

I looked in the code. It looks like the problem is a bit more general. When
we do Resize Image or Resize Canvas actions, the canvas is resized on
screen, but the offset does *not* change. This looks actually not quite bad
for these very actions, because the user considers it as "the canvas is
scaled relative to the topleft corner". But this is, of course, not the
best way from the usability point of view. You can actually check this if
you remove all the pan() calls from the KisCropTool. The cropped area will
be moved to the topleft corner of the initial canvas.

So, I guess, we could widen this bug to all the three actions. We would get
the equal requirements for all these actions (Crop, Resize, Rescale):
1) If the zoom mode is Fit{Width,Page}, switch to Fixed Zoom mode of the
same scale
2) Recenter the resulting image on screen without changing transformation
(the center of the image is in the center of screen)

If we generalize these requirements to all the three actions, then the
problems with threaded execution and undo well be solved very easily,
because the code, that handles resizing of the image in the UI (called by
the automatically emitted signal) is placed in one place,
in KisView2::slotImageSizeChanged().

You could probably just add something like (and remove the code from
KisCropTool at all):

m_d->zoomManager->zoomController()->resetToFixedZoom();

m_d->canvasController->setPreferredCenter(widgetSizeRect.center());

m_d->canvasController->recenterPreferred()


The question is whether we need to generalize these actions or not, but I
guess this is quite ok from the UI pov.



On Wed, Jan 30, 2013 at 4:43 AM, Sven Langkamp <sven.langkamp at gmail.com>wrote:

> Hi,
>
>
>
> I have modified the patch for the cropping tool to work with transform
> images without resetting transformation. It's does pan the canvas by
> the widget distance of the crop rect before and the (0,0) image pixel
> after cropping. It still requires an ugly hack that I would like to
> avoid: The new values are not immoderately available after cropping so
> I use a timer to add a small delay. Dmitry do you have an idea how
> that can be avoided? Any signal that tells that the update is
> finished?
>
> Patch is attached.
>
>
>
> Sven
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130130/af398ac9/attachment.html>