Re: [Development] Can QImage format plugins require QGuiApplication?
Hi, On 4/14/20 1:34 AM, Konstantin Tokarev wrote: The golden rule is that you're not allowed to touch any Qt API without creating a Q*Application object first, unless the documentation says otherwise. Question is whether Q_Core_Application should be sufficient for using and image format plugin, or QGuiApplication/QApplication is required. No, any GUI-related API requires QGuiApplication, and any widget-related API QApplication. My 2 c, -- 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: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can QImage format plugins require QGuiApplication?
14.04.2020, 02:27, "Giuseppe D'Angelo via Development" : > Il 13/04/20 18:50, Kevin Kofler ha scritto: >> Today, a user on #fedora-kde ran across a crash which resulted from: >> * a GTK+/GNOME application (Jami) using (for some reason) QImage to load >> images, without a QGuiApplication or QApplication constructed, vs. >> * a QImage format plugin (QtPBFImagePlugin) using font APIs that require >> QGuiApplication and abort otherwise. >> >> Obviously, one or the other must be wrong. So, who is to blame? > > The golden rule is that you're not allowed to touch any Qt API without > creating a Q*Application object first, unless the documentation says > otherwise. Question is whether Q_Core_Application should be sufficient for using and image format plugin, or QGuiApplication/QApplication is required. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can QImage format plugins require QGuiApplication?
Il 13/04/20 18:50, Kevin Kofler ha scritto: Today, a user on #fedora-kde ran across a crash which resulted from: * a GTK+/GNOME application (Jami) using (for some reason) QImage to load images, without a QGuiApplication or QApplication constructed, vs. * a QImage format plugin (QtPBFImagePlugin) using font APIs that require QGuiApplication and abort otherwise. Obviously, one or the other must be wrong. So, who is to blame? The golden rule is that you're not allowed to touch any Qt API without creating a Q*Application object first, unless the documentation says otherwise. 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can QImage format plugins require QGuiApplication?
On Montag, 13. April 2020 18:50:17 CEST Kevin Kofler wrote: > Hi, > > I have a question concerning development of plugins for Qt, so hopefully it > is not entirely off-topic here: > > Today, a user on #fedora-kde ran across a crash which resulted from: > * a GTK+/GNOME application (Jami) using (for some reason) QImage to load > images, without a QGuiApplication or QApplication constructed, vs. > * a QImage format plugin (QtPBFImagePlugin) using font APIs that require > QGuiApplication and abort otherwise. > > Obviously, one or the other must be wrong. So, who is to blame? > > There is also an additional issue, in that the plugin's check for supported > images is too broad, which leads to it getting (wrongly) automatically > chosen in the first place and triggering the conflict. We have already > reported that one as a bug, because in that case, it is clear who is at > fault: > https://github.com/tumic0/QtPBFImagePlugin/issues/6 > but I do not know whom to blame for the other issue. > > I have looked at the documentation, but I was not able to find a definite > answer to my question there either. I see that, e.g., > QImageReader::supportedImageFormats() is documented as requiring > QApplication, but I do not know whether that is relevant here. > I think supporting QImage without QGuiApplication is supported but not recommended. We have tests for it in qtbase QTEST_*GUILESS*_MAIN. Not sure it is a documented thing though. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote: > The prevailing feeling in the room, when the vote was taken, > was that Qt people MUST BE SMOKING CRACK if they think > the ISO 14882 C++ Standard should or would tiptoe around Qt's > aggressive abuse of lower-case macro names. That Qt has abused > them for a long time makes the abuse exactly that much *less* > excusable. To wit: you cannot claim you didn't know better. While the argument was indeed made that the prolonged time we have had lower-case macros in our public API makes accommodating them less appealing for WG21, the 'prevailing feeling' is something where you speak on behalf of a working group without the authority to do so, and it's highly questionable whether that feeling was as prevailing as you suggest. It also doesn't require smoking crack to suggest that WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before, when the Networking TS and its functions with names like ntohs and htons clashed with macros. > It would not be at all surprising if uses of all the other > abused names--signals, slots, etc--show up in key components > of C++23. Asking the committee to change them could not > reasonably be expected to produce a peaceful outcome. The outcome of this last asking was plenty peaceful. > Marc's proposal is far too modest. Just change the default, > in a single step: eliminate the abusive macros, as any > responsible organization would have done *decades* ago. > (An accompanying apology for past abuse would not be out of > place.) Anybody who wants to keep using the abusive macros > already knows how. They will also know that they are > deliberately choosing to do The Wrong Thing. Why? The users of emit don't care it's a macro, and if they never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path doesn't seem like a user-friendly way to approach it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can QImage format plugins require QGuiApplication?
On Monday, 13 April 2020 13:50:17 -03 Kevin Kofler wrote: > Hi, > > I have a question concerning development of plugins for Qt, so hopefully it > is not entirely off-topic here: > > Today, a user on #fedora-kde ran across a crash which resulted from: > * a GTK+/GNOME application (Jami) using (for some reason) QImage to load > images, without a QGuiApplication or QApplication constructed, vs. > * a QImage format plugin (QtPBFImagePlugin) using font APIs that require > QGuiApplication and abort otherwise. > > Obviously, one or the other must be wrong. So, who is to blame? Not using QGuiApplication, though that clearly makes the Qt API unable to be used outside of an actual Qt application. > I have looked at the documentation, but I was not able to find a definite > answer to my question there either. I see that, e.g., > QImageReader::supportedImageFormats() is documented as requiring > QApplication, but I do not know whether that is relevant here. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Can QImage format plugins require QGuiApplication?
Hi, I have a question concerning development of plugins for Qt, so hopefully it is not entirely off-topic here: Today, a user on #fedora-kde ran across a crash which resulted from: * a GTK+/GNOME application (Jami) using (for some reason) QImage to load images, without a QGuiApplication or QApplication constructed, vs. * a QImage format plugin (QtPBFImagePlugin) using font APIs that require QGuiApplication and abort otherwise. Obviously, one or the other must be wrong. So, who is to blame? There is also an additional issue, in that the plugin's check for supported images is too broad, which leads to it getting (wrongly) automatically chosen in the first place and triggering the conflict. We have already reported that one as a bug, because in that case, it is clear who is at fault: https://github.com/tumic0/QtPBFImagePlugin/issues/6 but I do not know whom to blame for the other issue. I have looked at the documentation, but I was not able to find a definite answer to my question there either. I see that, e.g., QImageReader::supportedImageFormats() is documented as requiring QApplication, but I do not know whether that is relevant here. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
