[Interest] weird QDesignerCustomWidgetInterface behavior
Hi all, I'm developing a designer widget plugin (VMCScrollArea) that inherits from another class (VMScrollArea) whos base class is a QScrollArea. Now when the plugin is added to a dialog in designer, it creates these entries in the custom widget area: VMScrollArea 1 VMCScrollArea VMCScrollArea.h VMScrollArea 1 and as a result, the layouting and the size properties have weird behavior. If i manually change these lines to: VMCScrollArea VMCScrollArea.h QScrollArea 1 all works fine as expected except for a designer message being displayed when editing the ui file: The file contains a custom widget 'VMCScrollArea' whose base class (QScrollArea) differs from the current entry in the widget database (VMScrollArea). The widget database is left unchanged. Now i wonder: where does the information in the widget database come from and what can i do to fix this. Or is this a bug that needs to be filed? Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Another Qt disappointment
On Montag, 3. Mai 2021 16:44:43 CEST Jason H wrote: > I have a load cell. It's a sensor that measures weight. I wanted to make a > quick UI for it in Qt. That went as expected. Then I wanted to put the app > on a spare Amazon Fire tablet rather than tie up a computer with it. > > I was running with Qt 5.15.2, but there's. bug with Bearer in Qt 5.15.2, so > I went to update it, and lo and behold, there is no 5.15.3. It's > apparently, commercial-only. So I figured I'd finally update to Qt 6, > except that after installing, it turns out Qt 6.0 doesn't have > androidextras. > > It's not just me that is disappointed, everyone in the comments at > https://www.qt.io/blog/commercial-lts-qt-5.15.3-released seems disappointed > that 5.15.3 is commercial-only. > > So as I sit here waiting for Qt 6 and Qt 5.15 to uninstall, and Qt 5.12 to > install, I figured that I'd drop this note about how things are going the > wrong way. +1 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Futur of Qt Webengine in Qt 6
On Mittwoch, 14. April 2021 13:11:23 CEST Allan Sandfeld Jensen wrote: > On Mittwoch, 14. April 2021 13:00:01 CEST Frank Hemer wrote: > > On Montag, 12. April 2021 17:35:43 CEST Allan Sandfeld Jensen wrote: > > > On Montag, 12. April 2021 13:20:36 CEST Frank Hemer wrote: > > > > Hi all, > > > > > > > > i wonder what are the plans for Qt Webengine in Qt 6. > > > > > > > > While webkit has been removed and replaced by webengine, there is > > > > still > > > > no > > > > replacement supported by the mingw compiler yet. > > > > As a commercial customer it was disappointing enought this happened > > > > within > > > > a minor release but even more to be told (by commercial support) that > > > > there currently is no replacement available - and no schedule for a > > > > replacement. > > > > > > > > Does this mean we have to go back in time using com interfaces or are > > > > there > > > > other plans on this? > > > > > > The plans for Qt WebEngine in Qt 6 does not include support for mingw. > > > But > > > like Qt 5 we do support building with clang-cl, if you only need to > > > avoid > > > MSVC. > > > > Hmm - regarding qt5, webengine-platform-notes tells me vs2017 version 15.8 > > or later is required. > > So i can't go w/o msvc, can i? > > Clang-cl uses the msvc standard library, but not the compiler itself. > Perhaps we need to update the platform-notes. Hi Allan, thx a lot - this indeed was missing. Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Futur of Qt Webengine in Qt 6
On Montag, 12. April 2021 17:35:43 CEST Allan Sandfeld Jensen wrote: > On Montag, 12. April 2021 13:20:36 CEST Frank Hemer wrote: > > Hi all, > > > > i wonder what are the plans for Qt Webengine in Qt 6. > > > > While webkit has been removed and replaced by webengine, there is still no > > replacement supported by the mingw compiler yet. > > As a commercial customer it was disappointing enought this happened within > > a minor release but even more to be told (by commercial support) that > > there currently is no replacement available - and no schedule for a > > replacement. > > > > Does this mean we have to go back in time using com interfaces or are > > there > > other plans on this? > > The plans for Qt WebEngine in Qt 6 does not include support for mingw. But > like Qt 5 we do support building with clang-cl, if you only need to avoid > MSVC. Hmm - regarding qt5, webengine-platform-notes tells me vs2017 version 15.8 or later is required. So i can't go w/o msvc, can i? Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Futur of Qt Webengine in Qt 6
Hi all, i wonder what are the plans for Qt Webengine in Qt 6. While webkit has been removed and replaced by webengine, there is still no replacement supported by the mingw compiler yet. As a commercial customer it was disappointing enought this happened within a minor release but even more to be told (by commercial support) that there currently is no replacement available - and no schedule for a replacement. Does this mean we have to go back in time using com interfaces or are there other plans on this? Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)
On Montag, 22. März 2021 15:22:37 CET Jason H wrote: > > Even Jason's company, you remember Jason right? QML's biggest, and > > possibly __only__, fan. Even his company dumped Qt. The medical device > > clients I've worked for have also dumped Qt. > > > > It isn't the FUD that is obsolete, just the management of Qt. > > I'm apparently Qt's biggest fan boy? Yes, I still think Qt (and yes, QML) is > rockstar technology. My problems aren't with the API. It's that QtCorp has > chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to > do, it didn't, even when under a commercial license. > > Qt completely delivered is promise in us getting something to market, but > when it was finally feature complete, that something had more native code > in it than Qt, because we were using using Qt just for the UI. Taking that > and writing a UI abstraction to native was not that hard. > > Qt *could have* made that port away so much harder, but because it's mobile > support was so lacking, it was actually quite easy once we put our heads in > it. > > I'm also at a new company and I've suggested Qt up for evaluation, to > replace the patchwork of libraries they are currently using. We will see > how the talks go... I doubt we will be using Qt6, regardless. Roland, what > did those companies move to? > > The problems I want fixed aren't technical. It's with the project's > direction and management. "Open Governance" has not manifest the way I > thought it would. Filling bugs and voting for them got my issues neglected. > The constant relicensing to, of what was LGPL, to be under GPL 3. But these > are issues that can be fixed with the stroke of a pen, or banging on a > keyboard for a bit. > > Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as > a supported platform? A debian package would go along way to introduce > people to Qt there in the hobbyist sector, but it's a > compile-it-for-yourself situation. Qt continues to get beat by HTML5, but > it shouldn't. Especially giving the WebGL plugin. But there just isn't that > effort to enable that segment. There is no grass roots support for Qt as a > result. And with the licensing issues of late, they've ensured that there > won't be. This means that they have to rely on and cater to the big > spenders boys in the market. +1 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] 5.11.3 make install failure
I also realized this (several times in the past) because the make failure happened several hundred lines before but the make process didn't stop. just my 2cent Frank On Monday, 14 January 2019 17:29:58 CET Jason H wrote: > Applying Occam's razor, > I think your make is failing, make install is making the default target > (resuming your broken build, and failing again) and not actually getting to > install? > > Can you confirm your make of the default target ended successfully? > > > Sent: Monday, January 14, 2019 at 9:30 AM > > From: rol...@logikalsolutions.com > > To: interest@qt-project.org > > Subject: [Interest] 5.11.3 make install failure > > > > > > I kick off the 5.11.3 build from source using same environment as the > > previous 5.12.0 failure. Once again, make install, which shouldn't > > compile __anything__ fails with a compilation error after make -j3 ran > > just fine. > > > > What is the point of having configure if make install completely ignores > > it? > > > > g++ -c -pipe -O2 -std=c++1z -fvisibility=hidden > > -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time > > -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow > > -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS > > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS > > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN > > -DQT_SERVICE_SUPPORT_LIB -DQT_WAYLANDCLIENT_LIB -DQT_GUI_LIB > > -DQT_CORE_LIB -I. > > -I../../../../hardwareintegration/client/shm-emulation-server > > -I../../../../../include/QtWaylandClient/5.11.3 > > -I../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtServ > > iceSupport > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtSer > > viceSupport/5.11.3 > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtSer > > viceSupport/5.11.3/QtServiceSupport > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui > > /5.11.3 > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui > > /5.11.3/QtGui -I../../../../../include > > -I../../../../../include/QtWaylandClient > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtGui > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCor > > e/5.11.3 > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCor > > e/5.11.3/QtCore > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/include/QtCor > > e -I.moc > > -I/home/developer/qt_5_11_3/qt-everywhere-src-5.11.3/qtbase/mkspecs/linux > > -g++ -o .obj/shmserverbufferintegration.o > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuff > > erintegration.cpp > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuff > > erintegration.cpp: In function ‘QOpenGLTexture* createTextureFromShm(const > > QString&, int, int, int, int)’: > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuffe > > rintegration.cpp:81:10: error: ‘QOpenGLContext’ has not been declared > > > > if (!QOpenGLContext::currentContext()) > > > >^~ > > > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuffe > > rintegration.cpp:84:59: error: incomplete type ‘QOpenGLTexture’ used in > > nested name specifier > > > > auto *tex = new QOpenGLTexture(image, > > > > QOpenGLTexture::DontGenerateMipMaps); > > > > ^~ > > ~ > > > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuffe > > rintegration.cpp:84:78: error: invalid use of incomplete type ‘class > > QOpenGLTexture’ > > > > auto *tex = new QOpenGLTexture(image, > > > > QOpenGLTexture::DontGenerateMipMaps); > > > > ^ > > > > In file included from > > ../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient/private/qway > > landserverbufferintegration_p.h:1:0,> > > from > > > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuffe > > rintegration.h:45,> > > from > > > > ../../../../hardwareintegration/client/shm-emulation-server/shmserverbuffe > > rintegration.cpp:40: > > ../../../../../include/QtWaylandClient/5.11.3/QtWaylandClient/private/../ > > ../../../../src/client/hardwareintegration/qwaylandserverbufferintegration > > _p.h:62:7: note: forward declaration of ‘class QOpenGLTexture’ > > > > class QOpenGLTexture; > > > > ^~ > > > > Makefile:1269: recipe for target '.obj/shmserverbufferintegration.o' > > failed > > make[6]: *** [.obj/shmserverbufferintegration.o] Error 1 > > make[6]: Leaving directory > >
[Interest] webkit and qt5.12.0 for mingw windows
I'm trying to build the qt webkit community_release (5.9) with qt 5.12.0 precompiled (mingw 64bit). On linux this is straight forward. On windows it appears it doesn't like the 64bit approach. Has anyone had succes with this combination - and is it possible to compile against the prebuild at all? What exact versions of the extra dependencies (ruby, perl, pthyon, etc) are required here? Any help will be very much appreciated:-) Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] webkit and qt5.12.0 for windows
I'm trying to build the qt webkit community_release (5.9) with qt 5.12.0 precompiled (mingw 64bit). On linux this is straight forward. On windows it appears it doesn't like the 64bit approach. Has anyone had succes with this combination - and is it possible to compile against the prebuild at all? What exact versions of the extra dependencies (ruby, perl, pthyon, etc) are required here? Any help will be very much appreciated:-) Best regards Frank ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] need a QT 5.12.0 MinGW 32bit release for windows in all the upcoming QT versions
Indeed - working in medical IT this is the major issue for me. Frank On Tuesday, 18 December 2018 17:28:05 CET Thiago Macieira wrote: > On Tuesday, 18 December 2018 03:56:47 PST Kai Koehne wrote: > > Anyhow, we don't want to maintain two different MinGW builds; there was > > quite some popular demand for 64 bits (see e.g. > > https://bugreports.qt.io/browse/QTBUG-35288), so we switched to 64 bit in > > Qt 5.12. I don't see us switching back until there's clear evidence that > > the majority would prefer 32 bit. > > I think the point is not to switch, but to provide an additional build. I'm > going to guess the requestors' argument is going to be that they still need > to ship 32-bit applications for Windows, since they still have users with > 32-bit Windows, despite running on a 64-bit CPU. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] need a QT 5.12.0 MinGW 32bit release for windows in all the upcoming QT versions
+1 On Monday, 17 December 2018 08:11:34 CET Amr Kamal wrote: > Hello, > > when Downloading the last version of QT 5.12.0 it only provides MinGW 64bit > for windows which makes some problem with previous projects that used > 32bit version especially if there is any kind of third-party library, at > the same time the need of using one updated version from QT, because of > that the only solution now, is to compile it with MinGW 32bit which takes a > very long time, need a lot of dependencies, and most of the users can't do > this, or using old versions of QT. > > so please consider this suggestion in the next version, as it's very needed > one it's great to have a 64bit version but 32 is very good working on all > platforms. > > Thank you very much. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Win10: GUI Program only runs as Admin
Hi Konrad, On Tuesday 01 August 2017 12:48:09 Konrad Rosenbaum wrote: > Hi, > > my program does not need explicit installation: you copy it into its > directory and start it. Usually this works like a charm. > > One of my users has the problem that the program does not run as normal > user under Windows 10, but it does run as Administrator. The error that > pops up for a normal user looks like the one shown if qwindows.dll cannot > be found (it is located in a sub-directory where the program normally > expects it). > > Any ideas how I could go about reproducing and fixing this problem? might be that the user copied it into its location using the Administrator account. So the 'regular' user has no permissions to access all the files in the installation dir. I've seen this happen multiple times when the target dir is somewhere on C: and acls are active. Best regards Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Solved: plugin trouble with webkit using QT_SCALE_FACTOR
On Monday 30 May 2016 16:12:44 Konstantin Tokarev wrote: > 30.05.2016, 15:59, "Frank Hemer" <fr...@hemer.org>: > > On Friday 20 May 2016 13:51:04 Frank Hemer wrote: > >> Hi, > >> > >> I really appreciate the option to globally scale qt applications with > >> QT_SCALE_FACTOR. After some tweaking I have managed to work around most > >> of > >> the bugs that are still there. > >> > >> Now qwebengine currently does not provide pdf support, so this is a > >> major > >> regression in 5.6 due to webkit being deprecated. > >> > >> In the available webkit package (for self-compilation) the (pdf) plugin > >> feature does not honor the QT_SCALE_FACTOR and plugins appear too small > >> (the viewport is too small) and at the wrong position. Does anyone have > >> a solution/patch for this or know how to fix it? > > > > I have patched webkit (windows) successfully - is there a place where I > > could send that patch for integration? > > If anyone is interested - just ping me. > > You need to submit it into Qt Gerrit [1]. There are instructions at [2] > > [1] https://codereview.qt-project.org > [2] https://wiki.qt.io/Qt_Contribution_Guidelines I will not have the time to go through this procedure within the next 3month ... any other option? Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Solved: plugin trouble with webkit using QT_SCALE_FACTOR
On Friday 20 May 2016 13:51:04 Frank Hemer wrote: > Hi, > > I really appreciate the option to globally scale qt applications with > QT_SCALE_FACTOR. After some tweaking I have managed to work around most of > the bugs that are still there. > > Now qwebengine currently does not provide pdf support, so this is a major > regression in 5.6 due to webkit being deprecated. > > In the available webkit package (for self-compilation) the (pdf) plugin > feature does not honor the QT_SCALE_FACTOR and plugins appear too small (the > viewport is too small) and at the wrong position. Does anyone have a > solution/patch for this or know how to fix it? I have patched webkit (windows) successfully - is there a place where I could send that patch for integration? If anyone is interested - just ping me. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] plugin trouble with webkit using QT_SCALE_FACTOR
On Friday 20 May 2016 18:51:37 Allan Sandfeld Jensen wrote: > On Friday 20 May 2016, Frank Hemer wrote: > > Hi, > > > > I really appreciate the option to globally scale qt applications with > > QT_SCALE_FACTOR. After some tweaking I have managed to work around most of > > the bugs that are still there. > > > > Now qwebengine currently does not provide pdf support, so this is a major > > regression in 5.6 due to webkit being deprecated. > > > > In the available webkit package (for self-compilation) the (pdf) plugin > > feature does not honor the QT_SCALE_FACTOR and plugins appear too small > > (the viewport is too small) and at the wrong position. Does anyone have a > > solution/patch for this or know how to fix it? > > > > This is now a showstopper for the cool new scaling feature:-( > > By plugins you mean NPAPI plugins such as Flash and PDF? Yes, exactly Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] plugin trouble with webkit using QT_SCALE_FACTOR
Hi, I really appreciate the option to globally scale qt applications with QT_SCALE_FACTOR. After some tweaking I have managed to work around most of the bugs that are still there. Now qwebengine currently does not provide pdf support, so this is a major regression in 5.6 due to webkit being deprecated. In the available webkit package (for self-compilation) the (pdf) plugin feature does not honor the QT_SCALE_FACTOR and plugins appear too small (the viewport is too small) and at the wrong position. Does anyone have a solution/patch for this or know how to fix it? This is now a showstopper for the cool new scaling feature:-( Thx Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] subclassed QTimer
Hi René,
On Tuesday 03 November 2015 14:13:46 René J.V. Bertin wrote:
> Hi,
>
> I wanted to add a quick timer to an editor class to check the state of the
> various items that editor can handle. It'd be cumbersome to subclass the
> edit items to add a timeout slot to them, or to extend the editor class so
> a timeout slot would get called with the appropriate item. The easiest way
> seemed to be to subclass QTimer:
>
> class QItemTimer : public QTimer {
> public:
> QItemTimer(QObject *parent, Item *item)
>
> : QTimer(parent)
>
> {
> _item = item;
> }
> public slots:
> void fired();
> protected:
> Item *_item;
> };
>
> and then do
>
> QItemTimer *t = new QItemTimer(0, _item);
> connect(t, SIGNAL(timeout()), t, SLOT(fired()));
> t->start(1000);
> timerList.append(t);
>
> but as far as I can tell my fired slot isn't being called.
>
> I'm probably overlooking something obvious?
I'm missing the Q_OBJECT macro
Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtWebkit replacement status...
On Friday 20 March 2015 21:59:10 Scott Aron Bloom wrote: What is the status of Qt WebEngine? Meaning, is it stable enough, to replace qtwebkit on production quality applications yet? Lots of talk about it's the future.. but I cant find on google, has it been fully replaced and fully working. The webpages I render in my app, are pretty simple, no media to worry about. currently no support for nsapi plugins (adobe ...). Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtWebkit replacement status...
Hi Scott, On Monday 23 March 2015 15:00:16 Scott Aron Bloom wrote: Which version of Qt should I use? 5.4? well, I currently use Qt5.4.0 with webkit since there recently have some annoying bugs with the nsapi plugin been fixed. The browser pdf plugins are a must for me (no alternative for using a pdf reader on end user systems), so I must wait for webengine to provide a replacement for these ... on devdays there has been mentioned that nsapi support is not planned to be implemented so that makes me worry a bit ... Currently webkit works fine for me and due to the latest talk on the list I expect it to keep working during the qt5 lifetime. Even compiling webengine took me very loong - just finding out about its dependencies was a hell! For me it does definitely not feel like being ready for production use. Frank -Original Message- From: interest-bounces+scott.bloom=onshorecs@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of Frank Hemer Sent: Monday, March 23, 2015 5:00 AM To: interest@qt-project.org Subject: Re: [Interest] QtWebkit replacement status... On Friday 20 March 2015 21:59:10 Scott Aron Bloom wrote: What is the status of Qt WebEngine? Meaning, is it stable enough, to replace qtwebkit on production quality applications yet? Lots of talk about it's the future.. but I cant find on google, has it been fully replaced and fully working. The webpages I render in my app, are pretty simple, no media to worry about. currently no support for nsapi plugins (adobe ...). Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtWebkit replacement status...
On Monday 23 March 2015 15:28:46 Scott Aron Bloom wrote: My biggest problem with webkit, is the TONS of dependencies it requires.. My app is not a web app, we use it for embedded help.. In Qt4, it added 1 or 2 dlls, in Qt5, we wind up having to include a large portion of Qt that my app really doesn't care about, except for webkit. Im hoping the replacement web engine has fewer dependencies. Nope - its worse! The chrome has more dependencies after all. Frank -Original Message- From: interest-bounces+scott.bloom=onshorecs@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of Frank Hemer Sent: Monday, March 23, 2015 8:14 AM To: interest@qt-project.org Subject: Re: [Interest] QtWebkit replacement status... Hi Scott, On Monday 23 March 2015 15:00:16 Scott Aron Bloom wrote: Which version of Qt should I use? 5.4? well, I currently use Qt5.4.0 with webkit since there recently have some annoying bugs with the nsapi plugin been fixed. The browser pdf plugins are a must for me (no alternative for using a pdf reader on end user systems), so I must wait for webengine to provide a replacement for these ... on devdays there has been mentioned that nsapi support is not planned to be implemented so that makes me worry a bit ... Currently webkit works fine for me and due to the latest talk on the list I expect it to keep working during the qt5 lifetime. Even compiling webengine took me very loong - just finding out about its dependencies was a hell! For me it does definitely not feel like being ready for production use. Frank -Original Message- From: interest-bounces+scott.bloom=onshorecs@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of Frank Hemer Sent: Monday, March 23, 2015 5:00 AM To: interest@qt-project.org Subject: Re: [Interest] QtWebkit replacement status... On Friday 20 March 2015 21:59:10 Scott Aron Bloom wrote: What is the status of Qt WebEngine? Meaning, is it stable enough, to replace qtwebkit on production quality applications yet? Lots of talk about it's the future.. but I cant find on google, has it been fully replaced and fully working. The webpages I render in my app, are pretty simple, no media to worry about. currently no support for nsapi plugins (adobe ...). Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Kicking out QtScript completely
Hi, So am I the only one who cares about QtScript? Am I the only one who still doesn't use (and even want) QML? I also support an application that I will have to maintain for years (health care - 15 years min.) - and yes - it depends on QtScript and I don't see the new QJSEngine API support all my needs. Since I have to keep old code (script code) running I as well feel this decision is the worst regarding qt ever! so: +1 from me! Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Kicking out QtScript completely
On Tuesday 17 March 2015 16:59:24 Christian Dähn wrote: Am 17.03.2015 um 16:17 schrieb Koehne Kai: Have you already filed the features you miss (either to Qt Support, or to the bugtracker)? Regards Kai Honestly? All commercial and private customers should analyze the code by creating diffs and scan that for missing methods, logic and data types??? Are you serious? Thats exactly the problem ... after some years of using QtScript, I know there's a lot of stuff deep within my app and I expect only the analysis what might be missing to take several days if not weeks. I've been reading the docs of QJSEngine and already know some things that are missing but an indepth analysis would be an expensive ride for me (btw. also a paying customer;-) Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Kicking out QtScript completely
On Tuesday 17 March 2015 15:17:31 Koehne Kai wrote: -Original Message- From: interest-bounces+kai.koehne=theqtcompany@qt-project.org Subject: Re: [Interest] Kicking out QtScript completely Hi, So am I the only one who cares about QtScript? Am I the only one who still doesn't use (and even want) QML? I also support an application that I will have to maintain for years (health care - 15 years min.) - and yes - it depends on QtScript and I don't see the new QJSEngine API support all my needs. Have you already filed the features you miss (either to Qt Support, or to the bugtracker)? Last time I seeked the tracker, I didn't find the right place - I've been told on dev days that there is a report being used for this but didn't manage to find it:-( Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QSettings stale lock file
On Thursday 26 February 2015 08:43:11 Koehne Kai wrote: -Original Message- From: interest-bounces+kai.koehne=theqtcompany@qt-project.org [mailto:interest-bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of Frank Hemer Sent: Wednesday, February 25, 2015 5:24 PM To: interest@qt-project.org Subject: Re: [Interest] QSettings stale lock file On Wednesday 25 February 2015 07:25:41 Thiago Macieira wrote: On Wednesday 25 February 2015 11:30:57 Frank Hemer wrote: On a windows7 professional, I'm using QSettings for the local user - the settings data is located on a roaming profile. Now I experience stale lock files xxx.ini.lock (zero bytes) that crash my application. There is no other process running that could access the qsettings! Can anyone shed some light on conditions that could cause this? I think you're confusing cause with consequence. The lock files don't cause the crash; the crash is the cause for the files existing: the process stopped before the lock file could be removed. well - I should have explained in more detail. I was asking for the cause of the lock files to appear ... in many years I have never seen these (well, prob. bec. they are created and removed in some msecs). And looking at the code I expected to find some processID written there, but the size was zero. The reason is that QSettings since Qt 5.4 use QSaveFile to write, which in turn uses QLockFile. See also the 5.4.0 change log: * [QTBUG-21739] The locking mechanism inside QSettings has changed and is no longer compatible with the one of previous versions of Qt. There might be corruption if two applications running different versions of Qt are writing to the same config file at the same time. You must also now have write permissions in the directory containing the settings file in order to write settings. Hmm - yes, that explains the appearance of lock files. But it does not explain the zero size. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QSettings stale lock file
On Wednesday 25 February 2015 07:25:41 Thiago Macieira wrote: On Wednesday 25 February 2015 11:30:57 Frank Hemer wrote: On a windows7 professional, I'm using QSettings for the local user - the settings data is located on a roaming profile. Now I experience stale lock files xxx.ini.lock (zero bytes) that crash my application. There is no other process running that could access the qsettings! Can anyone shed some light on conditions that could cause this? I think you're confusing cause with consequence. The lock files don't cause the crash; the crash is the cause for the files existing: the process stopped before the lock file could be removed. well - I should have explained in more detail. I was asking for the cause of the lock files to appear ... in many years I have never seen these (well, prob. bec. they are created and removed in some msecs). And looking at the code I expected to find some processID written there, but the size was zero. Right now it turned out that some user admin has changed the %appdata% env var for the win roaming profile to point onto a file server. I guess this kind of locking (QLockFile being used by QSettings) doesn't go very well with a samba? share. Btw, the crash actually is a freeze ... the users called it a crash. Best regards Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QSettings stale lock file
On a windows7 professional, I'm using QSettings for the local user - the settings data is located on a roaming profile. Now I experience stale lock files xxx.ini.lock (zero bytes) that crash my application. There is no other process running that could access the qsettings! Can anyone shed some light on conditions that could cause this? Thx Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] qt5.4.0 qscript module not built
Hi, I'm building qt5.4.0 (enterprise) from src package on linux using params 'configure -commercial -qt-xcb -nomake tests -nomake examples -sysconfdir /etc/xdg' - but the qscript module seems not to be built. Has anything been changed? Do I need to build the module separate or apply any params for that? Thx Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] C'tor member initialisation with 'this'
Hi,
when looking at the code of the qt solutions (from git), I realized following
snippet:
class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
{
...
private:
QNetworkAccessManager networkMgr;
...
};
QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
: QObject(parent), networkMgr(this)
{
...
}
Is there any reason why the QNetworkAccessManager needs to be initialized with
the 'this' reference?
Seems like a wrong approach to me - maybe because it used to be a pointer at
some point in time?
I found this when analyzing some weird and not really reproducible stack
traces ...
Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] C'tor member initialisation with 'this'
On Friday 10 January 2014 20:51:35 Constantin Makshin wrote:
Everything is OK unless QNetworkAccessManager's constructor (or anything
further in the call chain) tries to use that pointer for anything beyond
copying it somewhere else. What exactly is looking suspicious to you?
When the transports parent object gets deleted, it will delete the transport.
Thus I wonder whether it could cause a duplicate delete ('this' gets deleted
and will subsequently delete the networkMgr but it is a member var and thus
will be deleted twice?
Frank
On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:
Hi,
when looking at the code of the qt solutions (from git), I realized
following
snippet:
class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
{
...
private:
QNetworkAccessManager networkMgr;
...
};
QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
: QObject(parent), networkMgr(this)
{
...
}
Is there any reason why the QNetworkAccessManager needs to be initialized
with
the 'this' reference?
Seems like a wrong approach to me - maybe because it used to be a pointer
at
some point in time?
I found this when analyzing some weird and not really reproducible stack
traces ...
Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] C'tor member initialisation with 'this'
On Friday 10 January 2014 21:58:13 Constantin Makshin wrote:
No, it won't. 'this' is just a pointer and copying it anywhere (except a
free-memory-in-destructor kind of smartpointer, of course, but using these
to store a pointer to the parent object is a weird idea anyway) doesn't
affect the object's lifetime in any way; neither does the object's
destructor gets called when a pointer to it is destroyed by going out of
scope or any other means.
Well, I was confused by the QObject d'tor doc stating:
Warning: All child objects are deleted. If any of these objects are on the
stack or global, sooner or later your program will crash. We do not recommend
holding pointers to child objects from outside the parent. If you still do,
the destroyed() signal gives you an opportunity to detect when an object is
destroyed.
And the networkMgr is on the stack.
Frank
On Jan 10, 2014 9:42 PM, Frank Hemer fr...@hemer.org wrote:
On Friday 10 January 2014 20:51:35 Constantin Makshin wrote:
Everything is OK unless QNetworkAccessManager's constructor (or anything
further in the call chain) tries to use that pointer for anything beyond
copying it somewhere else. What exactly is looking suspicious to you?
When the transports parent object gets deleted, it will delete the
transport.
Thus I wonder whether it could cause a duplicate delete ('this' gets
deleted
and will subsequently delete the networkMgr but it is a member var and
thus
will be deleted twice?
Frank
On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:
Hi,
when looking at the code of the qt solutions (from git), I realized
following
snippet:
class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
{
...
private:
QNetworkAccessManager networkMgr;
...
};
QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
: QObject(parent), networkMgr(this)
{
...
}
Is there any reason why the QNetworkAccessManager needs to be
initialized
with
the 'this' reference?
Seems like a wrong approach to me - maybe because it used to be a
pointer
at
some point in time?
I found this when analyzing some weird and not really reproducible
stack
traces ...
Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] C'tor member initialisation with 'this'
On Friday 10 January 2014 20:35:56 Jan Kundrát wrote: The C++'s order of destruction is, in this case: 1) ~QtSoapHttpTransport(), which does more or less nothing. By the time it returns, the object is no longer a QSHT (which is the reason why you must not call virtual methods from destructors). 2) Any member variables are destroyed. In this case, one if them is a QNAM which derives from QObject, so at some point the ~QObject() of the QNAM runs, and at that time the QNAM is removed from the list of children of its parent QObject, which is the former QSHT. This is safe, because QSHT::~QObject has not run yet, so the former QSHT is still an QObject. 3) QSHT::~QObject runs, finally. It checks the list of its children, but that list does not include the already destroyed QNAM, so the former QNAM is not deleted twice and everything is OK. Yup, took me some time to understand this as well -- thanks for an excellent question. Thanks for the comprehensive explanation:-) @Thiago: Good hint - never thought of that. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Relashionship between time_t and QDateTime
On Tuesday 27 August 2013 10:19:06 Calogero Mauceri wrote: On 8/26/2013 7:30 PM, Thiago Macieira wrote: On segunda-feira, 26 de agosto de 2013 17:42:58, Calogero Mauceri wrote: QDateTime myDateTime = QDateTime::fromTime_t(f_mtime); The date time printed doing a myDateTime.toString() is Wed Dec 5 12:36:18 2007 Retrieving the last modified information using QFileInfo, the result is different QFileInfo fi(filepath); QDateTime myDateTime = fi.lastModified(); I get this result Wed Dec 5 11:36:18 2007 That is there is one hour difference. I guess the difference is due to the daylight saving management, but I can not understand how that management is performed. Note: if I look at the file properties on Windows dialog, the last modified time is shown as Wed Dec 5 12:36:18 2007 Ah, Windows... The problem might be simply a matter of timezones. The timestamps on files on Windows are not stored with time_t, but with some Windows-specific data. We get a FILETIME back from Win32. Anyway, up until Qt 5.2, you cannot trust the output of a QDateTime with qDebug since it does not include the timezone. You have to ensure that the dates you're comparing by text are in the same timezone: qDebug() dt.toUTC(); Thanks for your reply. Unfortunately the problem is still there even if I force a toUTC() conversion for both QDateTime, either the one initialized from time_t or the one returned by QFileInfo :/. Similarly QDateTime dtFromTime_t = QDateTime::fromTime_t(mtime).toUTC(); QDateTime dtFromFileInfo = fi.lastModified().toUTC(); int sec = ABS(dtFromTime.secsTo(dtFromFileInfo)); // sec returned is 3600 Daylight savings handling in windows is somehow 'weird'. The timestamps of files change when switching the system time from summer time to winter time and vice versa. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Upgrade to Qt 5 -- pros and cons?
On Thursday 21 March 2013 16:41:19 K. Frank wrote: Hello List! What would be the pros and cons of upgrading from Qt 4 to Qt 5? In particular, are there any good reasons not to do so? My particular results of a 'porting test' for a desktopmobil app (~400k lines of code) were quite some code adaptions (not all were documented but could be found somewhere in the doc) and a (currently unfixed) bug in the QSettings. The latter keeps me from further investigating the port but as a result I could run the app (full featured) and found some problems with the style which are caused by the removed styles in qt5. All in all the effort for porting is much much less than I expected (still having the pain of qt3-qt4 ports in mind). I expect it to require less than 2d for the plain porting. Now l'll wait for qt5.1 to give it another shot. Just my 2ct. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] how to block run function of QRunnable class
On Tuesday 19 March 2013 15:11:03 André Somers wrote:
Op 19-3-2013 14:57, K. Frank schreef:
Hello Tony!
I have something of a side question, below.
On Tue, Mar 19, 2013 at 2:09 AM, Tony Rietwyk t...@rightsoft.com.au
wrote:
Hi Ken,
...
// Hack to get around Qt strictness...
class TSleepThread: public QThread
{
public:
static void sleep(unsigned long secs) { QThread::sleep(secs); };
static void msleep(unsigned long msecs) { QThread::msleep(msecs);
};
static void usleep(unsigned long usecs) { QThread::usleep(usecs);
};
};
...
I've done this hack before to unprotect QThread::sleep. But for the
life of me I cannot figure out why QThread:: sleep is protected (or, at
least, why there isn't some other unprotected static sleep somewhere).
A cross-platform sleep (in a cross-platform framework, at that). What's
not to like?
But seriously, does anyone know what the motivation for making sleep
protected might have been?
I'm not sure, probably to discourage its usage. Anyway, in Qt 5, there
now are static public member functions sleep and usleep in QThread.
Sleep being public tends to make users think it could be called from anywhere
(not only from within the thread) which might have sideeffects. Thus,
overwriting QThread implies you're doing sth. non standard and you know what
you are doing.
Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to get/manipulate the scrollbars of QWebView
On Friday 25 January 2013 13:47:45 Wilhelm wrote: Hi all, this may be a very dumb question: how get access to the scrollbars of a QWebView? I want to connect to the sliderMoved() signal to store the actual position for later use. You can use javascript to achieve this:-) Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to get/manipulate the scrollbars of QWebView
On Friday 25 January 2013 15:05:38 Wilhelm wrote: Am 25.01.2013 14:04, schrieb Frank Hemer: On Friday 25 January 2013 13:47:45 Wilhelm wrote: Hi all, this may be a very dumb question: how get access to the scrollbars of a QWebView? I want to connect to the sliderMoved() signal to store the actual position for later use. You can use javascript to achieve this:-) Well, that's weird! No chance from C++ to do this? Then I guess you're looking for this: QWebFrame * frame = webView-page ()-mainFrame (); and use frame's methods: scrollPosition/scrollBarValue and setScroppPosition/setScrollBarValue Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to get/manipulate the scrollbars of QWebView
On Friday 25 January 2013 16:11:20 Wilhelm wrote: Am 25.01.2013 15:36, schrieb Frank Hemer: On Friday 25 January 2013 15:05:38 Wilhelm wrote: Am 25.01.2013 14:04, schrieb Frank Hemer: On Friday 25 January 2013 13:47:45 Wilhelm wrote: Hi all, this may be a very dumb question: how get access to the scrollbars of a QWebView? I want to connect to the sliderMoved() signal to store the actual position for later use. You can use javascript to achieve this:-) Well, that's weird! No chance from C++ to do this? Then I guess you're looking for this: QWebFrame * frame = webView-page ()-mainFrame (); and use frame's methods: scrollPosition/scrollBarValue and setScroppPosition/setScrollBarValue no, the code needs a notifier (aka signal) if the slider position changes! QScrollBar has this signal, but I can't figure out how to get QScrollBar objects. You can't. The sliders you are talking about are created by webkit (from the page source aka html) and are not QAbstractSlider instances. Thus you cannot access their signals. However it should be possible to achieve this via javascript - by registering an eventListener for the scrollbar that in turn calls some c++ method. But sorry - no codesnippet available:-( A hint can be found here: http://stackoverflow.com/questions/9615194/is-it-possible-to-call-a-c- function-from-javascript-in-a-qwebview Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Widget cross-platform (minimum) size constraint problem.
On Wednesday 02 January 2013 10:46:24 Goblin Coding wrote: Hi Tony, You make a valid point. Originally the idea was to allow for scrollbars, but since that comes with an entirely different set of issues (as soon as the scrollbar appears, it cramps the style of the remaining widgets...i.e. when the horizontal scrollbar is created, it actually uses some of the available vertical space and overlaps some of the widgets in the scroll area...I hope that makes sense). I'll try using a standard QWidget as parent (as opposed to the QScrollArea) and see how that pans out. I also realise that there are no guarantees regarding the look of the Qt widgets on different platforms. What I actually wanted to find out is if there was a way to design a widget in Qt Designer so that the way it looks in Designer will be the way it is created at run-time? (i.e. if I tweak it on Windows and run it on Windows, it should look fine on Windows...if I subsequently go tweak it on Linux and run it on Linux, it should look fine on Linux). My problem is that, so far, it seems setting min values is a hit and miss operation - tweak value, compile, run, see what it looks like, realise it's too big/small, tweak value, compile, etc etc. What you would need is a 'getMinRequiredSize' method ... I whish this would exist - as it would allow for choosing different layouts according to the available space, i.e. to create specialized layout managers. Currently calculating the expected size _BEFORE_ showing a widget is really expensive ... Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qt5 settings ini format regression
On Sunday 30 December 2012 16:50:50 Thiago Macieira wrote: On domingo, 30 de dezembro de 2012 18.35.20, Frank Hemer wrote: In QT5, QSettings with IniFormat being used with keys like 'general/entry1' do write all items into a '%General' section. This is what the doc explains as a way to ensure no keys without a group may get overwritten. Unfortunately it seems that with qt5 there appear multiple '%General' sections when accessed as described above. This is a regression to the 4.x. Can anybody confirm this behavior, maybe with other os (I tried linux) - I'll file a bugreport then. Please do, because there are no changes that could account for that. I've attached the full diff on all QSettings from 4.8.4 to 5.0.0. The changes can Done, @see here: https://bugreports.qt-project.org/browse/QTBUG-28893 Thanks Thiago for the detailed diff - looking over the code I suspect the splitting into several sections being an old issue that was possibly never recognized but didn't do any harm as the map reading the values put all things together. Anyway since 5.0 this fails ... maybe a change in the map being used? (I love these sideeffects *ironie*) Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] qt5 settings ini format regression
In QT5, QSettings with IniFormat being used with keys like 'general/entry1' do write all items into a '%General' section. This is what the doc explains as a way to ensure no keys without a group may get overwritten. Unfortunately it seems that with qt5 there appear multiple '%General' sections when accessed as described above. This is a regression to the 4.x. Can anybody confirm this behavior, maybe with other os (I tried linux) - I'll file a bugreport then. Thx Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
