On 13/03/2025 15:52, Jörg Bornemann wrote:
[...]
Let's focus on the next steps. I propose to do the following on our side:
1. Consolidate the two copies of natvis files in the qtvstools repo.
Why do they exist?
2. Remove the namespace from the files and adjust the namespace
replacement code.
3
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 f
On 28/02/2025 12:26, Jörg Bornemann wrote:
On 2/21/25 4:40 PM, Nicolas Arnaud-Cormos via Development wrote:
I think a better solution would be to have the natvis files embedded
into the pdb on Windows, for multiple reasons:
- no need to set a natvis file on VSCode or VS for those not using
Thank you Kai,
I didn't know about this natvis limitation (which makes me wonder what
is the exact use case for embedding a natvis file).
Anyway, I think the rest of my concerns are still valid:
- How to make the natvis file available to anyone or at least more visible?
- How to ease external
ving it hidden inside the
QtVsTool extension is not the best way IMO.
Regards,
Nicolas
Philippe
On Fri, 21 Feb 2025 16:40:40 +0100
Nicolas Arnaud-Cormos via Development wrote:
Hi everyone,
On Windows, for those using Visual Studio or VS Code with MSVC
compiler, the only way to s
n, at least better than right now, would be to have a
repo for the natvis, that could be used by both the VsTools extension
and the VSCode extension.
Not my best choice, but at least it will give a better visibility to it
and reduce the pain to contributions.
Thoughts?
Thanks,
Nicolas
--
failing to find who is the maintainer of the VS plugin, and I added
the only person who touched the file as a reviewer.
Thanks,
Nicolas
--
Nicolas Arnaud-Cormos | Senior Software Engineer & Teamlead
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53,https://www.kdab.com
On 29/01/2020 17:02, Volker Hilsheimer wrote:
On 29 Jan 2020, at 15:20, Benjamin TERRIER wrote:
On Wed, 29 Jan 2020 at 14:10, Cristián Maureira-Fredes
wrote:
but for Windows/macOS this might have three solutions (maybe more):
- Using package managers that provide Qt,
- Download and compile Qt
Hi Thiago,
On 29/01/2020 04:25, Thiago Macieira wrote:
On Monday, 27 January 2020 23:59:10 PST Christian Gagneraud wrote:
And that's really bad news How many wget will get broken?
This cannot be true, Lars, tell me that download.qt.io will still work w/o
login/password. Please!
The source
On 11/06/2019 21:51, André Pönitz wrote:
On Tue, Jun 11, 2019 at 08:47:12PM +0200, Mutz, Marc via Development wrote:
On 2019-06-11 09:48, Lars Knoll wrote:
On 11 Jun 2019, at 09:35, Olivier Goffart wrote:
On 11.06.19 09:17, Lars Knoll wrote:
So, is removing it worth all the hassle to us and
can find him on IRC as "mehdi_", he works for BlackBerry.
Regards,
Nicolas
--
Nicolas Arnaud-Cormos | nicolas.arnaud-cor...@kdab.com | Senior Software
Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts
y using the geo* features/classes in Qt Location, and don't plan
on using the maps and places ones.
Would be indeed nice to split the library in two here.
Nicolas
--
Nicolas Arnaud-Cormos | nicolas.arnaud-cor...@kdab.com | Senior Software
En
ystem. It also has the additional benefit that 3rd parties (i.e.
> RIM) will be able to host the build server and a number of devices for running
> the built unit tests in-situ.
>
> I will file a JIRA task as Rohan suggested so that we can coordinate things
> there.
Maybe worth a
, you can find us in #qt-labs or #qt-creator, and even
better most of the kdabians working on the project are reachable on #qt-qnx.
Cheers,
Nicolas
--
Nicolas Arnaud-Cormos | nicolas.arnaud-cor...@kdab.com | Senior Software
Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4
14 matches
Mail list logo
