Marvin4JS 6.3

Hi,

Thanks for adding the electron-flow arrows in Marvin4JS! I have a few suggestions for improvement.

1. The program requires that an atom have a visible electron or lone pair. This requirement should not be necessary. If lone pairs are not visible, then the user should still be able to draw a two-electron arrow. The arrow can start at the atom.


2. Even if lone pairs are visible, I have found that it is not possible to start the arrow by clicking on the atom (as opposed to a lone pair). I should be able to start an arrow by clicking on an atom. Marvin can then choose to place the start of the arrow at any of the lone pairs, but preferably on the one that is closest to the cursor.


3. You have implemented a new procedure for drawing an arrow from atom A to an incipient bond between A and B. This new procedure requires that you first draw the arrow pointing to B, then click on it to make it point between A and B. In the case of a two-electron arrow, this procedure is fine, because the meaning of the arrow pointing from A to B is the same as the meaning of an arrow pointing from A to the incipient A–B bond. However, in the case of one-electron arrows, these two drawings have different meanings; the first is a one-electron transfer, and the second is a bond-forming reaction. So in the case of 1-electron arrows, to draw the arrow pointing to the incipient bond, you first have to draw the arrow in a way that means something completely different. I understand why you implemented this two-step procedure -- it reduces the calculational burden and makes it much more clear where one is placing the arrows -- but I think the one-electron arrow case creates a fairly serious problem, in that it will induce users to draw something that they don't really intend to draw. One possible solution: in the case of the one-electron arrow, when the user releases the end of the arrow at atom B, have the arrow automatically snap back to point to the incipient bond, halfway between A and B. Then the user can click on the arrow again to make it point directly to atom B, if that's what the user wants. This approach makes sense because it is far more common to draw a radical bond-forming reaction than to do a one-electron transfer. You could do the same trick in the case of the two-electron arrow, if you want consistency, though here it doesn't matter as much, as both representations have the same meaning.


4. When I draw a two-electron arrow that goes from atom A to an incipient bond between A and B, the head of the arrow should not be halfway between A and B, but about 3/4 of the way from A to B. However, for one-electron arrows, they should point halfway, as they currently do.


5. When an arrow points to an atom, the head of the arrow points to the very center of the atom symbol. It should point to the edge of the letter, not quite touching it.

One other suggestion: When I click on Export to get the MRV, the MRV should be more readable, with return characters and appropriate indentation.

Finally, two questions:

1. I see that the reaction arrows and resonance arrows are graphical objects. Great! Now, when will you implement boxes/rectangles and text boxes?


2. When will you add the ability to add atom maps and the option to make atom maps visible?

Thanks again for this big enhancement.

-- Bob

Hi Bob,

Thank you for your suggestion. I appreciate  it and try to include them in the development plan.

1-2. Can you give me examples when it is important to draw electron flow arrow without having the actual electrons on the canvas? Why do you think it is important? (I am not sure that we can change this behavior easily.)

3. "One possible solution: in the case of the
one-electron arrow, when the user releases the end of the arrow at atom
B, have the arrow automatically snap back to point to the incipient
bond, halfway between A and B."

I think it could work when we start the electron flow arrow from a bond (see the attached figures please). What do you think? Would it be acceptable?

"

I see that the reaction arrows and resonance
arrows are graphical objects. Great! Now, when will you implement
boxes/rectangles and text boxes?

" -- rectangles will be released in 6.4 (July); text box has not been planned yet.

 

Best Regards,

Efi

And the second and third step.

ehoffmann wrote:

1-2. Can you give me examples when it is important to draw electron flow arrow without having the actual electrons on the canvas? Why do you think it is important? (I am not sure that we can change this behavior easily.)

Because when I draw Me₃N, I understand that the N atom has a lone pair. I do not need to draw it to know that it exists and to use it as a source of electrons. 

At the least, if a person clicks on an atom that has no lone pairs displayed, you can automatically add a lone pair (or a single electron in the case of a one-electron arrow) to the atom and have the arrow start from there.

