On 03/03/2025 12:16, Jörg Bornemann wrote:
We can probably improve things already by ditching the testing
attempt, but keep in mind that we're dealing with three different
natvis dialects:
- full blown VS natvis
- reduced (or just old?) natvis of cdb
- severely reduced natvis subset of cppdbg for VS Code
The cdb one isn't that important, unless Qt Creator starts to use that.
I would ditch both cdb and cppdbg and focus only on Visual Studio and
cppvsdbg.
That would exclude VS Code users on non-MSVC platforms.
But for starters one could focus on the VS thing.
This is already the case, as the current natvis is using some internals
of std::pairs only available on MSVC.
Anyway, I scratched my itch (it's filling *my* use-case, mileage may vary):
https://github.com/narnaud/natvis4qt
A small utility that installs or updates Qt5 and/or Qt6 natvis files in
known locations:
- MSVC (supports 2019 and 2022), in the Visualizers directory
- Qt dirs, in a natvis directory
From doing that, I realized:
1) Contrary to my first thought, it doesn't make sense to integrate
natvis with the code
- if I had a new visualizer (like QDateTime), I want it for all Qt
versions, not the latest one
- it should be possible to handle multiple versions in the same
natvis file, using Optional or Priority (needs some proper testing though)
2) You need a tool that can handle all Qt versions, not the latest ones
- the tool is completely orthogonal to Qt versions
- it shouldn't follow Qt releases either, as you want the greatest
and latest natvis as soon as possible
- should handle auto-update (I don't want to think I need to update
the natvis file for my Qt 6.5 version I'm using on one project)
3) You need to simplify contributions
- one source of truth (right now, the natvis file in the vscode
extension is behind the one in the Qt vsaddin for example)
- change license (MIT is the license I've seen in all the external Qt
natvis code I found)
- remove namespace (In almost 25 years of Qt, I yet to see someone
using a namespaced Qt... worst case we could introduce them back by code)
- generally speaking, reduce the barrier of entry (no need to dig
into a big repository to find the natvis file to change, just to realize
you need to change it in 2 different locations...)
4) Autotest
- I really like the idea of Squish testing the natvis inside Visual
Studio, that's probably the only way to go
- Ideally an overview of what is working in which Qt versions, but
that's a stretched goal
natvis4qt fills 1), 2) and 3). 4) is outside my reach. The integration
from CMake could also be interesting, but I'm not sure what would be the
best way to do that...
My 2 cents,
Nicolas
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
