On 9/24/2015 5:49 PM, Alan Alpert wrote:
> The point of versioning isn't to prevent different runtime outcomes,
> that's not possible as you have showed. But there's an implicit
> compile step when you run a QML file at program startup, and the
> versioning system prevents that from failing. Get
On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa wrote:
> On 9/21/2015 10:51 PM, Alan Alpert wrote:
>>
>> I found part of the previous discussion, see my essay from 2012 which
>> explains the versioning system:http://alan.imagin-itis.net/?p=322
>
>
> Not a new discussion, indeed :)
>>
>> Now in the n
On 9/21/2015 10:51 PM, Alan Alpert wrote:
> I found part of the previous discussion, see my essay from 2012 which
> explains the versioning system:http://alan.imagin-itis.net/?p=322
Not a new discussion, indeed :)
> Now in the next minor version of Qt, say we add a QQmlFlange class to
> QtQml. A a
>Your "solution" to have all the minor version number of all modules the same
>as Qt would not work with third party libraries that have different releasing
>cycle.
In this thread we have almost exclusively talked about QML API's which are not
released at a different time. Let's not talk about t
On Monday 21. September 2015 08:07:24 Nurmi J-P wrote:
> 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
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 2
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 c
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 2
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 the users want to be able to _pin_
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 "import QtQuick" - without any versi
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 dev
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
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 entire
y of the
> application source code, try the app and see if there are any property
>
> conflicts that needs resolving. Then he can commit that version bump,
> possibly together with files to .qml files that resolve conflicts.
>
>
>
>
> Simon
>
>
>
mon
From: development-bounces+simon.hausmann=theqtcompany@qt-project.org
on behalf
of Filippo Cucchetto
Sent: Sunday, September 20, 2015 13:55
To: Nurmi J-P
Cc: development@qt-project.org
Subject: Re: [Development] QML import versions
I'm no troll, but i do
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
> QtQuick.
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 2.0
>>> - QtQuick.Controls 1.5 (++)
>>> - QtQuick.L
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
> likelyhood of a name
On Friday 18. September 2015 15:12:22 Nurmi J-P wrote:
[...]
> What makes the situation even more cumbersome, to ourselves who develop
> these modules, is that there's no convention on how new properties are
> revisioned. Some classes are using a running revision number that gets
> incremented when
On Sun, Sep 20, 2015 at 4:55 AM, Filippo Cucchetto
wrote:
> I'm no troll, but i don't see any way to solve this without putting
> something new to the table
>
> 1) What about extending the a little bit the QML language itself.
> Something like
> import QtQuick as in 5.5
> import QtQuick.Controls a
On Sun, Sep 20, 2015 at 11:56 AM, Robin Burchell wrote:
> On Fri, Sep 18, 2015, at 08:15 PM, Nurmi J-P wrote:
>> > I have some opposition to the idea because it entirely prevents us from
>> > making changes if they are needed. An example of this came up just the
>> > other day on IRC: Window{} has
On Fri, Sep 18, 2015, at 08:15 PM, Nurmi J-P wrote:
> > I have some opposition to the idea because it entirely prevents us from
> > making changes if they are needed. An example of this came up just the
> > other day on IRC: Window{} has a number of major (or at least quite
> > irritating) flaws. A
> On 20 Sep 2015, at 19:34, Nurmi J-P wrote:
>
> Hi,
>
>> On 20 Sep 2015, at 15:35, Jocelyn Turcotte wrote:
>>
>> - It would be nice to be able to increase a module’s major version without
>> waiting for Qt6
>
> I can see the desire to implement and release new major versions - we
> develo
Hi,
> On 20 Sep 2015, at 15:35, Jocelyn Turcotte wrote:
>
> - It would be nice to be able to increase a module’s major version without
> waiting for Qt6
I can see the desire to implement and release new major versions - we
developers love rewriting things. :) But in the end it’s the poor Qt Q
> On 20 Sep 2015, at 13:55, Filippo Cucchetto
> wrote:
>
> I'm no troll, but i don't see any way to solve this without putting something
> new to the table
>
> 1) What about extending the a little bit the QML language itself.
> Something like
> import QtQuick as in 5.5
> import QtQuick.Contro
Hi,
I always had that feeling too, that QML import versions are confusing if you
don’t have any IDE to give you direct insight on what is available. If I put my
user hat, I can see three reasons on why I’m usually fiddling with the import
version:
1) Which major version of the plugin do I want
I'm no troll, but i don't see any way to solve this without putting
something new to the table
1) What about extending the a little bit the QML language itself.
Something like
import QtQuick as in 5.5
import QtQuick.Controls as in 5.5
so a way to specify to import a module at version when a speci
Hi Alan,
> On 18 Sep 2015, at 20:13, Alan Alpert <4163654...@gmail.com> wrote:
>
> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P wrote:
>> Hi all,
>>
>> I'd like to propose that all QML imports that are part of the Qt Essentials
>> start following the respective Qt version number.
>>
>> Let's ta
> 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 2.0
>> - QtQuick.Controls 1.5 (++)
>> - QtQuick.Layouts 1.3 (++)
>> - QtQuick.Dialogs 1.2
>
> You misse
On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P wrote:
> Hi all,
>
> I'd like to propose that all QML imports that are part of the Qt Essentials
> start following the respective Qt version number.
>
> Let's take a look at the version history of some of the QtQml and QtQuick
> imports.
You missed a f
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 2.0
> - QtQuick.Controls 1.5 (++)
> - QtQuick.Layouts 1.3 (++)
> - QtQuick.Dialogs 1.2
You missed QtQuick.Window I think :)
... which brings me to this:
> Is thi
Hi all,
I'd like to propose that all QML imports that are part of the Qt Essentials
start following the respective Qt version number.
Let's take a look at the version history of some of the QtQml and QtQuick
imports.
### Qt 5.0
- QtQml 2.0
- QtQuick 2.0
- QtQuick.Particles 2.0
In the beginni
32 matches
Mail list logo