The reason it is important to be able to click on an atom to start the drawing process, even when lone pairs are displayed, is simply logistical. It is sometimes difficult to position the arrow over a particular lone pair of electrons. The atom symbol provides an easier target for a mouse. Just choose an already-displayed lone pair (whichever produces the most esthetically pleasing result) of the atom at which to start the arrow.

ehoffmann wrote:

3. "One possible solution: in the case of the one-electron arrow, when the user releases the end of the arrow at atom B, have the arrow automatically snap back to point to the incipient bond, halfway between A and B." I think it could work when we start the electron flow arrow from a bond (see the attached figures please). What do you think? Would it be acceptable?

I hadn't yet thought about arrows originating from bonds. I was considering arrows originating from atoms. But now that you bring up arrows originating from bonds, it indeed makes no sense for a two-electron arrow to start at a bond X-Y and end at an atom Z; the arrow *must* point to an incipient X-Z or Y-Z bond. So in this case, the current drawing process causes the user first to draw something nonsensical, and then to have to take action to convert it into something that makes sense. This is a recipe for disaster. So I think when a user clicks on the X-Y bond with the two-electron arrow tool, then on atom Z, you must immediately place the arrow so that it points at an incipient X-Z bond. Clicking on the arrow makes it point to the incipient Y-Z bond, and clicking again puts it back at the incipient X-Z bond. In no case should a two-electron arrow point from the X-Y bond directly to Z.

In the case of a one-electron arrow, it is permissible for it to point from the X-Y bond directly to Z, but only after the user cycles through the two incipient bond options.

Getting back to my original point: When a user uses the one-electron arrow tool to lick on atom A, and then on atom B, the arrow should point to an incipient A-B bond. Only if the user clicks on the arrow again should the arrow point directly to atom B. The rationale is that the process of forming a new bond is far more common than a one-electron transfer. It is analogous to automatically adding a + charge when the user places an isolated H atom on the canvas; the program takes the liberty of adding the + charge because the user will almost always want it, and, in the rare cases that the user doesn't want it, she has to take a second action.

ehoffmann wrote:

rectangles will be released in 6.4 (July); text box has not been planned yet.

OK. I need textboxes before I can migrate to Marvin for JS.

You didn't say when atom mapping would be available. I also need this feature.

Atom mapping is available via atom property dialog in version 6.3. (https://marvinjs-demo.chemaxon.com/latest/docs/manual/marvinjs_basic.htm#atomproperties). Currently if your file contains the map, it is visible. (no display option for that.)

About the text box:  May I ask how would you like to use it? Do you need only a simple text mode or would you like to use format options like font type, italics, bold,  subscripts, superscripts etc.?

Best Regards,

Efi

ehoffmann wrote:

Atom mapping is available via atom property dialog in version 6.3. (https://marvinjs-demo.chemaxon.com/latest/docs/manual/marvinjs_basic.htm#atomproperties). Currently if your file contains the map, it is visible. (no display option for that.) About the text box:  May I ask how would you like to use it? Do you need only a simple text mode or would you like to use format options like font type, italics, bold,  subscripts, superscripts etc.? Best Regards, Efi

I need the display option for atom mapping as well. Sometimes we use atom mapping without users' knowledge. If we show the atom mapping, it could be confusing to the user.

For text boxes, all we need is simple text mode. No format options are necessary.

We have implemented the API option and a GUI option ( "View setting dialog" ) to turn off/on atom map visibility. They  will be released in version 14.7.14.

Best regards,

Efi

Yay! Köszönöm!

Any progress on a simple text box? All I need is the ability to place a number 1, 2, etc. wherever I want on the canvas.

Unfortunately, we could not implement textbox yet. I know it is not a nice workaround but could you add the numbers as an alias of a carbon atom?

Best regards,

Efi

No. The feature is not for me to make drawings that other people look at; it's for students to use to place numbers on the page. If I tel them they need to place a C atom on the page, then change it to an alias, they will become so confused.... Plus I would have to recode.

Dear Bob,

Unfortunately this feature is not done yet. Until then i suggest you to use rectangles or ellipses instead. They can be drawn in various colors, although it won't help people with disabilities.

I will just have to wait for the textboxes. Remember, I don't need formatting, just the ability to put simple text (like a number) on the canvas.