[Development] [Windows] State of the Qt6 natvis file

[Nicolas Arnaud-Cormos]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250306/837da966/attachment.htm>