Multi-Monitor context menu

[mrelg]

There is a bug when working with a multi-display setup ( x3)
RMB context menu appears on the wrong display (different from the main window) usually when the main window is on the default display

[pablogventura]

This was fixed in PR #108 (merge of 1.1.1 improvements) and follow-up PR #109 (Windows threshold overflow fix). Please close this issue.

[pablogventura]

Update on multi-monitor context menu placement:

Partial fix in tree (zones): For zone / fill-zone context menus we now anchor the menu using the actual context-menu event position (QContextMenuEvent::globalPos) instead of coordinates that could map to the wrong screen. See ZoneDefaultInteraction::onContextMenuEvent and ZoneContextMenuInteraction (popup uses lastContextMenuScreenPos / cursor fallback)—both reference issue #75 in comments. That targets the main image view RMB workflows for zones.

Still worth validating: Other menus use different code paths. Thumbnail strip / project context menus go through ThumbnailSequence → event->screenPos() from QGraphicsSceneContextMenuEvent and QMenu::exec(screenPos) in MainWindow. On some Qt + multi-monitor setups, scene screenPos() has historically been unreliable. If your problem was only on thumbnails (or only on the page image), please say which—so we know whether the remaining work is in graphics view / scene mapping (e.g. thumbView->mapToGlobal(...)) or already covered.

Please reply with:

1. Where the wrong monitor appears: thumbnails, main page view, both, or other (which panel).
2. OS / desktop (X11 vs Wayland if you know), Qt5 vs Qt6, and approximate Qt version.
3. On current master, is behaviour unchanged / better / worse?

That will tell us whether we can close this after zone fixes or need a follow-up patch for thumbnail / QMenu::exec positioning.

Thanks for the x3-display report—it is exactly the class of setup that exposes these coordinate bugs.

[pablogventura]

Implementation and feedback request are in PR #133: #133

Please try a current build from that branch (or CI artifacts when available) and comment here or on the PR with works / issues / regressions for your use case.

[mrelg]

Hi, first of all, thank you for the flurry of recent bugfix activity! I hope it continues.
Second, I have to notice that not everyone on GitHub is actually a developer, so if you would prefer more of those non-dev software users who reported issues to help with testing, I would suggest uploading temp non-install releases on your PR forks.

I'm a book digitisation/preservation enthusiast, and although I have an EE degree (non-CS/SE), running "cmake --build build, core_tests --run_test=..." is not really my thing.

And again, this is not a critique; it's just a friendly suggestion.

[mrelg]

Also, sorry, I hope you understand the users being slow in testing fixes of 3-year-old issues. We (the users) head to build up a lot of habits and mental workarounds, so as not to be frustrated by our workflows and nonworking interface.

[mrelg]

@pablogventura the last off-topic thing, to be honest, my workfow actualy changes with every single book, because old books don't have as neat of a layout as ones imagined by ST-A design. Maybe it's just OCD talking, but I often fall back on running a book first through the ST-Experimental before ST-Advanced because of the frankly terrible decision of ST-A to focus on flatbed-scanned books and separate dewarping from deskewing as a filter in the output after the margin calculation, which is already jittery by itself for lack of a margin-"master pages" and "Bleed to Margin" feature. But that is just my personal frustration, and a whole different can of worms than just ST-A bugfixes. Maybe I'll find the time to do my own fork after I'm finished with my long-running and never-ending PhD. Good luck with this ST-A endeavour, I'll try participating when time allows.

[pablogventura]

Thanks @mrelg — that context helps.

Different books (especially older ones with irregular layout) often need different workflows; Scan Tailor Advanced was not always flexible enough there, and workarounds like running Scan Tailor Experimental first are understandable.

Multi-monitor context menus: a partial fix is in PR #133 (menu parent set on the thumbnail view). That PR is waiting on community re-test of the deskew/oblique part before merge. When you have time, a build from that branch would be useful feedback — no rush.

We are not expecting every reporter to be a developer; short “what I clicked / what happened” notes are enough. Thanks for the patience while long-standing issues get untangled.

[pablogventura]

Update (May 2026): PR #133 was closed accidentally when its branch was deleted during cleanup — not an intentional drop of this fix.

The P0 work continues in #152 (restored fix/p0-plan-issues, rebased on current master). Please follow #152 for builds and feedback.

This issue remains open until that PR merges and we have confirmation on the relevant workflow.