Jay, this WORKSFORME on Version: 4.4.0.0.alpha2+
Build ID: 30123b9559e2fb74c9db7d530c538a1c6dc7e32c
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-11-16_00:07:14

Setting to WORKSFORME. Can you double check with the latest nightly build if this persists for you? If so, please do re-open. I can recall, that writer and calc where the first to have the proportional image resizing and Impress indeed was forgotten. But in my test now it worked as expected.

?? Me being confused by how I understand the report of Jay, and how I read the comment from foss ;)

So: the goal is that resizing works the same in all modules?

Hi foss,

I think you maybe misunderstanding the issue. The issue here is that crop shouldnt be scaled proportionately.

Version: 4.4.0.0.alpha2+
Build ID: 2f342c61616418c6ad7303d7f5efa27a28378681
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-16_00:33:40

(In reply to Jay Philips from comment #3)

> I think you maybe misunderstanding the issue. The issue here is that crop
> shouldnt be scaled proportionately.

Ah, it's about cropping :)


CONFIRM: problem is that when you crop with the mouse, it does the same crop at all sided, unless you use Shift+mouse.

Misread title of this bug. Sorry for causing confusion. Yet i still believe proportional image resizing to be the best default. So i disagree with this being an issue.

Apologies. Wow I misread this bug for the 2nd time.

And yes, I do agree with Cor Nouws and Jay that proporional cropping isn't a good default.

Sorry guys!

(In reply to foss from comment #6)

> Sorry guys!

No problem, you can always serve us apple pie ;)
Do you like that too, Jay :)

(In reply to Cor Nouws from comment #7)
> No problem, you can always serve us apple pie ;)
> Do you like that too, Jay :)

Yep i love me some apple pie. :D

Oddly enough, when I tested this in 4.4.0.3 and current master, only the PREVIEW for a crop is proportional.  When you release the mouse button, the resulting crop is not constrained.  In fact, holding shift only changes the preview to be non-constrained and the resulting crop is still unconstrained.  So it is actually currently impossible to get a constrained crop.  

So, the following changes need to be made:
1. Fix the constrained behavior to make the preview while dragging consistent with what is actually set.
2. Reverse the shift-constrain behavior, so the default behavior for crop is to NOT be proportionally constrained.

Whatever the case, it looks like the new crop interface made it into the bibisect-44 repo.  The latest revision in the repo still has the old dialog, so I'll mark this as bibisectednewer.

It might be a little tricky to fix this one since, like everything else in LO, a lot of the code touches other behavior.  For instance, when adjusting image size was flipped to default to being constrained, it also made moving images constrained as well.  My guess is that a similar patch will need to be produced to specifically fix cropping too.

Thanks tmacalp for digging into it more as you are correct that the crop preview is different than the crop that appears when you release the mouse drag.

I had CCed samuel on this as he was the one who implemented the global proportionate changing of images in bug 83808.

Spoke to Qubit about bibisectNewer and he said it is dangerous to use, so i'm reading bibisectRequest and when it eventually gets bibisected, both can be removed.

