Re: [Development] 5.3 still open?
On 03/02/15 13:20, Bo Thorsen b...@vikingsoft.eu wrote: Den 03-02-2015 kl. 13:18 skrev Tomasz Olszak: 2015-02-03 10:55 GMT+01:00 Bo Thorsen b...@vikingsoft.eu: Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? Submit it to gerrit. Depending if will you submit patch as a private person or company employee you need to agree to individual or corporate CLA (http://qt-project.org/contributionagreement.html). Next depending on how critical is this bug submit it to 5.4.1 or 5.4 branch (or dev branch). I assume you are fimiliar with gerrit and git if not see (http://qt-project.org/wiki/Gerrit-Introduction and http://qt-project.org/wiki/Setting-up-Gerrit) Also it is worth to see how to submit a patch in http://qt-project.org/wiki/Qt-Contribution-Guidelines Thanks for the description, but the problem was that I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. IIRC, rebasing it onto 5.4 and pushing it again (to the new branch) should work. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
On Tue, Feb 03, 2015 at 03:14:00PM +0100, Bo Thorsen wrote: you can ask me for retargeting changes administratively (just tell the source target branch and change-id). if you're in too much of a hurry for that, you can simply push for the new branch and abandon the first change. Thanks, Oswald. I'll need to update with a test anyway, so I'll just push it to 5.4 as a new change and abandon the old. you still unnecessarily create churn and a discontinuity of the reviews that way, so it's always better to retarget properly if there is enough time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 3 February 2015 at 08:33, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Thanks for the update. Is there a replacement for, say, 90% of Qt Script features, including these where performance counts? I understand that the concern here is that the engine itself isn't and won't be updated. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 03/02/15 09:24, Jaroslaw Staniek stan...@kde.org wrote: On 3 February 2015 at 08:33, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Thanks for the update. Is there a replacement for, say, 90% of Qt Script features, including these where performance counts? QtQml should with 5.5 have most of the required API and the performance should not be a whole lot worse than QtScript (as the JS engine in there is by now ~5 years old). Please let Simon and myself know if you’re missing some functionality or find some larger performance gap. Cheers, Lars I understand that the concern here is that the engine itself isn't and won't be updated. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
2015-02-03 10:33 GMT+03:00 Knoll Lars lars.kn...@theqtcompany.com: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Does this mean that QtWebEngine will be provided for Mingw targets instead Webkit? Now Mingw can't build QWebEngine. Regards, Alexey. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 3 February 2015 at 09:29, Knoll Lars lars.kn...@theqtcompany.com wrote: On 03/02/15 09:24, Jaroslaw Staniek stan...@kde.org wrote: On 3 February 2015 at 08:33, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Thanks for the update. Is there a replacement for, say, 90% of Qt Script features, including these where performance counts? QtQml should with 5.5 have most of the required API and the performance should not be a whole lot worse than QtScript (as the JS engine in there is by now ~5 years old). Please let Simon and myself know if you’re missing some functionality or find some larger performance gap. Thanks for the info. As for performance, I'd mention I am looking for equivalents of QScriptClass which is a handy and light tool. Other than that - QScriptEngineDebugger equivalents? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Hi, Functionality wise, what type of class do you wrap with QScriptClass? Simon Original Message From: Jaroslaw Staniek Sent: Tuesday, February 3, 2015 09:36 To: Knoll Lars Cc: development@qt-project.org Subject: Re: [Development] Deprecating modules with 5.5 On 3 February 2015 at 09:29, Knoll Lars lars.kn...@theqtcompany.com wrote: On 03/02/15 09:24, Jaroslaw Staniek stan...@kde.org wrote: On 3 February 2015 at 08:33, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Thanks for the update. Is there a replacement for, say, 90% of Qt Script features, including these where performance counts? QtQml should with 5.5 have most of the required API and the performance should not be a whole lot worse than QtScript (as the JS engine in there is by now ~5 years old). Please let Simon and myself know if you’re missing some functionality or find some larger performance gap. Thanks for the info. As for performance, I'd mention I am looking for equivalents of QScriptClass which is a handy and light tool. Other than that - QScriptEngineDebugger equivalents? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reimplementation of HTML5 support (QtWebKit)
I had been working on some video support for a while when I realized that javascript events are not being sent properly. Can anyone please gimme a tip, what's the class that takes care of dispatching events for javascript object and where could the problem possibly be? Thanks! On Fri Jan 30 2015 at 9:37:33 PM Ilya Kowalewski illya.kovalevs...@gmail.com wrote: Hey there! My main purpose here is to reimplement some behaviour of QtWebKit on HTML5 Video support. Am I right that there is an abstract layer between actual context rendering / processing and webkit abstraction for HTML5 Video standart? So what's the best place to start with there? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On Tuesday 03 February 2015 20:14:42 Knoll Lars wrote: Yes, making the Qt WebView module work on all desktop platforms could be a possible solution. I think the consensus here is that we need some more work on Qt WebView / webengine before we can drop QtWebKit from the binaries. That said, yes, I agree on deprecating it or, at least, warning people that this is coming. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Requesting reviewers for a QtNetwork feature - Support HTTP redirection
Hi All, Sometime back I implemented a feature in QtNetwork - QNetworkAccessManager: Support HTTP redirection. https://codereview.qt-project.org/#/c/83058/ This review request has been pending in review for quite some time. There was a partial review done, but no one has approved it yet. There was some delay on my part in adding test-cases as I was shifting jobs and country in-between but I've managed to complete the test cases (reviewed and ack'ed by Thiago). It looks like my current set of reviewers are busy with their work, so was wondering if someone else can volunteer to review this implementation. Thanks for your time. Regards, -mandeep ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reproducible Qt ; the purpose of QLibraryInfo::buildDate
On Tuesday 03 February 2015 07:40:12 Sune Vuorela wrote: So, can someone enlighten me on the purpose of this function? This function was added when we opened the repository back for 4.5.1 because we couldn't keep the configure.exe linked against the license key decoder, which contained the expiration dates for evaluation licences. It was used by the nag screen in those builds. That was then. I have no clue now if the function is still used. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 13:18 skrev Tomasz Olszak: 2015-02-03 10:55 GMT+01:00 Bo Thorsen b...@vikingsoft.eu: Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? Submit it to gerrit. Depending if will you submit patch as a private person or company employee you need to agree to individual or corporate CLA (http://qt-project.org/contributionagreement.html). Next depending on how critical is this bug submit it to 5.4.1 or 5.4 branch (or dev branch). I assume you are fimiliar with gerrit and git if not see (http://qt-project.org/wiki/Gerrit-Introduction and http://qt-project.org/wiki/Setting-up-Gerrit) Also it is worth to see how to submit a patch in http://qt-project.org/wiki/Qt-Contribution-Guidelines Thanks for the description, but the problem was that I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI configuration changes
On 02 Feb 2015, at 10:01, Sarajärvi Tony tony.saraja...@theqtcompany.com wrote: Hi Here's a wiki page describing the planned changed along with a bit of version information of the tools: http://qt-project.org/wiki/Qt-5.5.0-tools-and-versions Since OS X 10.7 is no longer CI tested that makes the status of 5.5 on that platform at least “deprecated. I still think that removing support now would be a little bit abrupt. I've collected some of the rationale behind OS X support decisions: https://docs.google.com/document/d/1Iff0SjZyMqXmH5WXi-8bnbwZXx-d8l2FGCa_IDElOpo/edit# Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 13:33 skrev Oswald Buddenhagen: On Tue, Feb 03, 2015 at 07:35:55AM +, Knoll Lars wrote: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. it's been several months since i did the last batch integration, and nobody asked for more since then, so i think we can say it's dead. On Tue, Feb 03, 2015 at 01:20:13PM +0100, Bo Thorsen wrote: I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. gerrit lacks a frontend feature to change the target branch of existing changes. you can ask me for retargeting changes administratively (just tell the source target branch and change-id). if you're in too much of a hurry for that, you can simply push for the new branch and abandon the first change. Thanks, Oswald. I'll need to update with a test anyway, so I'll just push it to 5.4 as a new change and abandon the old. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
On Tue, Feb 03, 2015 at 07:35:55AM +, Knoll Lars wrote: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. it's been several months since i did the last batch integration, and nobody asked for more since then, so i think we can say it's dead. On Tue, Feb 03, 2015 at 01:20:13PM +0100, Bo Thorsen wrote: I already submitted the 5.3 patch to gerrit. I'm not sure how to handle a switch in the branch I'm sending it against. gerrit lacks a frontend feature to change the target branch of existing changes. you can ask me for retargeting changes administratively (just tell the source target branch and change-id). if you're in too much of a hurry for that, you can simply push for the new branch and abandon the first change. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
2015-02-03 10:55 GMT+01:00 Bo Thorsen b...@vikingsoft.eu: Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? Submit it to gerrit. Depending if will you submit patch as a private person or company employee you need to agree to individual or corporate CLA (http://qt-project.org/contributionagreement.html). Next depending on how critical is this bug submit it to 5.4.1 or 5.4 branch (or dev branch). I assume you are fimiliar with gerrit and git if not see (http://qt-project.org/wiki/Gerrit-Introduction and http://qt-project.org/wiki/Setting-up-Gerrit) Also it is worth to see how to submit a patch in http://qt-project.org/wiki/Qt-Contribution-Guidelines BR, Tomasz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QML Item design deliberately hindering C++ interaction?
On Mon, Feb 2, 2015 at 3:43 PM, Alex Montgomery apmontgom...@gmail.com wrote: Is it a design goal of QML/Quick to discourage C++ interaction? I ask because every DevDays talk I attend includes some version of the phrase any reasonably complex QML application will have C++ doing its back-end work, but yet I keep running into QML classes that hide important Qt C++ classes / data in their private implementation. I honestly am just trying to figure out if the philosophy of Qt Quick is to facilitate C++ interaction or discourage it. The strangest example of this push-pull is how Qt Quick handles drag and drop. If you derive from QQuickItem to handle drags, you get the classic Qt C++ API that uses classes like QDragEnterEvent and QDropEvent. Awesome. If you instead want to handle drops in QML, you get the Frankenstein class DragEvent, known in C++ as QQuickDropEvent. This class is a strange mix of C++ only and C++ hostile. If a drop has urls in its mime, you must use the urllist property, which is complete opaque/unusable to QML, so must be handled in C++ (See https://bugreports.qt.io/browse/QTBUG-42277 ). However, if you want to access the mime type directly and read custom mimetypes in C++, you can't, because QQuickDropEvent does not expose (but does keep internally) the actual QDropEvent that it encapsulates. So if you want to make custom mime data with bytearray-style blobs, you have to rely on its invokable function getDataAsString which may or may not mangle your binary data. I honestly can't tell. If I do a toLatin1() on it, will I get back the exact data in the mime type? I'm skeptical at best. TLDR: Are QML classes supposed to rely on C++ interactions or are they supposed to abstract them out of C++'s reach and force programmers to handle events in QML? I really want to know, because the answer right now seems to be both and it makes good architecture nearly impossible. The good architecture, which is conveniently supposed to be enforced by our inflexibility, is for QML to be the front-end/UI layer and C++ to be the back-end/business layer. So abstract data is supposed to be easy to pass between the two, but UI classes (like QDragEnterEvent) are not. The custom Items case goes against this intended split. Custom QQuickItems is not the C++ interaction that we commonly expect in QML applications, and having to create your own custom QML items in C++ should be far, far rarer than creating your own custom QWidgets was. If you are creating custom items you are going to hit some rough spots due to the UI layer trying to stay contained from the C++ back-end. In general we prefer to extend the functionality of the QtQuick elements and the QML language to remove the need for custom QQuickItems. That said, we still want custom items to be possible and not too hard - the need is lessened compared to widgets but certainly not gone. Binary data handling is something that we don't currently support in QML well, and until we do custom QQuickItems seems like a reasonable solution. This specific case is just a defect in our handling of drag and drop (one of the more immature parts of QtQuick, I'll admit). It should certainly be possible in theory to do custom binary mime data from a custom QQuickItem, and it sounds like the current implementation doesn't support that as well as it should. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a break in behavior in QML Text element
On Fri, Jan 30, 2015 at 1:59 AM, Rutledge Shawn shawn.rutle...@theqtcompany.com wrote: On 29 Jan 2015, at 23:46, Olivier Goffart oliv...@woboq.com wrote: On Thursday 29 January 2015 23:24:51 Robin Burchell wrote: tl;dr: I'd like to request a behavior break in QML's Text element. I would like to change the default value of Text::textFormat from Text.AutoText to Text.PlainText. Actually, the default should be Text.StyledText. It contains the core features of RichText without the big performance hit. Personally, that's what I am doing in the QML project I am working on (We had to develop our own set of component (it was started before QtQuick controls), and the text component default to Test.PlainText) Given the security implication, I do believe PlainText should be the default. If you're using user-generated values you should certainly set PlainText (until we have remote references disabled), but it's not the common case for Text. It's the basic element used to put your UI text on the screen anywhere in the app. However, I think it's too much of a breaking change for anyone who has used html tags on purpose and did not explicitly set the format. Is it possible to do the change if we do import QtQuick 2.5 That is, the default of textFormat changes depending on the number in the import statement. +1 to that. If you update your import versions, you can expect some minor changes; and if you are editing the QML anyway, it implies that you are ready to take the time to re-test your application and make small fixes and improvements. I agree in theory. The biggest concern of changing the default value is if the runtime updates underneath your application and breaks it (super bad!), so if we can tie the change to a new import version then we avoid that scenario while helping new applications quicker. It's not without drawbacks, as have been pointed out, but it's manageable. In practice, we don't do this anywhere (default value changes based on import version) and we don't have language support for doing it. By the time we get to instantiating a QQuickText element, we're past the stage with import information. So I would like to resolve it this way, but it's not feasible. And I do not want to risk breaking existing applications. So I recommend this change should wait until QtQuick 3.0. On 29 Jan 2015, at 23:24, Robin Burchell robin...@viroteck.net wrote: Ideally, we could also provide tooling changes to help cover the migration, by warning in QQuickTextItem::setText if HTML was discovered and an explicit format had not been set, or perhaps in other custom tooling aids. This is something that we could add now, if you want to make AutoText warn on use (something like: Text.AutoText determines this is plain text. Please set Text.PlainText as Text.AutoText may be removed in QtQuick 3.0). The details of the message and its performance impact would be up for a separate discussion, but it helps guide users without breaking any existing applications. Seperately, we may want to look at a restriction on the loading of remote resources in Text. I can understand allowing remote URIs in Image, but Text seems like an unexpected behavior to me. If we do that, there needs to be a way to override the restriction, maybe by adding a property to control whether loading of anything outside the QML is allowed. It would IMO be OK to have this property false by default, since the majority of use cases don’t need it. Or we can add the property now, but default it to true (no behavior break). Then we can change the default to false next major version, which I agree seems like a more sensible default. Restricting remote URIs in RichText and StyledText is my biggest concern about malicious user generated content in rich text (it could force a request for an arbitrary external resource). So disabling them and using StyledText would be the best defaults I think. Shame we have to wait. I can imagine that loading remote resources is a useful feature which some apps are relying on. In fact, a single Text element is practically a web browser already, for certain limited purposes. It's kindof cool to forego the need for a real web engine if you need only to display lightweight mid-90’s HTML. Which is really useful while the WebView is in flux or unavailable. Before there was a WebView, we used Text to display HTML all the time. By the time we had a choice we were already used to it. But for tables and certain text/image layouts, HTML is still easier to use than QML (just try inline images, even now). I'm optimistic that by QtQuick 3.0 QML will be preferred for most mid-90's-HTML style content and there will be a mature and efficient WebView available as well, which will decrease use of the rich text features. I also think we should add a source URL property like Image has. It’s unfortunate to need to rely on ugly hacks like this one
[Development] Qt5 compilation on OpenWRT (
Hi. I'm trying to create a Qt5 package for OpenWRT (our solution runs on top of a machine running it). The Makefile was based on this one [1]. I'm attaching the compilation error I'm getting here. The configuration is attached as well, but we know it is not optimal, since we've disabled some options just to get in the compilation step. Also, I've tried to find some reference about the errors on the internet, but no luck with it. Anyone had some similar problem, or can point where I'm failing? Thank you, Rodrigo Oliveira [1] https://github.com/rferrazz/qwebdomo-openwrt/tree/master/qt5 -- Rodrigo Gonçalves de Oliveira Florianópolis, Brazil +55 92 82599445 make[6]: Entering directory `/srv/buildbot/pilsner/build_dir/target-i386_eglibc-2.11/qt-everywhere-opensource-src-5.4.0/qtbase/src/tools/bootstrap' g++ -c -pipe -ffunction-sections -O2 -fPIC -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT -DQT_NO_LIBUDEV -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -DQT_\ NO_DEPRECATED -DQT_NO_TRANSLATION -DQT_QMAKE_LOCATION=\\/srv/buildbot/pilsner/build_dir/target-i386_eglibc-2.11/qt-everywhere-opensource-src-5.4.0/qtbase/bin/qmake\\ -DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTR\ INGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -I../../../mkspecs/linux-g++ -I. -I/srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include -I/srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr\ /include/X11 -I../../../include -I../../../include/QtCore -I../../../include/QtXml -I../../../include/QtCore/5.4.0 -I../../../include/QtCore/5.4.0/QtCore -I../../../include/QtXml/5.4.0 -I../../../include/QtXml/5.4.0/QtXml -I../../3rdparty/zlib -o .obj/qlatincodec.o ../../corelib/codecs/qlatincodec.cpp\ In file included from /srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include/QtCore/qchar.h:45:0,\ from /srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include/QtCore/qstring.h:45,\ from /srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include/QtCore/qtextcodec.h:45,\ from ../../corelib/codecs/qlatincodec_p.h:48,\ from ../../corelib/codecs/qlatincodec.cpp:34:\ /srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include/QtCore/qglobal.h:1503:0: warning: QT_NO_EXCEPTIONS redefined [enabled by default]\ command-line:0:0: note: this is the location of the previous definition\ g++ -c -pipe -ffunction-sections -O2 -fPIC -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT -DQT_NO_LIBUDEV -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -DQT_\ NO_DEPRECATED -DQT_NO_TRANSLATION -DQT_QMAKE_LOCATION=\\/srv/buildbot/pilsner/build_dir/target-i386_eglibc-2.11/qt-everywhere-opensource-src-5.4.0/qtbase/bin/qmake\\ -DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTR\ INGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -I../../../mkspecs/linux-g++ -I. -I/srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include -I/srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr\ /include/X11 -I../../../include -I../../../include/QtCore -I../../../include/QtXml -I../../../include/QtCore/5.4.0 -I../../../include/QtCore/5.4.0/QtCore -I../../../include/QtXml/5.4.0 -I../../../include/QtXml/5.4.0/QtXml -I../../3rdparty/zlib -o .obj/qtextcodec.o ../../corelib/codecs/qtextcodec.cpp\ In file included from ../../../include/QtCore/qprocessordetection.h:1:0,\ from ../../../include/QtCore/../../src/corelib/global/qglobal.h:69,\ from ../../../include/QtCore/qglobal.h:1,\ from ../../../mkspecs/linux-g++/qplatformdefs.h:39,\ from ../../corelib/codecs/qtextcodec.cpp:34:\ ../../../include/QtCore/../../src/corelib/global/qprocessordetection.h:65:0: warning: Q_BIG_ENDIAN redefined [enabled by default]\ In file included from ../../../include/QtCore/../../src/corelib/global/qglobal.h:51:0,\ from ../../../include/QtCore/qglobal.h:1,\ from ../../../mkspecs/linux-g++/qplatformdefs.h:39,\ from ../../corelib/codecs/qtextcodec.cpp:34:\ /srv/buildbot/pilsner/staging_dir/target-i386_eglibc-2.11/usr/include/QtCore/qconfig.h:9:0: note: this is the location of the previous
Re: [Development] Deprecating modules with 5.5
On Tue, Feb 03, 2015 at 07:47:14AM +, Ziller Eike wrote: On Feb 3, 2015, at 8:33 AM, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit As long as WebEngine is not (yet?) a “full replacement of Qt WebKit functionality, most notably https://bugreports.qt.io/browse/QTBUG-44221 we should still include Qt WebKit in our binary packages. Assistant and Qt Creator will otherwise only have a QTextBrowser backend for displaying help, leading to broken looking documentation, since that does not even roughly support the CSS that we use in Qt documentation. I think the main dependency here is that Qt Creator needs to render Qt documentation. What technology this uses is of secondary interest. It just needs to be good enough, and it preferably should not be a lot bigger than actually needed for the task. WebKit was already a bit of a stretch here, I do not really see WebEngine as an improvement in the size and overhead departement. It's a huge club for a task that's just a wee bit beyond the QTextBrowser fallback's capabilities (which was, btw, working reasonably well for a while about two or three years ago, until some change in the doc style sheet made it really ugly again). Creator would benefit most from a *lightweight* HTML renderer, possibly thin wrappers around platforms' native renderers, _or_ a doc style that's usable in QTextBrowser, less so from being used as a pawn in the WebKit vs WebEngine discussion, both of which are not really good fits for the task. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 03/02/15 20:25, André Pönitz apoen...@t-online.de wrote: On Tue, Feb 03, 2015 at 07:47:14AM +, Ziller Eike wrote: On Feb 3, 2015, at 8:33 AM, Knoll Lars lars.kn...@theqtcompany.com wrote: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit As long as WebEngine is not (yet?) a “full replacement of Qt WebKit functionality, most notably https://bugreports.qt.io/browse/QTBUG-44221 we should still include Qt WebKit in our binary packages. Assistant and Qt Creator will otherwise only have a QTextBrowser backend for displaying help, leading to broken looking documentation, since that does not even roughly support the CSS that we use in Qt documentation. I think the main dependency here is that Qt Creator needs to render Qt documentation. What technology this uses is of secondary interest. It just needs to be good enough, and it preferably should not be a lot bigger than actually needed for the task. WebKit was already a bit of a stretch here, I do not really see WebEngine as an improvement in the size and overhead departement. It's a huge club for a task that's just a wee bit beyond the QTextBrowser fallback's capabilities (which was, btw, working reasonably well for a while about two or three years ago, until some change in the doc style sheet made it really ugly again). Creator would benefit most from a *lightweight* HTML renderer, possibly thin wrappers around platforms' native renderers, _or_ a doc style that's usable in QTextBrowser, less so from being used as a pawn in the WebKit vs WebEngine discussion, both of which are not really good fits for the task. Yes, making the Qt WebView module work on all desktop platforms could be a possible solution. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Knoll Lars schreef op 3-2-2015 om 10:51: So Qt 5.6 can drop mingw support? There are currently no plans in dropping mingw. But webengine is currently not supported on that compiler. So I guess that does mean that it will no longer be Tier 1 then. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ministro not able to install qt libs anymore
Hello, I am not able to get ministro to download qt libs anymore. I've been told that this is due to an expired SSL certificate at qt-project.org, and that it may last 1 or 2 days... Consequence no new user can install my application... Any hope this can be resolved sooner? Thanks Philippe Lelong ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ministro not able to install qt libs anymore
Hi, it’s being worked on. I hope that a new certificate is in place within the next few days. Cheers, Lars On 03/02/15 11:24, mai...@virtual-winds.org mai...@virtual-winds.org wrote: Hello, I am not able to get ministro to download qt libs anymore. I've been told that this is due to an expired SSL certificate at qt-project.org, and that it may last 1 or 2 days... Consequence no new user can install my application... Any hope this can be resolved sooner? Thanks Philippe Lelong ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 03/02/15 10:08, Alexey Pavlov alex...@gmail.com wrote: 2015-02-03 11:49 GMT+03:00 Knoll Lars lars.kn...@theqtcompany.com: On 03/02/15 09:35, Alexey Pavlov alex...@gmail.com wrote: 2015-02-03 10:33 GMT+03:00 Knoll Lars lars.kn...@theqtcompany.com: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Does this mean that QtWebEngine will be provided for Mingw targets instead Webkit? Now Mingw can't build QWebEngine. It’ll probably be difficult to build WebEngine against Mingw, but I hope that we can build it with clang on Windows when 5.6 comes. Currently you have to use MSVC if you need WebEngine on Windows. But we don’t really have a choice, as there is no upstream for Qt WebKit anymore. This implies that we’d have to fully develop that fork on our own to support is. That in turn requires a team far larger than what we have. So it’s simply not doable. So Qt 5.6 can drop mingw support? There are currently no plans in dropping mingw. But webengine is currently not supported on that compiler. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
2015-02-03 11:49 GMT+03:00 Knoll Lars lars.kn...@theqtcompany.com: On 03/02/15 09:35, Alexey Pavlov alex...@gmail.com wrote: 2015-02-03 10:33 GMT+03:00 Knoll Lars lars.kn...@theqtcompany.com: Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Does this mean that QtWebEngine will be provided for Mingw targets instead Webkit? Now Mingw can't build QWebEngine. It’ll probably be difficult to build WebEngine against Mingw, but I hope that we can build it with clang on Windows when 5.6 comes. Currently you have to use MSVC if you need WebEngine on Windows. But we don’t really have a choice, as there is no upstream for Qt WebKit anymore. This implies that we’d have to fully develop that fork on our own to support is. That in turn requires a team far larger than what we have. So it’s simply not doable. So Qt 5.6 can drop mingw support? Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.3 still open?
Den 03-02-2015 kl. 08:35 skrev Knoll Lars: It’s not strictly closed, but I don’t think we’ll create a release from 5.3 anymore. Ok, that answers the question I posted, but not the next one. Should I do a new patch against 5.4 instead? If yes, how would I do this in gerrit? On 03/02/15 07:52, Bo Thorsen b...@vikingsoft.eu wrote: Hi guys, I fixed a bug for 5.3, but Marc asked if it was still open. I don't know that it isn't? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
