Captain's Log: Stardate 77699.9

Fractal complexity! The visual keyboard note picker should be so simple, but then you realize that it's a top-level window, and thus does not automatically forward keypresses along to the main top-level window that listens for hotkeys like undo/redo (ctrl+z, ctrl+r). Okay, that actually makes sense, because it would break things if the user could e.g. hit "delete" and kill the entities for which they're picking notes.

But you really do want ctrl+z/r to work while picking notes. So then you listen for those hotkeys in the keyboard window (now centralizing the hotkey so if you decide to change it, you won't end up with two different hotkeys for redo). But then you realize that it's really bad if the user can undo things that happened before the window opened! So you have to create some idea of an undo restriction to allow undo/redo to work as expected for note edits, but not for previous things.

Okay so that works... but does it? You write a simple unit test and it fails. It turns out that keeping a simple low-water mark for the redo stack doesn't work, because when the user makes an edit, the redo stack is invalidated (cleared). So now you have to account for that in the undo/redo restrictor thing.

Great, so now that all works, but: undo/redo causes the window to flicker. WTF? Well, it turns out a hack from a few months ago where you're manhandling the keyboard focus has now come back to bite you. Okay, good, there's a TODO from back then about how to actually solve that problem. Not so good is that it involves rewriting JUCE's concertina class from scratch. Which... you know you need to do, but you just don't want to. ;D The flickering fix can wait until later...