Would it not - in general - be a good idea to use the Linux dbgutil Bibisect repo (that contains newer versions than the other Bibisect repositories, s. https://wiki.documentfoundation.org/QA/HowToBibisect#Testing_Versions) to bibisect bugs that cannot be bibisected with the "standard" Bibisect repos because the bugs are too new?

Or is this repository not reliable enough? (It is marked as "for testing purposes only.")

@Michael: Yes the latest bibisect repo should work till the current master.

bibisect result:
 4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e is the first bad commit
commit 4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Thu Dec 18 05:59:20 2014 +0100

    2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f

:100644 100644 f0bb717b2ff287197bfaa22233406e60044af9c0 aa66f24ad1e25f64ed7e798652e8b4594c126693 M	build-info.txt
:040000 040000 3c4cf305f1eadbe35f4fac38fff08f51721fef5f 7794c9f8660d711158b277d641aded43ded9a107 M	opt


$ git bisect log
# bad: [ad5ed3c0a2b049c70515c303e8150f5a75dd818f] 2015-02-06: source-hash-004304eb2fd1703d22dec0abf0170bb2ce493d0c
# good: [e4b0a61cedc6ac0e65a4a110fd83edd8295f4856] 2014-11-20: source-hash-d273a60bfdbf9bb7623bed38667ec0647753157c
git bisect start 'master' 'oldest'
# bad: [09b2fa5b1f166e0d6f077325f2ea5fec8c061b47] 2014-12-29: source-hash-4c9cf98819037fdb70cbe68f678f6498d5646736
git bisect bad 09b2fa5b1f166e0d6f077325f2ea5fec8c061b47
# good: [cc11b8ff286074f3edcc650b231c4ed3edaebc2f] 2014-12-09: source-hash-887cb59ac4bfca94f310baee3e9da58ccf9cb3e3
git bisect good cc11b8ff286074f3edcc650b231c4ed3edaebc2f
# bad: [74219a396267b26bfe81f8ea4b9142eb04bb0947] 2014-12-19: source-hash-b7e61384f135f9f513659bcfd2502a9d00acd2f9
git bisect bad 74219a396267b26bfe81f8ea4b9142eb04bb0947
# good: [e0c729d4968b1f602da2944a3324bea9921e4945] 2014-12-14: source-hash-f92183833fa569006602ac7e93c906d2094e0d4d
git bisect good e0c729d4968b1f602da2944a3324bea9921e4945
# good: [2f4a8813051de6bf388715f27cbf832dd3d9bb5b] 2014-12-16: source-hash-990dbcab759265de1497b15a93e53a5fe81ff48d
git bisect good 2f4a8813051de6bf388715f27cbf832dd3d9bb5b
# bad: [4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e] 2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f
git bisect bad 4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e
# good: [4787587b8ee487f6eae6802b89ec40f991457f2c] 2014-12-17: source-hash-cccf45a3d3ea6b06e6c8a507645d23505a91e8d5
git bisect good 4787587b8ee487f6eae6802b89ec40f991457f2c
# first bad commit: [4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e] 2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f



Between those commits, the way of cropping images was changed.
* Before, a separate Dialog to crop the image was shown where you would specify for each side how much of the image should be cropped there.
* Afterwards (now), cropping works with handles at the sides of the image. The image crop tool preview is proportionately, while the result is not.

Created attachment 113448 [details]
screenshot showing the previous dialog to crop images

This screenshot shows the image crop dialog that was used previously.

Cropping an image with right-click crop was changed in bug 86627, but we are looking for crop behaviour differences within the UNO command (.uno:Crop).

*** Bug 89758 has been marked as a duplicate of this bug. ***

I've submitted a small patch to code review that should solve this particular issue:
https://gerrit.libreoffice.org/#/c/15505/

Unfortunately, I noticed many other issues with interactive cropping while testing this bug.  These may be reported elsewhere.

1. Hitting escape does not abort our crop, but applies it instead.

2. It's somehow possible to drag our crop area outside the bounds of the picture.  This will expand a clickable invisible area around our image.

3. There is no easy way to undo our cropping other than undo.  You would have to carefully drag your crop back to the edges of your picture.

4. There is no way to to constrain the resulting crop rectangle.  Even with this bug fixed, it now ACTS like holding shift will constrain proportions while you have your mouse button down, but the actual crop region is determined somewhere else.  Constrained crop really does need to be properly implemented.

(In reply to tmacalp from comment #17)
> I've submitted a small patch to code review that should solve this
> particular issue:
> https://gerrit.libreoffice.org/#/c/15505/

I've tested and pushed your commit and cherry picked it for 4.4.
https://gerrit.libreoffice.org/#/c/15521/

> 1. Hitting escape does not abort our crop, but applies it instead.

True.

> 2. It's somehow possible to drag our crop area outside the bounds of the
> picture.  This will expand a clickable invisible area around our image.

True.

> 3. There is no easy way to undo our cropping other than undo.  You would
> have to carefully drag your crop back to the edges of your picture.

Yes i've suggested we have an uncrop command. (bug 86628)

> 4. There is no way to to constrain the resulting crop rectangle.  Even with
> this bug fixed, it now ACTS like holding shift will constrain proportions
> while you have your mouse button down, but the actual crop region is
> determined somewhere else.  Constrained crop really does need to be properly
> implemented.

True.

Please do submit these bugs and CC me and i'll confirm them.

Seems Trent used the duplicate bug report number when submitting the patch. :D

--------------------------------

Trent MacAlpine committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=18a592a5bfc3c4592b7118cceae774fcc00ae94d

tdf#89758 Interactive crop preview shouldn't scale proportionally

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Linking up the bug reports that Trent has just added and the uncrop bug.

Trent MacAlpine committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c60e9bb90e7954cbdebbf5db8e00ad6879c58f9&h=libreoffice-4-4

tdf#86329 Interactive crop preview shouldn't scale proportionally

It will be available in 4.4.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.