Re: [Development] QML import versions

On Sep 21, 2015 7:48 AM, Olivier Goffart wrote: > I've always found that tyhe revision system is broken by design. > (Because of the mainingless of the version number, because of the inheriting, > because it's of little use anyway for we always do behaviour changes and the >

Re: [Development] Qt 5.6.0 header diff: QtQml.diff

Only one new method in qqmldebug. Looks good. Lars On 17/09/15 12:57, "Frederik Gladhorn" wrote: > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML import versions

On 18 Sep 2015, at 20:15, Nurmi J-P wrote: >> On 18 Sep 2015, at 17:33, Robin Burchell wrote: >> >> On Fri, Sep 18, 2015, at 05:12 PM, Nurmi J-P wrote: >>> - QtQml 2.2 >>> - QtQml.Models 2.3 (++) >>> - QtQuick 2.6 (++) >>> - QtQuick.Particles

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

Hi Lazlo, On 21/09/15 13:54, "Agocs Laszlo" wrote: >As for the "extra" functions, it was seen a better choice to introduce a >new class since there is a certain difference: the GLES 2.0 calls in >QOpenGLFunctions are guaranteed to be available as long as the system

Re: [Development] Qt 5.6.0 header diff

On Thursday 17 September 2015 12:29:27 Frederik Gladhorn wrote: > I'll send the actual header diffs as attachments in follow-up mails, For next time, I think it would be a good idea to have this diff as a Gerrit change on 5.(x-1) (just the headers), to use the commenting and approval features

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

Hi Lars, As for the "extra" functions, it was seen a better choice to introduce a new class since there is a certain difference: the GLES 2.0 calls in QOpenGLFunctions are guaranteed to be available as long as the system meet's Qt's minimum OpenGL requirements whereas these new ones are not.

Re: [Development] ANGLE upgrade plans for 5.6/5.7

Hi, On 09/21/2015 02:04 PM, Andreas Holzammer wrote: > Hi, > > Am 21.09.2015 um 12:49 schrieb Knoll Lars: > >> I’d only like to get a confirmation from the WEC maintainers, that they >> are ok with this plan as well. > So for WEC angle is not build nor used. As on WEC Direct X would be > build

Re: [Development] Qt 5.6.0 header diff

On 21/09/15 16:10, "Marc Mutz" wrote: >On Thursday 17 September 2015 12:29:27 Frederik Gladhorn wrote: >> I'll send the actual header diffs as attachments in follow-up mails, > >For next time, I think it would be a good idea to have this diff as a >Gerrit >change on 5.(x-1)

Re: [Development] Enhancement to QIODevice?

Thiago, my apologies for replying that late. For some strange reason gmail has decided to mark your reply as spam (even though previous conversation was perfectly OK). Since I see you active in the mailing list I had to dig deeper to find it. On Wed, Sep 16, 2015 at 8:17 PM, Thiago Macieira

Re: [Development] QML import versions

I agree with most of what has been said by everyone here. What i see it's there're two problems: 1) A way to specify a QML module version based on a Qt release 2) A way to decentralize the version used in several .qml files or of an entire project To me we should focus on (1) since (2) could be

Re: [Development] ANGLE upgrade plans for 5.6/5.7

Hi Andrew, This sounds like a solid plan. For 5.6, we probably don’t have any other choice than staying with what we have now. For 5.7, the desktop this sounds ok IMO. I actually don’t think we need to (or should) support VS2012 there at all. I’d only like to get a confirmation from the WEC

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

For OpenGL ES 3.2, those will go into the extras at some point in a future release, yes. And that's pretty much it for now since it is unlikely we get a wide range of new OpenGL versions anytime soon. This does not affect the version & profile based wrappers, for those who are only interested

Re: [Development] Qt 5.6.0 header diff: QtCore.diff

APIs look good, just two doc fixes: https://codereview.qt-project.org/#/c/126153/ https://codereview.qt-project.org/#/c/126154/ Cheers, Lars ___ Development mailing list Development@qt-project.org

Re: [Development] QML import versions

Hi, I agree that something "new" needs to be put on the table in order to solve this. And "this" expands unfortunately to a few issues at the same time. I think that it would be a mistake of "import QtQuick" - without any version tag - would always import the latest available version on

Re: [Development] ANGLE upgrade plans for 5.6/5.7

Hi, Am 21.09.2015 um 12:49 schrieb Knoll Lars: > I’d only like to get a confirmation from the WEC maintainers, that they > are ok with this plan as well. So for WEC angle is not build nor used. As on WEC Direct X would be build with OpenGL ES2 and yeah angle then would do it the other way

Re: [Development] Qt 5.6.0 header diff: QtWidgets.diff

On 21/09/15 11:05, "Knoll Lars" wrote: >Tons of noise with Q_NULLPTR and similar changes... > >New APIs: > >QFileDialog::supportedSchemes property, looks good > >QDesktopWidget::primaryScreenChanged signal >-> IMO this should be added as NOTIFY to the corresponding

Re: [Development] ANGLE upgrade plans for 5.6/5.7

On Monday 21 September 2015 12:50:26 Andrew Knight wrote: > while Qt 5.7 will only support VS2013 and newer (as > well as recent versions of MinGW, but that is tangential to this > discussion). The minimum version of VS for Qt 5.6 is 2012, not 2013, but like Lars said, people using 2012 still

