Bug (or feature suggestion) -- scroll (move caret?) to undo position even if change was made programatically

[ftolsson]

This may be by design or not -- but the current behavior is:

If I add/remove/change something via FTOutliner (a section, a synopsis, either entirely or just changing the contents of a line) UNDOING and REDOING works fine which is great.

But if after the operation I move to somewhere else (either by clicking in FTOutliner or by scrolling the page) then hit cmd+z to undo, caret and scroll position stays where I am while changes are performed out of sight. This is arguably quite confusing and inconsistent with undoing within the app.

I probably suspect this is due to the fact that when making changes from outside, the caret "never was in that place to begin with" and thus can't be undone back to where it wasn't.

I also realize now that the same happens if I add a section from Beat's own outline pane -- the caret never goes there, and both the addition and the undo operation takes place out-of-sight. Hm. This may boil down to a question instead of a bug:

Is it our responsibility to move the caret to the place where we make a change, so that the undo feature knows to move us there? Or should undo-redo always move us to the affected place, to alert us to what just happened?

(I would prefer the latter — it would be nice to be able to stay in one place and delete/add an element without going there, as is possible from both your outline and mine. But is there a Mac UI/UX rule that dictates either behavior?)

[lmparppei]

Unfortunately, this is how macOS handles it. If a change was made out of view, it will be undone out of view, too. You might be able to circumvent this by first moving the caret to the place where the changes take place. I'll take a look if I can force the text view to reveal the area that was undone — without the the unwanted side effect of scrolling to anywhere a change was made.

[ftolsson]

Got it. I feared that might be the case.

Perhaps it's an edge case, but I'm currently outlining and having my plugin take up all the screen (obscuring the main Beat window). Sometimes when I use ctrl-tab to get back from another doc I forget that even though my plugin is visibly on top, Beat will be focused below it until I click. So, hitting a key for a command, that character gets entered into the doc instead. Any undoing from that point make me lose my bearings completely... :)

I love that my plugin can go on top of Beat for the very reason of outlining. But might it be useful if a focused Beat window would go on top of any related unfocused plugin window? Or would that break something else?

(Not that this is really a solution to my initial question, but perhaps a workaround and/or simplified behavior.)

Or not. The heat wave is making my brain work very slowly if at all.

[lmparppei]

Implemented in 1.95.0

[lmparppei]

I love that my plugin can go on top of Beat for the very reason of outlining. But might it be useful if a focused Beat window would go on top of any related unfocused plugin window? Or would that break something else?

It's... complicated. Losing the plugin windows behind main window wouldn't be too nice, and also, making the plugin be the first thing to be focused, would break the user experience for many other users.

I don't remember, is there a way to focus the plugin window or editor from code? I could make a plugin event for when the document gets activated, and you could tap into that. Something like Beat.onDocumentBecameMain(...)

Edit: Implemented in 1.95.0 as well

[ftolsson]

I don't remember, is there a way to focus the plugin window or editor from code?

Haha, I was just about to answer but you're fast as always. My overheated brain doesn't really grasp the full width of what you just implemented but I'm looking forward to trying it out!

[lmparppei]

You can now do this:

Beat.onDocumentBecameMain(function () {
    pluginWindow.focus()
})

In this case, whenever your document is focused (from another tab, or even from another app) it focuses the plugin window.

[ftolsson]

Very nice. And it's able to tell if previous focus was the plugin? (So that I'm not redirected back to the plugin in an unescapable cul-de-sac...? :)

BTW, I've been meaning to ask you (and sorry for deviating even further from the subject of the post) if the plugin-windows-are-hidden-when-focusing-other-apps behavior is a choice or an inherent necessity? The are times (development not least, but also when assessing notes in an email or document, or even researching in safari on my second monitor) when it's a bit jarring to have the outline disappear instead of being able to see both...

[lmparppei]

BTW, I've been meaning to ask you (and sorry for deviating even further from the subject of the post) if the plugin-windows-are-hidden-when-focusing-other-apps behavior is a choice or an inherent necessity? The are times (development not least, but also when assessing notes in an email or document, or even researching in safari on my second monitor) when it's a bit jarring to have the outline disappear instead of being able to see both...

Implemented in 1.95.0 as well, and the plugin window previously active should become the key window now, too.

[ftolsson]

Oh, that's just awesome! Next build, I assume, not the one already up? (Downloading it now regardless...) 😊