TASEmulators
TAStudio marker edit dialogue box spawns in bad locations
In BizHawk 2.9.1, creating a marker (via double clicking or the 'Add marker with text' icon) will spawn the marker edit dialogue box where the mouse cursor is.
This behavior doesn't make sense to me, and it's often in an inconvenient location. By contrast, the 'Edit Marker Text' icon always places the edit dialogue consistently and conveniently in the center of the TAStudio window, but it can't be used to create new markers.
Preferred behavior: all methods of editing marker text place the dialogue box in the same location.
Host env.
- BizHawk 2.9.1; Win11 Home 22H2; Intel/Intel
Oh wait, I just realized I reported this a while ago, and it was resolved as "won't fix": #2369 (edit: seems unrelated --yoshi)
I have some new context here of inconsistent behavior, but I won't be offended if this also resolves the same way.
Ah least the double click behavior was explicitly coded to spawn the dialog box on the cursor location: https://github.com/TASEmulators/BizHawk/blob/4f144c74d47021018bc3252393db8685d98d58c7/src/BizHawk.Client.EmuHawk/tools/TAStudio/MarkerControl.cs#L234-L240
So I wanna say this is intended behavior? I personally don't find this bothersome at all, but arguably the inconsistency in behavior doesn't really make sense.
IMO all modal dialogs should appear centred on their parent window, no exceptions.
IMO all modal dialogs should appear in centred on their parent window, no exceptions.
How many tastudio markers did you create in your life?
it's often in an inconvenient location
Could you elaborate on this? If you move the mouse to click on an icon and the shown dialog box appears directly under the mouse, where's the issue in that?
Late reply (somehow I was unsubscribed from this GitHub issue), but I believe there was an issue of it getting offset when the TAStudio window is near the edge of the screen. I also recall some situations where it would spawn the dialog box in the place it was previously instead of relative to the current window.
In some cursory testing in 2.9.1, I'm not observing either of these two issues (which is weird: maybe they show up only in edge cases or I got confused when filing this issue?), though I do think if the standard is going to be mouse cursor centered, that should extend to the "edit cursor text" button.
feos insisted on the dialog appearing under the cursor—not beside the cell under the cursor, not near the cursor, exactly under it—so I have done so. Clicking (or selecting with the keyboard) the buttons in the right pane does not open it under the cursor. And as a reminder, you've always been able to close the dialog with Enter after typing in a new value.
There are a few instances of FormStartPosition.Manual left in the codebase, but I believe they're all either centred on their "parent Control" (TAStudio piano roll), or take a position from Lua.
I insisted on making it optional so the author of this issue could have their own workflow.
And forcing it to the center when hitting GUI buttons has the same problems as input roll marker clicking: when the dialog height occupies your entire screen and you're looking at the very bottom to click that button, the dialog appears in the middle instead, and looking back and forth every time serves no productive purpose, which is why it was initially attached to cursor position 8 years ago.
So now both parties are equally unhappy I guess.
I've reread the OP once again and it looks like the only problem was that some GUI buttons don't spawn those dialogs under the cursor while others do. That's the problematic inconsistency which needed to be fixed, which I'll do.
In some cursory testing in 2.9.1, I'm not observing either of these two issues (which is weird: maybe they show up only in edge cases or I got confused when filing this issue?), though I do think if the standard is going to be mouse cursor centered, that should extend to the "edit cursor text" button.
Done in 28757bd8bef8633f89f119ab00a2f91e79db936c.