Re: [Development] Enhancement to QIODevice?

On Monday 21 September 2015 12:32:36 Andrzej Ostruszka wrote: > > Well, yeah, it needs to read at least one from the lower device into the > > QIODevice buffer. It will then copy the data again to your buffer. There's > > no way to avoid the double copy, unless device implementation > >

Re: [Development] QML import versions

On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon wrote: > Hi, > > > I agree that something "new" needs to be put on the table in order to solve > this. And "this" expands unfortunately to a few issues at the same time. > > > I think that it would be a mistake of

Re: [Development] ANGLE upgrade plans for 5.6/5.7

On Monday 21 September 2015 08:28:13 Thiago Macieira wrote: > On Monday 21 September 2015 12:50:26 Andrew Knight wrote: > > while Qt 5.7 will only support VS2013 and newer (as > > well as recent versions of MinGW, but that is tangential to this > > discussion). > > The minimum version of VS for

Re: [Development] QML import versions

On 21.09.2015 00:51, Alan Alpert wrote: > By using "import QtQuick 2.4" explicitly, that can't happen. That is > the value offered by minor version numbers. It is the mechanism by > which we achieve "Code written for older versions will Just Work on > newer versions". There is another side of the

Re: [Development] QML import versions

WARNING: Flammable reply ahead. On 9/21/2015 9:07 AM, Nurmi J-P wrote: That would a massive improvement, but it boils down to the same problem. It can only be like that if Qt and QML version numbers match. We cannot sprinkle qtquick versions to the base classes in qtbase. As a third party

Re: [Development] Qt 5.6.0 header diff: QtWidgets.diff

On 21/09/15 13:47, "Knoll Lars" wrote: > > >On 21/09/15 11:05, "Knoll Lars" wrote: > >>Tons of noise with Q_NULLPTR and similar changes... >> >>New APIs: >> >>QFileDialog::supportedSchemes property, looks good >>

Re: [Development] QML import versions

On Sun, Sep 20, 2015 at 02:59:57PM -0700, Alan Alpert wrote: > I think last time this was put forward we considered implementing it > with "metamodules" that are just lists so that we could have a > qml/Qt5/qmldir that looks like > > <...> > QtQuick 2.4 since 5.4 > QtQuick 2.5 since 5.5 >

[Development] ANGLE upgrade plans for 5.6/5.7

Hello, tl;dr: I propose that the copy of ANGLE currently in the 5.6 branch of qtbase be maintained without being upgraded for the next minor release of Qt (5.6). For Qt 5.7 and beyond, we should upgrade ANGLE from upstream while dropping support for VS2010 and VS2012. Around each minor Qt

Re: [Development] QML import versions

On 9/21/2015 8:25 PM, Giuseppe D'Angelo wrote: > I totally agree that one can't just "import the latest" without > breaking code, just please don't use a language mis-feature > (unqualified properties propagating down) to support it :-) My 2 c, We have had Q_OBJECTs which have properties that

Re: [Development] Qt 5.6.0 header diff: QtGui.diff

New QImage::pixelColor and setPixelColor methods, looking good New QImageReader::gamma/setGamme methods, looking good QMouseEvent has a new constructor, looks ok Some new methods in QOpenGLFBO, looking ok to me QColor: rgba64 support, looking ok QPaintDevice::devicePixelRatioF, looks ok Some

Re: [Development] QML import versions

Op 21-9-2015 om 13:08 schreef Filippo Cucchetto: > I agree with most of what has been said by everyone here. > What i see it's there're two problems: > 1) A way to specify a QML module version based on a Qt release > 2) A way to decentralize the version used in several .qml files or of > an

Re: [Development] QML import versions

Just to nitpick, On Sun, Sep 20, 2015 at 11:51 PM, Alan Alpert <4163654...@gmail.com> wrote: > Here is the scenario: > > import QtQuick 2 > > Item { > property bool scrollGestureEnabled: false > MouseArea { > onClicked: console.log(scrollGestureEnabled) > } > } > > In QtQuick

Re: [Development] QML import versions

On 9/21/2015 6:51 PM, Alan Alpert wrote: > On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon > wrote: >> or Go, then we can see that the approach of automatically always importing >> the latest version is known to cause more headaches >> than do good. Very quickly

Re: [Development] QML import versions

I found part of the previous discussion, see my essay from 2012 which explains the versioning system: http://alan.imagin-itis.net/?p=322 It even has an answer for "Why not just use Qt versions?" (but it's a little out-of-date). Additional answers to Attila's questions inline below. On Mon, Sep

Re: [Development] Qt 5.6.0 header diff: QtWidgets.diff

Tons of noise with Q_NULLPTR and similar changes... New APIs: QFileDialog::supportedSchemes property, looks good QDesktopWidget::primaryScreenChanged signal -> IMO this should be added as NOTIFY to the corresponding property. qHash(QSizePolicy, uint), looks good QMainWindow::GroupedDragging

Re: [Development] Qt 5.6.0 header diff: QtNetwork.diff

New APIs: Added support for redirections: QNetworkReply::redirected() signal QNetworkReply::InsecureRedirectError QNetworkRequest::FollowRedirectsAttribute These look good to me. int QNetworkRequest::maximumRedirectsAllowed() const; void QNetworkRequest::setMaximumRedirectsAllowed(int