AdjustImage Feature Improvements

[DiapDealer]

On Windows, I notice that I cannot immediately cancel crop mode (Esc key) if I happen to click it experimentally. I have to first click somewhere in the image before the Escape key will exit crop mode. Is this by design? It's probably not something I'm going to use very often, so that's fine if it is. I figured it out fairly quickly anyway. Perhaps focus needs to be changed when the crop button is first clicked?

[KevinH]

Never noticed that, and it is not by design. You are right it is probably a focus issue of some sort.

We do override KeyPress event in AdjustImage so it should capture all keypresses as long as the cursor is somewhere in the AdjustImage widget anyplace. So the toolbar must somehow be interfering by keeping focus on the just pressed crop button.

Clicking on the exact Image should not be needed.

I will look into it.

[BeckyEbook]

I confirm this Esc issue.

I see a different issue.
Step by step:
* Open any image – preferably a larger one, such as a cover.
* Zoom out to below 50% (e.g., 30%).
* Now just click the Crop icon.
The default size of the crop selection is calculated based on the image displayed at 100%, so the selection is too large.
Now, when (with the crop selection visible) you start zooming in on the image, you’ll see that the selection eventually appears in its entirety, and at 100% scale, it will cover exactly 1/4 of the image.

I hope you understand what I’m trying to say.

[KevinH]

Yes, by adding an setFocus back to AdjustImage when crop is pressed seems to fix that issue.

I have just pushed this fix to master.

Thanks!

Originally Posted by KevinH

Never noticed that, and it is not by design. You are right it is probably a focus issue of some sort.

We do override KeyPress event in AdjustImage so it should capture all keypresses as long as the cursor is somewhere in the AdjustImage widget anyplace. So the toolbar must somehow be interfering by keeping focus on the just pressed crop button.

Clicking on the exact Image should not be needed.

I will look into it.

[KevinH]

Originally Posted by BeckyEbook

I confirm this Esc issue.

I see a different issue.
Step by step:
* Open any image – preferably a larger one, such as a cover.
* Zoom out to below 50% (e.g., 30%).
* Now just click the Crop icon.
The default size of the crop selection is calculated based on the image displayed at 100%, so the selection is too large.
Now, when (with the crop selection visible) you start zooming in on the image, you’ll see that the selection eventually appears in its entirety, and at 100% scale, it will cover exactly 1/4 of the image.

I hope you understand what I’m trying to say.

Yes, I have to give the rubberband some initial geometry to work with. Zooming way out may make it too small to see, zooming way in may make it too big or appear outside the viewport.

I am open to suggestions here.

[KevinH]

I guess I got that reversed. I will look into scaling the rubbeband geometry by the current scale factor and see if that helps.

[KevinH]

Okay, that seemed to work. I scaled the initial rubberband (selection rectangle) geometry using the scale factor and that seemed to work just fine for a 30% zoom level.

I have pushed that to master.

Cropping when you are way zoomed out is inherently less accurate then cropping at a zoom of 1.0. But I am sure people realize that.

Thanks for the bug report!

[DiapDealer]

Can confirm that both of the reported issues seem resolved (on Windows --and I assume macOS), now. Thanks!

[BeckyEbook]

A few more minor issues:
1. If we crop an image, Sigil doesn’t recognize that the file has been modified (no asterisk appears in the application’s title bar).
2. When you zoom in (either from the toolbar above the image or from the Sigil UI in the lower-right corner), the status bar below the image doesn’t refresh automatically; it only updates when you hover the cursor over the image.
3. The third issue is more of an aesthetic one: it could multiply the zoom value by 100 and display it as a percentage. While 0.9625 is understandable, my brain prefers to read it as 96.25% (the parentheses are also unnecessary).

[KevinH]

Until you save that image to disk and exit the ImageEditor, no changes to the book have been made. The file watcher should detect the modifications and properly update Book modified just like it does with Open With when a file is actually saved. If not I will have to update the file watcher in some way or just have the save in an ImageTab directly set Book Modified.

As for the zoom and updating, yes it has always been driven by cursor movement. I will look into updating it after each click on any of the zooms.

Not a fan of percentages here, it is a Zoom factor. And it has always been like that so I would prefer to leave it as is.

[BeckyEbook]

Ad 1. Of course! Just cropping the image doesn't mean we've saved it yet!

Ad 2. OK.

Ad 3. OK.

[DNSB]

Old link removed. New compile is available in message#32.

[KevinH]

@BeckyEbook,
I was able to recreate the missing modified change by AdjustImage/ImageTab when that image was no longer being watched for "open with". So I modified the code to create a connection via signals from AdjustImage to ImageTab to MainWindows's Book.

That properly set Book Modified even when the Image file was never watched.

I have pushed that change to Sigil master just now.

Next I will work on updating the status bar info after every use of zoom.

[KevinH]

And I have now pushed changes to update the zoom field in the status bar after every zoom change.

Note: the x,y corrdinates are going to be wonky cause the mouse is actually not inside the Image at all when you are pressing any of the zoom and may not even be inside AdjustImage when using the MainWindow Zoom bar. Not much I can do about that.

So hopefully this fixes things for you.

Thanks!

[BeckyEbook]

I confirm that everything is OK now.