Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed drawing of O in aldehydes. #5515

Merged
merged 6 commits into from
Sep 12, 2022
Merged

Conversation

DavidACosgrove
Copy link
Collaborator

Reference Issue

Fixes 5511

What does this implement/fix? Explain your changes.

Moves the atom label to centre between the 2 lines of the aldehyde double bond.

Any other comments?

Also, makes the change of colour of the two lines match up, which was attempted previously but had a bug in it.
If should how look like this:
image
The minor residual wonkiness in the O position is due to the catch tests not using Freetype. It looks better when drawn with a Freetype font.

@ptosco
Copy link
Contributor

ptosco commented Aug 24, 2022

@DavidACosgrove Thanks for taking care of this. However, in #5511 you can see that previously the aldehyde was being drawn as if it were exocyclic, while here it is still drawn as endocyclic, thought the O is in a better position. Wouldn't it make sense to draw it as exocyclic rather than fixing how it is drawn as endocyclic?

@DavidACosgrove
Copy link
Collaborator Author

I prefer it as it's drawn now, I never liked the way the double bond straddled end of the single bond. Also, and crucially, the guys at Glysade who paid for the latest round of enhancements to the code prefer it. It's the way it's done in at least 1 widely used commercial sketcher.

@ptosco
Copy link
Contributor

ptosco commented Aug 24, 2022

@DavidACosgrove You are right, ChemDraw does the same, and I agree it looks nicer. Thanks Dave for clarifying! Tomorrow I'll make some time to build your PR so I can test it locally.

Copy link
Contributor

@ptosco ptosco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Just a couple of minor suggestions.

auto l2 = (l2s - l2f).lengthSq();
if ((bond->getBeginAtom()->getDegree() == 1 ||
bond->getEndAtom()->getDegree() == 1) &&
!(cols.first == cols.second) && fabs(l1 - l2) > 0.01) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
!(cols.first == cols.second) && fabs(l1 - l2) > 0.01) {
(cols.first != cols.second) && fabs(l1 - l2) > 0.01) {

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Operator != isn't defined for DrawColour. I have thought about making one, but it feels like a bit of code bloat to solve something that is a only a question of ugly style, really, and not used often.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually define the != operator negating the == operator as you did above. I think that makes code using the class a bit more readable as the ugliness stays in the operator definition, but it is definitely not a must.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will put one in. I was in two minds about it when I wrote the code, and your extra vote has convinced me.

if ((bond->getBeginAtom()->getDegree() == 1 ||
bond->getEndAtom()->getDegree() == 1) &&
!(cols.first == cols.second) && fabs(l1 - l2) > 0.01) {
double midlen = sqrt(l1) / 2.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
double midlen = sqrt(l1) / 2.0;
double midlen = sqrt(l1) * 0.5;

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always let the compiler sort out this sort of micro-optimisation. Personally I think the intention is more immediately obvious with / 2.0 than * 0.5 but that might just be me. I can change it if it's house style.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More than a micro-optimization my suggestion was intended for consistency with the * 0.5 that is used a few lines below (line 2799), but again, not a must.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry, I missed that. Consistency within a function is very desirable. I will alter it. If nothing else, that will force another run of the CI checks which will hopefully pass this time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At a quick scan there is pretty much a 50:50 mixture of / 2.0 and * 0.5 through this file. I think I will leave this particular instance, but aim for more consistency in future.

@DavidACosgrove
Copy link
Collaborator Author

I don't think these failures are real. I do all my development on macOS, and it build and tested fine on my machine.

Copy link
Member

@greglandrum greglandrum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@DavidACosgrove
Copy link
Collaborator Author

Confilcts fixed. I'll correct the hashcodes after fixing the conflicts for #5534 after this is merged.

@greglandrum
Copy link
Member

@DavidACosgrove : I fixed the more recent conflicts on this one.
Will merge assuming the CI builds pass.

@DavidACosgrove
Copy link
Collaborator Author

DavidACosgrove commented Sep 11, 2022 via email

@greglandrum greglandrum merged commit 40e27a6 into rdkit:master Sep 12, 2022
@greglandrum greglandrum linked an issue Oct 7, 2022 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regression in the way aldehydes are drawn in current master
3 participants