Re: [Interest] Is 6.x finally there ??
On 2022-10-27 10:09, Volker Hilsheimer via Interest wrote: Yo Roland, On 26 Oct 2022, at 20:52, Roland Hughes via Interest wrote: On 20 Oct 2022, at 22:35, Scott Bloom wrote: I haven?t been following the 6.x progress very much. Only because it was clear 6.0 and 6.1 were not ready to replace all the functionality of 5.x However, with 6.4 it appears that all functionality that is going to be brought forward, has been completed. Is that true? Or is there sill chunks of 5.x missing (that will be brought forward) ? Scott Hello Scott, I feel compelled to point out only developers creating Qt responded with "Good to Go!". In particular the sticky wicket would be this quote "and that we still want to bring back in some form" Qt 6 has become the rental car company definition of "full sized" which now fits in the trunk of what most customers would call "full sized." They mentioned QtLocation and Bill Jones brought up "Another missing module in Qt 6.x that is very important to desktop applications is clipboard support." I don't know how anyone could create a desktop application without any form of clipboard support since users like to select from text file and paste answers into fields, especially if they are scraping answers out of an email or something like that. What makes you think that Qt 6 has no clipboard support? You obviously didn’t bother with opening the referenced JIRA ticket. What Bill pointed out as missing are the platform-specific classes that facilitate the integration of platform specific clipboard formats on Windows and macOS into Qt’s mime-based framework. Qt supports clipboard operations for common mime types just fine. You should probably also check here: https://blog.basyskom.com/2021/porting-a-qt-5-application-to-qt-6/ Note that the basyskom blog is based on Qt 6.0. We are at Qt 6.4 now, and I would anyway almost think that you didn’t read it, given your implication that it must have been somehow difficult to port to this trunk-sized, clipboard-less Qt 6. Not that it matters to you, but not one of my clients is moving to Qt 6. Legacy products will continue to be maintained with Qt 4.8 custom spins as well as Qt 5.x custom spins but no new development will occur using Qt. That has been the feedback from one and all. Indeed, what your clients do or don’t do would be a lot more interesting if we could assume that they get their information from someone who’s at least trying to keep up ;) Hi, I am totally unrelated to the Qt company. I can only speak for myself, but I and colleagues successfully used now Qt 6.x on Linux, Windows and macOS (both x86 and ARM) and at least for us the most glitches we did have with Qt 6 vanished with Qt 6.2 or 6.3. And so far my early tries with Qt 6.x in the KDE project look fine, too. And for the glitches we found, normally the people on the Qt side of the bug tracker were really helpful. I somehow feel sad to always read these mails here that Qt 6 is totally useless, Naturally everybody can have his/her/... own opinion, but it would be nice to not get it repeated here XXX times all over. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] L Word
On 2021-04-29 11:45, Nuno Santos wrote: +1 +1 On 29 Apr 2021, at 10:37, Florian Bruhin wrote: Hey everyone, On Thu, Apr 29, 2021 at 12:13:13PM +0300, coroberti wrote: Dear Guiseppe, You were very helpful for the list members and personally to me. The list will deteriorate without you. Sincerely hope that the moderator will start to function and to do something. Note, that for Roland it's a pure business - spread links and sell books, support, perhaps projects etc. This is what is expected to be stopped by moderation. Hope, you will reconsider dropping the list. Thanks. I've been quiet on this so far, but I can only echo this sentiment. The signal-to-noise ratio on this list is abysmal since Roland showed up with his rants - by not banning him, list admins here allow an otherwise well-working community medium to be destroyed. I'm sure many people who've made significant useful contributions to this mailinglist have already left, and more will follow if nothing gets done about this. If you allow unhealthy community members to continue with their behaviour, over time, the healthy ones will leave. That's not something admins on this list should be okay with. Florian -- m...@the-compiler.org | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ ___ 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 -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
On 2020-06-11 18:06, Frederik Schwarzer wrote: Am 11.06.2020 17:32 schrieb Christoph Cullmann: Hi, I think a lot of developers/companies will have pain because of this, if they have 1) some large customers staying on Windows 7 until really EOL for them Not really an opinion about this but this changelog entry from a release two weeks ago came to mind. "Updated the included Qt library to version 4.8.7." ;) ... And that company has a big market share. In the industry lots of companies lag behind ... a ... bit. But I would suspect those who lag behind with their Windows version to also do not mind lagging behind with their Qt versions. And since Qt 5.15 will be supported for quite some time ... But as I said, I am not in favor of or against one or another. Do you have a customer who actually runs on Windows 7 and is otherwise eager to jump on Qt6 in its early releases? I mean, maintaining old Windows versions will double in price every year now, so there's some pressure at least. I think there is a misunderstanding: The customer will get some software to use, they don't care if it uses internally Qt X.Y or whatever. And yes, even if they have Windows 7, they will want a new version of the software with feature X they paid for ;=) They will not even understand why that should not be possible given they have some Windows 7 support contract with Microsoft and will tell you "but it is not EOL for us". I just wanted to point out that for people building software with Qt, this might mean they will need to maintain two versions of their software to still cater all their Windows customers. Which doubles the pain for them ;=) And yes, one might argue this is a sole issue for the people building such software, but this issue doesn't arise for them if they use an other toolkit that doesn't deprecate Windows 7 now. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
On 2020-06-11 17:23, Philippe wrote: I hardly see many users that need to stick to an old Windows version to be keen, on another hand, to update to the brand new Qt 6. That would be paradoxal, few would do this. And that's not the end of Qt for these Windows 7 users anyway, as they will be able to use Qt 5.15 for a long time. Hi, I think a lot of developers/companies will have pain because of this, if they have 1) some large customers staying on Windows 7 until really EOL for them 2) all other customers having modern Windows 10+ You will want to have the fixes/improvements Qt 6 will get in the next 1-2 years (e.g. better HiDPI support, ...) but you will still need to support the other customers on Windows 7. Staying on Qt 5.15 isn't really an option then and in the worst case you will have to maintain & support 2 builds of your software, which is really not that nice. Thought I can understand that if the Qt Company doesn't have resources to maintain both, not a lot can be done against this decision. Greetings Christoph Philippe On Thu, 11 Jun 2020 14:41:34 +0200 Oliver Wolff wrote: Hi, with Qt 6 approaching it is time to have a look at our set of supported platforms. One candidate for removal of support was Windows 7. Some considerations about dropping this support have been communicated on Qt's development mailing list in March last year [1] and there were some discussions about this topic on the corresponding bug report [2] The operating system was initially launched in 2009 and reached its official end of life in January 2020. That means that Microsoft no longer provides security updates and instances running Windows 7 should be replaced as soon as possible. With this official Microsoft standing in mind our current plan is to remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is planned towards the end of 2020, roughly one year after Windows 7s end of life. Of course, we do not make decisions like this easily or to upset our users but there are clear advantages that speak in favor of dropping support: - We can rely on Windows functions being available instead of trying to dynamically load libraries which might or might not be available. - We can use functionality that only became available in later Windows versions unconditionally. One example of this can be UWP APIs which are Microsoft's "new way of writing APIs". Our new graphics abstraction (RHI) can also rely on newer features being available on Windows - We can focus our Windows resources on bug fixes and new functionality instead of maintaining this "legacy" operating system - CI resources that are used for Windows 7 tests can be used to test other configurations Br, Olli [1] https://lists.qt-project.org/pipermail/development/2019-March/035532.html [2] https://bugreports.qt.io/browse/QTBUG-74687 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Development mailing list developm...@qt-project.org https://lists.qt-project.org/listinfo/development -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Question about correct way to initialize HiDPI support
Hi, after reading https://doc.qt.io/qt-5/highdpi.html it is still a bit unclear to me, what is the correct sequence of attribute setting to have proper HiDPI support on the X11/Windows/macOS platforms (including support for scales like 150%). At the moment, e.g. in Kate, we try (before we init the QApplication): /** * enable high dpi support */ QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); /** * allow fractional scaling */ #if QT_VERSION >= QT_VERSION_CHECK(5, 14, 0) QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough); #endif Is that actually the right way to do it? Does one actually need the Qt::AA_EnableHighDpiScaling call? We got some reports that we behave strangely (weird sizes) since we added Qt::AA_EnableHighDpiScaling. If I miss some example snippet in the documentation, any pointer is welcome ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [#ID:INC-1251018#] Installation issue.
Hi, > On Tuesday, 12 March 2019 02:10:08 PDT Dr.-Ing. Christoph Cullmann wrote: >> > But the point remains: at some point, it becomes difficult to actually >> > build those dependencies because the distribution is old. Also note Qt 6 >> > will not ship bundled libraries. There will be a way to install them from >> > sources, but then we go back to the problem of actually building them. >> >> I think this will be a hard issue for a lot of people that need to support >> industrial customers. > > Understood. We do mean to provide a way to perform an automated build of those > dependencies, both as static and as dynamic libraries, so you should get the > same benefits as current bundling. I was going to write that I didn't expect > it to be well tested on Linux, but then I realised that the binaries from > qt.io are likely to use this technique, so I withdrew my argument before even > sending it. > > Advantage of this method is that we always get the latest, with latest > security fixes. If there are futher fixes that apply to users of Qt, then all > they need to do is rebuild. They will see clearly what those libraries are. > And it simplifies our own maintenance, of course. > > But yes, a disadvantage is now having to deal with the buildsystem for those > libraries. As long as there is at least the idea to have some "helpers" to get external stuff build, that is fine. > >> AbsInt will migrate to Red Hat/CentOS 7 for our builts to circumvent that, >> but I think a lot of other people don't have this possibility. > > RHEL 7 was initially released in 2014. If you can't update to a 6-year-old > series in 2020 when upgrading a major Qt, you could have much bigger problems. > > I'd also advise looking into RHEL 8, which should be released this year, for > further long-term support. This will be no option, some of our larger customers will stay on 7 for the next X years. And yes, staying with some LTS Qt is no real solution, we had already in the past the issues that old Qt releases lacked critical bugfixes (critical for us, not necessarily for all people). > >> For the xkbcommon thing: What me most disturbed is that it was removed >> during a patch release. 5.12 did compile fine on CentOS 6.x, 5.12 did have >> it removed and failed. That was kind of unexpected. > > Yeah, not ideal. But we had to do it because of 5.12's long term nature. It > ought to have been done for .0, but we just couldn't in time. > > Rock, meet hard place. :=) I hope at least I don't need to start as ugly things like https://kate-editor.org/2014/12/22/qt-5-4-on-red-hat-enterprise-5/ again in the near future to have still a current Qt building on some 7.x version. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [#ID:INC-1251018#] Installation issue.
Hi, > On Monday, 11 March 2019 18:23:37 PDT Giuseppe D'Angelo via Interest wrote: >> Il 12/03/19 02:11, Allan Sandfeld Jensen ha scritto: >> >> The problem is not the GCC version. It's the set of libraries provided by >> >> the old distribution. >> > >> > And I guess he could still build his own packages. The libraries would >> > just >> > use bundled qt copies if too old. Only the prebuilt packages have higher >> > requirements, right? >> >> No; e.g. xkbcommon is no longer shipped with Qt and the one in RHEL6.6 >> is too old (the solution is building your own, I guess). > > And as others have found out, that is getting very difficult. The current Git > version of xkbcommon can only be built with Meson and you can't install Meson > on RHEL 6.6 (its Python3 is too old). > > You can build the current xkbcommon release. And past releases that are > greater than the minimum that Qt requires, of course. > > But the point remains: at some point, it becomes difficult to actually build > those dependencies because the distribution is old. Also note Qt 6 will not > ship bundled libraries. There will be a way to install them from sources, but > then we go back to the problem of actually building them. I think this will be a hard issue for a lot of people that need to support industrial customers. AbsInt will migrate to Red Hat/CentOS 7 for our builts to circumvent that, but I think a lot of other people don't have this possibility. For the xkbcommon thing: What me most disturbed is that it was removed during a patch release. 5.12 did compile fine on CentOS 6.x, 5.12 did have it removed and failed. That was kind of unexpected. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On Wed, 18 Mar 2015, Thiago Macieira wrote: I'm not sure I will apply a fix to the main codebase since this is a feature added for kernel 2.6.22, almost 8 years ago. Still very much in use by certain industries who standardized on RH 5 for the time being. 8 years is not much time for the life time of classic Qt user's products. Yep, for us, we need to keep that around as least as long as the official support is there, and sorry, I have neither the time nor the knowledge to find out what is needed to make forkfd working with the old kernel :/ I would try to stick with Qt 5.4 longer, but that is not possible as other major bugs only will get fixed in 5.5. like https://bugreports.qt.io/browse/QTBUG-44511 Now we have either the pain to backport a lot of fixes to 5.4 (without that you crash any Qt app by plugin in a projector) or try to fix that other stuff ;=) Just filled some support issue, lets see. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On 21/03/15 20:19, Thiago Macieira wrote: On Thursday 19 March 2015 14:41:24 Nikos Chantziaras wrote: Qt 5.5 will provide support for Windows 10 (when available) and RedHat Enterprise Linux 6.6. From http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/ RHEL 6.6 comes with glibc 2.12, which isn't affected by these issues. See http://distrowatch.com/table.php?distribution=redhat Again, the problem is RHEL 5, which has glibc 2.5. How is the C++11 situation here though? I assume RHEL 6 support in Qt comes without C++11 due to the ABI incompatibilities between the toolset and vanilla RHEL? If you use a modern devtoolset, like 1.x/2.x, you can have C++11 on both RHEL 5 6 without any problems. The CI wiki states they use gcc 4.9.1 on RHEL 6 (at least from qt 5.5.0 on), guess that means devtoolset = 2.x See https://wiki.qt.io/Qt-5.5.0-tools-and-versions Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On Friday 20 March 2015 23:48:52 Thiago Macieira wrote: On Friday 20 March 2015 08:19:23 Christoph Cullmann wrote: But don't get me wrong: I don't want to try to force somebody to now fix that, I just wanted to state that there ARE users of Qt that use it on such old machines and that they now will have a problem, like me ;=) The fix was easy, but it's going in completely untested. Please compile Qt 5.5 again in one week's time and let me know. Links: https://bugreports.qt.io/browse/QTBUG-45139 https://codereview.qt-project.org/109124 Thanks! Will try to compile it and then run our company integration test suites with the new Qt (if build successfully). Will give feedback in the review/bug tracker. I hope I will get away with Red Hat 5 this year and finally have Red Hat 6 as minimal requirement, but d'oh, large companies are slow ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On Thursday 19 March 2015 06:52:33 Till Oliver Knoll wrote: Am 19.03.2015 um 04:52 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 18 March 2015 16:00:54 Ian Monroe wrote: On Wed, Mar 18, 2015 at 3:02 PM, william.croc...@analog.com If I do ever go for 5 I will probably have to bundle a lot of libraries with my distribution. Are you sure the off-the-shelf binaries don't work on RH6? The qt.io binaries for Qt 5.4 is built on Ubuntu 11.10, which is only about a year newer than RH6. The problem is RHEL5. Yes, but the OP also explicitly mentioned RH 6 (I tried once to get it to build on RH6, but even there I got the impression that I did not have the required versions of the required libraries.). Christoph didn't say anything about RHEL6. The only mention of RHEL comes from the subject, which said (and still says) RHEL5. The person who mentioned RHEL6 was Bill Crocker, who isn't the OP. And he said he has the same problem because he has the same version (RHEL5). As I see it the current issue (using a kernel feature which is not present on an 8 years old RH 5) can be ignored. Qt 5 will never compile for them, as it seems, since even when that feature in question would be removed again, they would get past that point in compilation, but would still hit problems with outdated (system) libraries. So I would rather focus on RH 6 and ignore RH 5. I can only say, Red Hat Enterprise is still in use, a lot, and still supported until 2017 with even longer support extensions possible (I would appreciate if people would upgrade to 6 or 7, but yeah, I can't force them). Given you even get modern toolsets for it, with gcc 4.8.x, it was no real problem to compile most parts of Qt until 5.5, you only need to ship some more up-to-date libraries with your product. That now even QtCore is not compiling is IMHO not that nice. I would stick with Qt 5.4 a year longer, but given it has some interesting issues, that are only fixed in 5.5 for real, that is no real option, too. But don't get me wrong: I don't want to try to force somebody to now fix that, I just wanted to state that there ARE users of Qt that use it on such old machines and that they now will have a problem, like me ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 5.5 and Red Hat 5
Hi, with the current 5.5 branch I get during compile: io/../../3rdparty/forkfd/forkfd.c:58:27: fatal error: sys/eventfd.h: No such file or directory # include sys/eventfd.h ^ I doubt that the kernels for that old Red Hat's support that stuff. Is it possible to compile without that stuff? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Issues building Qt 5.4.0 on CentOS 5.
On Monday 09 February 2015 22:17:26 Thiago Macieira wrote: On Monday 09 February 2015 22:07:19 Simon Matthews wrote: In file included from /usr/include/asm-x86_64/byteorder.h:30:0, from /usr/include/asm/byteorder.h:5, from 3rdparty/linux_perf_event_p.h:19, from qbenchmarkperfevents.cpp:53: /usr/include/linux/byteorder/little_endian.h:43:19: error: ‘__le64’ does This is not a Qt error. Your kernel headers are bad and you should fix them. CentOS 5 has kernel 2.6.18. According to the kernel sources for that tag, __le64 is defined as a typedef in linux/types.h, which is #included by linux_perf_event_p.h. So I don't think this is a kernel issue either. CentOS may have screwed up the kernel headers. Please report to them. Hi, here a quick and dirty way to build it on CentOS 5 ATM: http://kate-editor.org/2014/12/22/qt-5-4-on-red-hat-enterprise-5/ But, yes, reporting it will make sense. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 5.x and Plugin-Build-Key
Hi, for our commercial application, we ship the Qt dynamic libraries in our package, as we can't rely on the system libs to be up-to-date enough. In Qt 4.x, we used the build-key of the plugins to disallow qt plugins of the system to be loaded, should there be some Qt 4.x stuff installed. (http://qt-project.org/doc/qt-4.8/deployment-plugins.html#the-build-key) For Qt 5.x, that feature seems to have gone. If I now install our application on some system having e.g. KF5 installed, it will instantly segfault on launch as it will find the platform integration plugin of KF5 (that is linked against system Qt5 that is not compatible to our build, because of different g++ and Co.) Is there a way to block any loading of plugins not bundled like in Qt 4.x with the build-key? (Without relying on some shell script purging QT_PLUGIN_... env vars?) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Text rendering, QPainter on QWidget vs. QImage on X11
Hi, if I render text using Qt / QPainter to a QWidget directly or first into a QImage (in some background thread) and then paint that image on the widget, I get differences in the rendering result. It seems to only occur if sub-pixel hinting is enabled. Is there a way to enforce the same result for both methods? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Apologies on the bloat thread (a.k.a yes Windows is still important)
Hi, 1) the overwhelming majority of Windows downloads are of the pre-compiled binaries and have been for as long as I can remember, so we will continue to invest time to make that better, easier, more efficient That's why we're now going to ship an MSVC2012 64-bit build, a non-ANGLE build, and we've worked with the MinGW community to come up with a decent distribution of theirs that can produce good-performance code. A small problem with that is: For many applications, people need to stick with MSVC2010 SP1, for both 32 64bit, as only 2010 supports XP without a hassle and 2012 has ugly compiler bugs on IA32 (see the still unresolved issue with libicu + optimizing 32bit builds, even with MSVC2012 update 2). Therefore really a MSVC2010 SP1 32bit/64bit package would be nice to avoid having to toy with two different MSVC's (+ SDKs) to just compile your application on Windows for both variants. (or a MSVC2012 32bit/64bit combo with the XP support enabled, but I guess that is even more work and the compiler bugs might be an issue) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Problem Building QT 5.0 RC1 on Redhat Enterprise
Hi, we need to build Qt5 on still supported RedHat Enterprise Release 4. After building enough other new stuff needed as dependencies on such a machine, we run into this in WebKit2: Platform/unix/SharedMemoryUnix.cpp: In static member function 'static WTF::PassRefPtrWebKit::SharedMemory WebKit::SharedMemory::create(size_t)': Platform/unix/SharedMemoryUnix.cpp:110:66: error: 'O_CLOEXEC' was not declared in this scope Problem is O_CLOEXEC is only around for newer kernel versions than in this distro (and newer shipped headers). Any patch chances? Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Problem Building QT 5.0 RC1 on Redhat Enterprise
07.12.2012, 16:46, Christoph Cullmann cullm...@absint.com: Hi, we need to build Qt5 on still supported RedHat Enterprise Release 4. After building enough other new stuff needed as dependencies on such a machine, we run into this in WebKit2: Platform/unix/SharedMemoryUnix.cpp: In static member function 'static WTF::PassRefPtrWebKit::SharedMemory WebKit::SharedMemory::create(size_t)': Platform/unix/SharedMemoryUnix.cpp:110:66: error: 'O_CLOEXEC' was not declared in this scope Problem is O_CLOEXEC is only around for newer kernel versions than in this distro (and newer shipped headers). Any patch chances? Do you really need WebKit2 on RHEL 4? You can try to build WebKit1-only, or just omit QtWebKit altogether. I mean, I can skip it, but it would be nice to be able to build all qt modules on a LSB 3 distro, or? Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Problem Building QT 5.0 RC1 on Redhat Enterprise
I mean, I can skip it, but it would be nice to be able to build all qt modules on a LSB 3 distro, or? Not really, that's way too old. Do not expect us to provide fixes for LSB 3. There are people interested in keeping LSB 4 working, though. In the specific case of O_CLOEXEC, I'd recommend this simple fix: #ifndef O_CLOEXEC # define O_CLOEXEC 0 #endif The file descriptor will leak to sub-processes, but you deserve that if you're using a kernel that old. Ok, can live with that ;) Still, I think not only we have this LSB 3 problem. There are still a lot companies around using LSB 3 stuff like this RHEL 4 (as long as the support is available from RH). (And I agree that it is a bad idea to do so and we don't do it ourself, still customers demand support for that old stuff.) Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
