Unable to significantly change window size while editing project

[JFritzle]

Describe the bug

Without success, I am trying to make QMS toplevel window significantly bigger to see more within project's diary editor. As soon as I touch a window corner/edge for resizing, dialog window "Build diary ..." re-opens, allowing me to resize window only very, very slightly larger. Even more, after dialog window "Build diary ..." has closed, it immediately re-opens a second time when clicking toplevel window's title bar for moving QMS around on display.

What have you done to circle down the problem?

Issue is due to window manager's option Show window contents while dragging enabled.
If not explicitely disabled, this option is by default enabled by Windows and at least by most modern Linux window managers (Gnome, KDE, Xfce, ...) too.

On platform Windows this global option is to be found and can get customized in Performance Options with elevated privileges:

Enabled option causes resize events to be fired to application while grabbing resize corner or edge until releasing grab. Window manager's intension is to improve visibility experience by updating window's content smoothly while resize is in progress.

As opposed to (most?) Linux window managers, Windows window manager fires much faster and more frequently. Consequence: QMS gets next resize event while updating diary is still in progress, causing immediately to restart diary update while window size has only changed minimally.

This is no problem, if project is rather small and building diary takes only moments. But it is a huge problem, where building diary takes several seconds.

To Reproduce

1. Import attached project
2. Right-click project to edit -> diary gets created
3. Wait until diary tab is ready
4. Grab window edge/corner and try to significantly increase window size
5. Notice that it is at least on platform Windows nearly impossible.

Expected behavior

I expect to be able to significantly change window size while editing project.

Screenshots

Attachments

Tauernradweg.zip

On my 15 year old Windows PC, building diary of attached project takes about 25 seconds.
If issue can not get reproduced on someone's modern PC, I recommend to add to project a reverse track of each of 7 included tracks. Having added these 7 reverse tracks, building diary on my PC takes about 5 minutes.

Tracebacks

Desktop

• OS: in particular Windows
• QMapShack Version: current
• Window Manager: -

Additional context

[JFritzle]

Can anyone confirm this problem?

[kkarsten62]

Can anyone confirm this problem?

My observation when loading and handling your project on Linux Fedora 43 Gnome, Wayland:

• I can use the upper right button "Minimize/Maximize"
• When clicked from maximized to minimized the window is centered in the screen and about 50%
• When minimized I can drag vertically on outer upper border, but not horizontally
• When clicked from minimized to maximized the windows is back to full screen
• When maximized I can not drag by using the corner edges
• On each window sizing the diary is recomputed and the progress bar shows up, only 2-3 seconds on my desktop pc with a good CPU and graphic performance

Just a quick note:
Over the last few years, we’ve made a few adjustments to the GUI layout of the project pages to reduce the amount of horizontal space taken up by the GUI elements. This has improved, but in my view some tab pages still take up too much horizontal space, which has a negative impact on smaller screen resolutions. I can’t say whether this has anything to do with the problem you’ve described.

Hope it helps.

[JFritzle]

Thank you @kkarsten62.
Even with my Ubuntu Linux running in a VM, impact of resizing issue is barely perceptible. This is because Gnome window manager handles Show window contents while dragging rather differently compared to Windows window manager.

[wthaem]

@JFritzle : Used your GPX + all reversed tracks, i.e., tested with 14 tracks using Windows 11 with a good CPU. Diary opens more or less immediately, no "Build diary...". Resizing without any issues and immediately. When using the option "Track mit Details" very short delay with a small window. But this small window disappears before I can read its content.

[JFritzle]

Thank you @wthaem.
I hadn't believed that my PC with 4 cores isn't such a lame duck compared to a modern one.
Perhaps I should think about buying a new one? Being not a gamer, performance has been good enough so far.

[JFritzle]

Unfortunately, I wrongly suspected my poor old PC.
It's the DEM data, that slows down building diary.

Test:

1. Having 4 map view tabs. None of them has DEM activated. Open Project to edit diary -> diary immediatley built and and tab is ready. Thus, no resizing problem.
2. Having 4 map view tabs. One of them has DEM activated. Open Project to edit diary -> diary immediatley built and and tab is ready. Thus, no resizing problem.
3. Having 4 map view tabs. Two of them have DEM activated. Open Project to edit diary -> diary immediatley built and and tab is ready. Thus, no resizing problem.
4. Having 4 map view tabs. Three of them have DEM activated. Open Project to edit diary -> diary takes 20 seconds for build and and tab being ready. Thus, resizing problem.
5. Having 4 map view tabs. All of them have DEM activated. Open Project to edit diary -> diary takes 20 seconds for build and and tab being ready. Thus, resizing problem.

DEM source is exactly same for each map view, a VRT file combining Sonny's GeoTIFFs

• DTM Austria 10m v2 by Sonny
• DTM France 20m v3 by Sonny
• DTM Germany 20m v3b by Sonny
• DTM Italy 20m v2b by Sonny
• DTM Switzerland 10m v2 by Sonny

[JFritzle]

