In Qt >= 5.13, one can override the OS default settings for the display of keyboard shortcuts: https://doc.qt.io/qt-5/qstylehints.html#showShortcutsInContextMenus-prop

0e837d9 sets this to true:

I noticed this issue, which makes it unfit to merge:

It is unrelated to the removal of expandedTo.

Can you reproduce this @maxpietsch ?

What QT version are you using? I can't even configure it with homebrew's latest qt (6.1.1) due to a missing link to the moc executable which is located not in the bin folder in 6.1.1:

➜  brew unlink qt; brew link qt5
➜ ls /usr/local/bin/moc
lrwxr-xr-x  1 mp  admin    29B  7 Jul 12:40 /usr/local/bin/moc -> ../Cellar/qt@5/5.15.2/bin/moc
➜  brew unlink qt5; brew link qt
➜ ls /usr/local/bin/moc
ls: /usr/local/bin/moc: No such file or directory

/usr/local/Cellar/qt@5/5.15.2/bin/moc # exists
/usr/local/Cellar/qt/6.0.2/bin/moc # exists
/usr/local/Cellar/qt/6.1.1/bin/moc # does not exist
/usr/local/Cellar/qt/6.1.1/share/qt/libexec/moc # exists

Edit:

I get the same issue with PATH=/usr/local/Cellar/qt/6.1.1/share/qt/libexec/:/usr/local/Cellar/qt/6.1.1/bin:$PATH ./configure or the 6.0.2 equivalent and a few more deprecation warnings.

Weird... What happens when you resize if the dock widget is blank?

A horizontal resize does not change the behaviour. However, if one undocks the widgets after the first successful open as a docked tool, all works including closing and reopening them.

OK. We may have to revisit the size handling for dock widgets...

What QT version are you using? I can't even configure it with homebrew's latest qt (6.1.1) due to a missing link to the moc executable which is located not in the bin folder in 6.1.1:

I used 6.1.1 as follows:

PATH=$(qmake -query QT_HOST_LIBEXECS):$PATH ./configure && ./build bin/mrview

what about this output:

QPainter::begin: paint device returned engine == 0, type: 2
QPainter::translate: Painter not active
QPainter::rotate: Painter not active

?

Issues confirmed on Linux with Qt6 (6.1.2). I'll have a quick look into it...

OK, I think the empty tool issue is a bug in Qt6 when using vertically-arranged tabs for the dock widgets. @bjeurissen, @maxpietsch: give this last commit a go, see if it fixes the issue for you (does for me on Linux).

Horizontal tabs work on macOS, Qt 6.1.1. However, a few issues I noticed:

• if the connectome tool is opened, the node list is always displayed at the bottom also for other tools
• vertical scrolling of tools seems deactivated, instead, the main window size is enlarged to accommodate the tool. The window height can be reduced somewhat but not beyond the size of the largest opened tool. This is an issue for the connectome tool, in particular.
• other than the connectome tool node list, no tool window can be undocked tools can be undocked by dragging their title, not the tab GUI element above it. This is counter intuitive as dragging the tab element in macOS finder open the tab in a new window.
• opening the view options tool the first time prints the below text to the terminal (this is not the case for the other tools):

QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::translate: Painter not active
QPainter::rotate: Painter not active

OK, I've had a quick go at looking into Qt6 support for the latest dev, and I got it to work on my Arch Linux desktop against Qt 6.4.1 (latest on Arch). It seems to work OK, though I've not done any thorough testing of the issues previously mentioned here (I'd totally forgotten about them, to be honest...).

It did require one major change though: the last commit removes all checks and balances for AVX512 support (which requires 32 byte alignment rather than the default 16). I've been thinking about doing this for a while since we don't compile with AVX512 support by default, and haven't for a long time. My own testing showed a relatively minor difference in performance, and you'll find lots of criticism of AVX512 online (basically it's very power-hungry and often causes performance regressions due to heating-induced CPU throttling).

Removing all this code has the distinct advantage of simplifying the code base somewhat, and not having to explain why our code is peppered with these MEMALIGN macros is a bit of a relief... Moreover, there's a good chance that using C++17 is sufficient to completely avoid these issues, so if anyone is absolutely hell-bent on using AVX512, they should be able to do so simply by using CXXSTD=c++17 ./configure.

So I don't think it's a great loss... I hope everyone is OK with that?

Inconsequential correction: Eigen report that AVX512 may require 64-byte alignment:

For instance, SSE/NEON/MSA/Altivec/VSX targets will require 16-byte-alignment, whereas AVX and AVX512 targets may require up to 32 and 64 byte alignment respectively.

If you've done the testing and not seen a worthwhile improvement in performance with AVX512, I've no issue with removing it; it'll already be absent from the pre-compiled binaries. More generally, I've not delved into the allocation alignment topic as much as you have, so I'll trust your judgement.

Also, I think FFTW might use AVX512; might want to double-check that mrfilter fft is happy?

OK, I've had a quick go at looking into Qt6 support for the latest dev, and I got it to work on my Arch Linux desktop against Qt 6.4.1 (latest on Arch). It seems to work OK, though I've not done any thorough testing of the issues previously mentioned here (I'd totally forgotten about them, to be honest...).

Works on macOS Monterey without any of the previous issues!

Inconsequential correction: Eigen report that AVX512 may require 64-byte alignment:

Ouch. I'm pretty sure we never targeted such large alignment requirements... In fact, looking back at the code, we only ever aligned at 16 bytes... I think we would already have been in trouble with AVX / AVX512 if anyone had ever tried to compile with these instructions...

Also, I think FFTW might use AVX512; might want to double-check that mrfilter fft is happy?

Good point. Though if that's the case, it would have been an issue already: we link against the pre-compiled library, so we have no control over whether it decides to use these instructions. I'm assuming that the FFTW libraries will only use these instructions if it's detected it's running on hardware that supports them, and if it does that, it'll already have done all its required checks and balances.

But you're right, there's a chance that if we pass a structure that doesn't have the expected alignment, when it would have had the expected alignment with the previous MEMALIGN macros in place, then that might cause issues. I note there are no tests in the CI for the FFT filter, most likely because it's currently pretty buggy on master - this was overhauled for #2338, though on the basis of this discussion, it may be worth adding some tests...

640443c will hopefully make this play with qt<5.14 and consequently fix the failing CI on linux and windows.

Qt6 seems to provide a better native HiDPI experience on macOS.

The above is a screenshot at 4k resolution of both Qt5(top) and Qt6 mrview (bottom).