Re: [Interest] QtWebView: how to ignore ssl errors?
Thank you guys, mitmproxy sounds as an interesting option! Importing test CA on each test platform / device sounds a bit more painful but still good option. пт, 25 окт. 2019 г. в 17:42, Konstantin Tokarev : > > > > 25.10.2019, 17:37, "Thiago Macieira" : > > On Thursday, 24 October 2019 16:42:05 PDT Alexander Ivash wrote: > >> I understand all the theory behind, but still need to ignore errors > >> for test purposes. If it is possible, where can I read how to achieve > >> it? My understanding QtWebView uses native things for Android & IOS > >> and WebEngine for desktop platforms and unfortunately there is no any > >> public API allowing to ignore SSL errors, what I'm missing? > > > > Instead, import your test CA to your test device. That way, the SSL errors > > you're getting won't b errors and there won't be any debug code that you may > > forget to remove. > > Or use tool like mitmproxy, which can be run on another machine. > > -- > Regards, > Konstantin > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Write QSettings to a QString in INI format
> > So I guess I can use QFile to create my own file, do what I need to > > do, then remove it myself when I'm done, but is there any alternative > > way to get what I want - QSetting written to a QString? > > There are overloads of QFile::open() that take a system file handle / file > descriptor. This one can point to memory. Anyhow, I guess you'll end up > with platform specific code there ... But how would I get QSettings to write to there? QSettings doesn't have an open(). All it has is one of its constructors takes a QString as a filename, and then it opens that file under the hood. So all you can pass to QSettings is a file NAME. Not a pointer, not a file handle/descriptor. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Write QSettings to a QString in INI format
> -Original Message- > From: Interest On Behalf Of Murphy, Sean > Sent: Thursday, October 24, 2019 5:53 PM > To: interest@qt-project.org > Subject: [Interest] Write QSettings to a QString in INI format > > I'd like to be able to have QSettings write out my settings to an INI file > format, > but I'd like to avoid writing it to an actual file, instead just writing it to > "something" in memory (for example, a QString, QByteArray, QBuffer, etc.). > > [...] > So I guess I can use QFile to create my own file, do what I need to do, then > remove it myself when I'm done, but is there any alternative way to get what I > want - QSetting written to a QString? There are overloads of QFile::open() that take a system file handle / file descriptor. This one can point to memory. Anyhow, I guess you'll end up with platform specific code there ... Kai ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QtWebView: how to ignore ssl errors?
On Thursday, 24 October 2019 16:42:05 PDT Alexander Ivash wrote: > I understand all the theory behind, but still need to ignore errors > for test purposes. If it is possible, where can I read how to achieve > it? My understanding QtWebView uses native things for Android & IOS > and WebEngine for desktop platforms and unfortunately there is no any > public API allowing to ignore SSL errors, what I'm missing? Instead, import your test CA to your test device. That way, the SSL errors you're getting won't b errors and there won't be any debug code that you may forget to remove. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Strange issue with Qt, OpenGL and remote desktop
Il 25/10/19 08:56, Rainer Wiesenfarth ha scritto: This is (still) QGL..., we have not yet switched to the QOpenGL... classes. Ok, so, to test if my random guess is remotely correct: get your QGLContext and connect to ctx->contextHandle()'s signal called aboutToBeDestroyed (i.e. check if that is getting called before problems appear). It's really a lick-finger-in-the-air kind of guess... HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Strange issue with Qt, OpenGL and remote desktop
On Thu, Oct 24, 2019 at 10:23 PM Giuseppe D'Angelo via Interest < interest@qt-project.org> wrote: > Il 24/10/19 17:57, Rainer Wiesenfarth ha scritto: > > We ran into a reproducible crash that is restricted to a certain > > scenario. The crash occurs in QGlContextPrivate::syncGlState() when > > trying to call glDisableVertexAttribArray(). It seems the function > > pointer is not available. However, there are some other factors involved: > > Very wild guess, maybe remote desktop is somehow issuing a GL context > reset, and the code in question is not prepared to handle it? > > (Are we talking about QGL* classes here or QOpenGL* classes?) > This is (still) QGL..., we have not yet switched to the QOpenGL... classes. Remote desktop is definitely involved in some way, as its Windows 10 version supports OpenGL > 1.1. Probably the graphics driver also, as the issue is related to (older) Nvidia GTX boards. In the meantime we ran the OpenGL Extensions Viewer (version 6.0.5) both locally on one of the affected machines as well as via RDP. Over RDP, it also crashes, during "Querying properties - Forwarding context 4.1" or "... 4.3". So, the root cause seems to be unrelated to Qt (I assumed that earlier), but it would be nice if we could get our application / Qt 5.12.x to cure the symptoms, as at least Qt 5.6.2 did not trigger the crash... Cheers, Rainer -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest