Image adjustment after cropping

[Sven Langkamp]

On Wed, Jan 30, 2013 at 8:30 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
> 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.

Actually I kind of liked it that way as the cropped area does stay
exactly where it was and it doesn't jump to a centered position.

> 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
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>