The crop tool allows to select various predefined as well as custom crop ratios. Assuming D11202 will add a way to remember the last used crop setting for the next invocation of the crop tool, it might (or might not) be a good idea to invert the crop ratio in case the image orientation changed. See https://phabricator.kde.org/D11202#226207 ff. for an initial discussion.
> [huoni @ https://phabricator.kde.org/D11202#226409] > QSizeF::transposed() simply returns a new object with width/height swapped. > I don't see how that would help determine which combobox items were under > which Landscape/Portrait heading. I think you don't need to pre-categorize the settings. If height() > width() it is portrait and vice versa. But that doesn't matter while switching the orientation. The corresponding setting for the other mode can be found by just searching the transposed actual QSizeF in the combobox list. >> IMHO a basic change/rewrite of storing and handling the combo box entries >> stands in no relation to the benefits. > > Sorry not sure what you mean. Are you saying that a change/rewrite is fine > to go ahead with regardless? What I meant was that completely changing the combo box code ist much work and it doesn't give that much benefit. If it could be done with a little bit of work it's ok. ;)
> If height() > width() it is portrait and vice versa. There are 4 possible combinations ("I"/"C"): - Landscape image, landscape crop. - Landscape image, portrait crop. - Portrait image, landscape crop. - Portrait image, portrait crop. This means with normalizing we could store the value for C as-is (for I == landscape) and inverted/transposed (for I == portrait) in the config. Anyway, I think we first have to determine whether this behaviour makes any sense at all (and I don't like adding yet another option…).
> I think you don't need to pre-categorize the settings. If height() > width() it is portrait and vice versa. But if I chose This Screen, made a crop, then switched to a portrait image, I would NOT want it to automatically transpose the crop. > Anyway, I think we first have to determine whether this behaviour makes any sense at all (and I don't like adding yet another option…). I think it's a case of some users would want it, some wouldn't. IMO we should leave it as is for now, and revisit after implementing 'save last used ratio'.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!