Thank you! I’m always so happy to hear about a happy user!
That’s a neat idea. I was even thinking about doing something like that, but I forgot to. I’d have to figure out how to do that, but I think it’s straightforward.
Unselecting the tools puts the editor into navigate-only mode, which is a read-only mode to avoid editing the move tree by accident. The ability to do this was intentional, but maybe it makes sense to still leave the cut button working, if that’s a use case that you want. The cut button does anyways pop up a confirmation.
It automatically gives the first move depending on the balance of White vs Black stones. However, to set a move of the opposite color as first, you can select one of the “Set Black” or “Set White” buttons and then ctrl+click (sorry, no work-around for touch-only interfaces) to make a move with that color (instead of placing a “set stone”). Then, subsequent moves (with the auto “ying-yang” tool) with follow the alternating color order from there.
Ideally, the editor should also obey and offer a way to set the “next to move” property that is part of the SGF standard, but that is currently unsupported.
In principle, I guess it could be possible to edit the set stones, while there are child branches, but that could lead to some odd and unexpected behavior, since one might inadvertently set a stone in a location where a subsequent move will later overlap (before there is capture to empty that point). Hence, my editor forces a node to have no children before allowing one to edit it with set stones, but the current behavior will just create a new child and edit that one.
The funny thing is that the SGF standard explicitly allows moves to overlap on top of existing stones. My editor blocks entering such moves by default, but will allow it if you click while holding down the “Ctrl” key. Some other SGF editors might give an unrecoverable error message when dealing with such a (technically valid) SGF.
