On 17/02/2012 07:27, ext Thiago Macieira wrote:
> On sexta-feira, 17 de fevereiro de 2012 13.20.09,
> marius.storm-ol...@nokia.com wrote:
>> On 17/02/2012 05:39, ext Thiago Macieira wrote:
>>> On sexta-feira, 17 de fevereiro de 2012 01.47.13,
>>>
>>> andrew.den-ex...@nokia.com wrote:
I'm not s
On sexta-feira, 17 de fevereiro de 2012 13.20.09, marius.storm-ol...@nokia.com
wrote:
> On 17/02/2012 05:39, ext Thiago Macieira wrote:
> > On sexta-feira, 17 de fevereiro de 2012 01.47.13,
> >
> > andrew.den-ex...@nokia.com wrote:
> >> I'm not saying there won't be any maintenance burden, but it's
On 17/02/2012 05:39, ext Thiago Macieira wrote:
> On sexta-feira, 17 de fevereiro de 2012 01.47.13,
> andrew.den-ex...@nokia.com wrote:
>> I'm not saying there won't be any maintenance burden, but it's not
>> massively greater than a lot of other modules either.
>
> I'll take your word for it.
>
>
On sexta-feira, 17 de fevereiro de 2012 01.47.13, andrew.den-ex...@nokia.com
wrote:
> I'm not saying there won't be any maintenance burden, but it's not massively
> greater than a lot of other modules either.
I'll take your word for it.
What I'm still looking for is that someone comes out and say
> On quinta-feira, 16 de fevereiro de 2012 14.56.08, Stephen Kelly wrote:
> > On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:
> > > On Thursday 16 February 2012 13:39:14 lars.kn...@nokia.com wrote:
> > > > Well, it's working for the moment, so the question is where the
> > > > person
On Thu, 16 Feb 2012 22:12:16 ext Olivier Goffart wrote:
> On Thursday 16 February 2012 21:14:07 Alan Alpert wrote:
> > On Thu, 16 Feb 2012 20:47:49 ext Olivier Goffart wrote:
> > > On Thursday 16 February 2012 12:26:50 Alan Alpert wrote:
> > > > The way QML compatibility is supposed to work is diff
I think that maintaining the QtQuick1 in Qt5 will make people
become accommodated with the old technology (those people who have apps
relying on QtQuick1)
instead of adopting QtQuick 2 for their new applications (why spend time
learning the new features of QtQuick2 if 1 is still working on Qt5?), a
On quinta-feira, 16 de fevereiro de 2012 14.56.08, Stephen Kelly wrote:
> On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:
> > On Thursday 16 February 2012 13:39:14 lars.kn...@nokia.com wrote:
> > > Well, it's working for the moment, so the question is where the person
> > > comes fro
On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:
> On Thursday 16 February 2012 13:39:14 lars.kn...@nokia.com wrote:
> > On 2/16/12 2:11 PM, "ext Thiago Macieira"
> >
> > wrote:
> > >On quinta-feira, 16 de fevereiro de 2012 13.51.27, Stephen Kelly wrote:
> > >> > If that guarantee c
On Thursday 16 February 2012 13:39:14 lars.kn...@nokia.com wrote:
> On 2/16/12 2:11 PM, "ext Thiago Macieira"
>
> wrote:
> >On quinta-feira, 16 de fevereiro de 2012 13.51.27, Stephen Kelly wrote:
> >> > If that guarantee cannot be given, I will oppose the inclusion of
> >>
> >>QtQuick1
> >>
> >>
On 2/16/12 2:11 PM, "ext Thiago Macieira"
wrote:
>On quinta-feira, 16 de fevereiro de 2012 13.51.27, Stephen Kelly wrote:
>> > If that guarantee cannot be given, I will oppose the inclusion of
>>QtQuick1
>> > as part of the Qt 5.0 release.
>>
>
>> That said, even if it doesn't get released with
On quinta-feira, 16 de fevereiro de 2012 13.51.27, Stephen Kelly wrote:
> > If that guarantee cannot be given, I will oppose the inclusion of QtQuick1
> > as part of the Qt 5.0 release.
>
> That said, even if it doesn't get released with Qt 5.0, it could be
> released later in the future if those
On Thursday, February 16, 2012 13:27:43 Thiago Macieira wrote:
> On quinta-feira, 16 de fevereiro de 2012 13.01.39, Stephen Kelly wrote:
> > It's quite similar to the current qmetaobject revisions situation where
> > now qtactiveqt is being updated. QtQuick1 would have to be maintained,
> > but pre
On Thursday, February 16, 2012 09:26:57 you wrote:
> Having lot of QObject classes is ok, that would still work.
>
> I was talking about sublclasses of QDeclarativeItem. I looked in
> kde-baseapps kdeedu kdegraphics kdelibs kdepim kdepimlibs
> kdepim-runtime kdeplasma-addons kde-runtime kd
On quinta-feira, 16 de fevereiro de 2012 13.01.39, Stephen Kelly wrote:
> It's quite similar to the current qmetaobject revisions situation where now
> qtactiveqt is being updated. QtQuick1 would have to be maintained, but
> presumably no one is stepping up to do that.
Let's be clear then:
If the
2012/2/16 Stephen Kelly :
> On Thursday, February 16, 2012 08:43:37 Alexis Menard wrote:
>
>> The porting effort from Qt4 to Qt5 is minimal and I believe (based on
>
>> my own experience) that porting from QtQuick1 to QtQuick2 is quite
>
>> easy (expect if you have classes inheriting from QDeclarat
On Thursday 16 February 2012 21:14:07 Alan Alpert wrote:
> On Thu, 16 Feb 2012 20:47:49 ext Olivier Goffart wrote:
> > On Thursday 16 February 2012 12:26:50 Alan Alpert wrote:
> > > The way QML compatibility is supposed to work is different from C++.
> > > Even
> > > for a minor version, you don't
On Thursday, February 16, 2012 08:43:37 Alexis Menard wrote:
> The porting effort from Qt4 to Qt5 is minimal and I believe (based on
> my own experience) that porting from QtQuick1 to QtQuick2 is quite
> easy (expect if you have classes inheriting from QDeclarativeItem).
... in which case the effo
On Thu, Feb 16, 2012 at 8:35 AM, Artur Souza (MoRpHeUz)
wrote:
> On Wed, Feb 15, 2012 at 11:17 PM, Alan Alpert wrote:
>>
>> Now the fact that the C++ APIs are being maintained as well, and in this
>> somewhat drastic manner, for an obsolete major version... it's not the ideal
>> case that QML ver
On Thu, Feb 16, 2012 at 12:14 PM, Alan Alpert wrote:
> It will be interesting to see how this works out in practice - once there are
> distros that ship a different version of Qt. I may have seen qt 4.8 in a
> fedora somewhere, so this issue is just emerging. QML's approach doesn't seem
> as good
On Wed, Feb 15, 2012 at 11:17 PM, Alan Alpert wrote:
>
> Now the fact that the C++ APIs are being maintained as well, and in this
> somewhat drastic manner, for an obsolete major version... it's not the ideal
> case that QML versioning planned for. So we'll see how effective this approach
> is. Bu
On Thu, 16 Feb 2012 20:47:49 ext Olivier Goffart wrote:
> On Thursday 16 February 2012 12:26:50 Alan Alpert wrote:
> > The way QML compatibility is supposed to work is different from C++. Even
> > for a minor version, you don't always just jump to the latest version.
> > Your application continues
On Thursday 16 February 2012 12:26:50 Alan Alpert wrote:
> The way QML compatibility is supposed to work is different from C++. Even
> for a minor version, you don't always just jump to the latest version. Your
> application continues using the version it was developed for until you
> choose to up
On Thu, 16 Feb 2012 12:07:54 ext d3fault wrote:
> I understand that QML/Quick is young, which justifies breaking backwards
> compatibility as it matures... but thinking longer-term, wouldn't it be
> better to call the newest QtQuick (2.0) just QtQuick and the 1.0 version
> Qt4Quick... to retain bac
On Wed, 15 Feb 2012 21:41:06 ext Artur Souza (MoRpHeUz) wrote:
> On Wed, Feb 15, 2012 at 8:31 AM, Olivier Goffart wrote:
> > Anyway, this is a compatibility library. It's sole role is to be there to
> > help transition (just like qt3support was)
>
> I had the impression that most people agreed th
I understand that QML/Quick is young, which justifies breaking backwards
compatibility as it matures... but thinking longer-term, wouldn't it be
better to call the newest QtQuick (2.0) just QtQuick and the 1.0 version
Qt4Quick... to retain backwards compatibility? Does this promise of
backwards com
On Wed, Feb 15, 2012 at 8:31 AM, Olivier Goffart wrote:
>
> Anyway, this is a compatibility library. It's sole role is to be there to help
> transition (just like qt3support was)
I had the impression that most people agreed that qt3support was a
mistake. Are we going to take the same strategy for
On Wednesday 15 February 2012 10:56:54 Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 09.53.29, aaron.kenn...@nokia.com
>
> wrote:
> > Hi,
> >
> > On 15/02/2012, at 9:44 AM, ext Thiago Macieira wrote:
> > > How big are the Qt Quick 1 language support classes? I'm asking so we
>
On quarta-feira, 15 de fevereiro de 2012 11.43.35, Olivier Goffart wrote:
> > To be honest, QMLEngine is better than QmlEngine.
>
> No.
> Qt naming convention says otherwise. (QXmlFoo, QUrl)
> It was changed in Qt4.0: Acronyms are writen CamelCase as every other words.
Indeed, which is why I'm say
Op 2/15/2012 11:21 AM, Mark schreef:
On Wed, Feb 15, 2012 at 11:17 AM, Robin Burchell
mailto:robin%2...@viroteck.net>> wrote:
2012/2/15 Mark mailto:mark...@gmail.com>>:
> Why would you still support QML 1? Qt5 is going to have QML 2
which should
> be superior to QML 1 in about e
On Wednesday 15 February 2012 10:44:46 Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 18.59.45, Alan Alpert wrote:
> > > Q followed by lowercase letters used to be reserved for third-party
> > > implementations. The Q in Qt classes means Qt itself, it's not the first
> > > letter
On Wed, Feb 15, 2012 at 11:17 AM, Robin Burchell wrote:
> 2012/2/15 Mark :
> > Why would you still support QML 1? Qt5 is going to have QML 2 which
> should
> > be superior to QML 1 in about every single way so why not just drop it
> for
> > Qt5?
>
> Because one of the central points of Qt 5 is mai
2012/2/15 Mark :
> Why would you still support QML 1? Qt5 is going to have QML 2 which should
> be superior to QML 1 in about every single way so why not just drop it for
> Qt5?
Because one of the central points of Qt 5 is maintaining compatibility
with Qt 4 as far as is possible. That means not b
2012/2/15 Thiago Macieira
> On quarta-feira, 15 de fevereiro de 2012 09.53.29, aaron.kenn...@nokia.com
> wrote:
> > Hi,
> >
> > On 15/02/2012, at 9:44 AM, ext Thiago Macieira wrote:
> > > How big are the Qt Quick 1 language support classes? I'm asking so we
> can
> > > have an idea of how much ma
On quarta-feira, 15 de fevereiro de 2012 09.53.29, aaron.kenn...@nokia.com
wrote:
> Hi,
>
> On 15/02/2012, at 9:44 AM, ext Thiago Macieira wrote:
> > How big are the Qt Quick 1 language support classes? I'm asking so we can
> > have an idea of how much maintenance effort those classes will be. I
>
Hi,
On 15/02/2012, at 9:44 AM, ext Thiago Macieira wrote:
> How big are the Qt Quick 1 language support classes? I'm asking so we can
> have
> an idea of how much maintenance effort those classes will be. I assume that
> they will continue to use V8, which will be continually updated and modif
On quarta-feira, 15 de fevereiro de 2012 18.59.45, Alan Alpert wrote:
> > Q followed by lowercase letters used to be reserved for third-party
> > implementations. The Q in Qt classes means Qt itself, it's not the first
> > letter in another acronym. So these classes should actually be called
> > "Q
On Wed, 15 Feb 2012 18:46:34 ext Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 08.22.17, martin.jo...@nokia.com
>
> wrote:
> > This is a heads-up regarding the renaming of QML C++ classes. As per
> > https://bugreports.qt-project.org/browse/QTBUG-23737 class names that
> > cur
On quarta-feira, 15 de fevereiro de 2012 08.22.17, martin.jo...@nokia.com
wrote:
> This is a heads-up regarding the renaming of QML C++ classes. As per
> https://bugreports.qt-project.org/browse/QTBUG-23737 class names that
> currently begin with QDeclarative* will be renamed Qml*, for example
> Q
This is a heads-up regarding the renaming of QML C++ classes. As per
https://bugreports.qt-project.org/browse/QTBUG-23737 class names that currently
begin with QDeclarative* will be renamed Qml*, for example QDeclarativeEngine
will become QmlEngine.
This change is needed because QtQuick 1 has
40 matches
Mail list logo