Debugging Windows WM_SIZE messages when Show window contents while dragging is enabled (which is enabled by default), shows WM_SIZE messages arriving in 8 ms interval after arrival of WM_ENTERSIZEMOVE message which marks begin of dragging window's resize corner/edge.
Set by timerUpdateTime->setInterval(20);, building project's diary (re-)starts every 20 ms after function CDetailsPrj::resizeEvent gets resize event received, blocking further resize events while building diary is in progress. During these 20 ms it is nearly unable to significantly resize window. Of course, this does not matter if building takes only a small fraction of a second.

A solution is to increase timer interval by timerUpdateTime->setInterval(500); to 500 ms. During this time it is indeed possible to resize window to required size, whether building project's diary triggers progress dialog or not. Control output shows

...
[QMS] 2026-03-30 19:19:31.061 [info] CDetailsPrj::resizeEvent new size= QSize(666, 522) old size= QSize(666, 521)
[QMS] 2026-03-30 19:19:31.155 [info] CDetailsPrj::resizeEvent new size= QSize(667, 522) old size= QSize(666, 522)
[QMS] 2026-03-30 19:19:31.219 [info] CDetailsPrj::resizeEvent new size= QSize(671, 527) old size= QSize(667, 522)
[QMS] 2026-03-30 19:19:31.288 [info] CDetailsPrj::resizeEvent new size= QSize(690, 537) old size= QSize(671, 527)
[QMS] 2026-03-30 19:19:31.345 [info] CDetailsPrj::resizeEvent new size= QSize(709, 551) old size= QSize(690, 537)
[QMS] 2026-03-30 19:19:31.407 [info] CDetailsPrj::resizeEvent new size= QSize(737, 572) old size= QSize(709, 551)
[QMS] 2026-03-30 19:19:31.472 [info] CDetailsPrj::resizeEvent new size= QSize(765, 590) old size= QSize(737, 572)
[QMS] 2026-03-30 19:19:31.539 [info] CDetailsPrj::resizeEvent new size= QSize(784, 604) old size= QSize(765, 590)
[QMS] 2026-03-30 19:19:31.661 [info] CDetailsPrj::resizeEvent new size= QSize(794, 610) old size= QSize(784, 604)
[QMS] 2026-03-30 19:19:32.169 [info] CDetailsPrj::slotSetupGui begin size= QSize(794, 610)
[QMS] 2026-03-30 19:19:51.873 [info] CDetailsPrj::slotSetupGui end   size= QSize(794, 610)
...

-> everything ok!

But increasing timer interval has an unwanted side effect:
When shrinking window to the smallest possible size, after finishing diary build windows size size jumps to previous size before beginning to resize. Control output shows

...
[QMS] 2026-03-30 19:51:41.469 [info] CDetailsPrj::resizeEvent new size= QSize(793, 610) old size= QSize(794, 610)
[QMS] 2026-03-30 19:51:41.551 [info] CDetailsPrj::resizeEvent new size= QSize(757, 582) old size= QSize(793, 610)
[QMS] 2026-03-30 19:51:41.634 [info] CDetailsPrj::resizeEvent new size= QSize(606, 470) old size= QSize(757, 582)
[QMS] 2026-03-30 19:51:41.694 [info] CDetailsPrj::resizeEvent new size= QSize(535, 360) old size= QSize(606, 470)
[QMS] 2026-03-30 19:51:42.197 [info] CDetailsPrj::slotSetupGui begin size= QSize(535, 360)
[QMS] 2026-03-30 19:52:02.420 [info] CDetailsPrj::slotSetupGui end   size= QSize(535, 360)
[QMS] 2026-03-30 19:52:02.447 [info] CDetailsPrj::resizeEvent new size= QSize(794, 610) old size= QSize(535, 360)
[QMS] 2026-03-30 19:52:02.938 [info] CDetailsPrj::slotSetupGui begin size= QSize(794, 610)
[QMS] 2026-03-30 19:52:23.152 [info] CDetailsPrj::slotSetupGui end   size= QSize(794, 610)
...

-> that something QMS internal triggers a main window resize to previous main windows size after completion of diary. As a result, CDetailsPrj::resizeEvent gets a new resize to previous size QSize(794, 610) making diary build with size QSize(535, 360) obsolete and forcing a new build of diary with previous size QSize(794, 610).
This side effect only occurs when shrinking windows to the smallest size limit. It does not occur when shrinking window nearly to smallest size limit nor does it never occur when increasing window size.

Unfortunately I couldn't find out why main window's resize gets triggered.
@kiozen: Any hint how to prevent main window to get resized after building diary?

Addendum:
As long as progress dialog does not get triggered, even shrinking to smallest size limit works. Seems that progress dialog is responsible for triggering main window's resize event. It turns out, that commenting statement show(); in line 61 of file CProgressDialog.cpp prevents progress dialog from being shown but prevents from triggering main window's resize event too.
Addendum 2:
Not commenting statement show(); in line 61 of file CProgressDialog.cpp but commenting statement setWindowModality(Qt::ApplicationModal); in line 36 prevents from triggering main window's resize event too.