On 17-Dec-12 00:20, Alan Alpert wrote:
>> I don't necessarily care how different a shiny new API implementation is and
>> if the fact that my application runs on it is purely coincidental based on
>> how I use those APIs, but not having a way to say "YES, I know you bumped an
>> API version, YES, I
On Sun, Dec 16, 2012 at 4:02 AM, Attila Csipa wrote:
> I don't necessarily care how different a shiny new API implementation is and
> if the fact that my application runs on it is purely coincidental based on
> how I use those APIs, but not having a way to say "YES, I know you bumped an
> API vers
Short summary for the TL;DR crowd:
I don't necessarily care how different a shiny new API implementation is
and if the fact that my application runs on it is purely coincidental
based on how I use those APIs, but not having a way to say "YES, I know
you bumped an API version, YES, I know there
On Wed, Dec 12, 2012 at 3:04 PM, Lincoln Ramsay wrote:
> On 13/12/12 07:12, Alan Alpert wrote:
>>
>> Hmm... so you're suggesting that we tie the imports for a single
>> application into a single file (manageable by the build system)? That
>> might work...
>>
>> So all the application source files
On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa wrote:
> On 12/12/12 23:01, Alan Alpert wrote:
>>
>> Major version means high-level incompatibilty, so if you import QtQml 2.0
>> now don't expect it to just work with QtQml 3.0. Minor version means
>> features, which actually means some low-level inco
On 13/12/12 07:12, Alan Alpert wrote:
> Hmm... so you're suggesting that we tie the imports for a single
> application into a single file (manageable by the build system)? That
> might work...
>
> So all the application source files would look like this:
>
> import QtQml from MyImports
> import QtQ
On 12/12/12 23:01, Alan Alpert wrote:
> Major version means high-level incompatibilty, so if you import QtQml
> 2.0 now don't expect it to just work with QtQml 3.0. Minor version
> means features, which actually means some low-level incompatibilty
> because it's a different language to C++. So Q
On Wed, Dec 12, 2012 at 10:57 AM, André Pönitz
wrote:
> On Wed, Dec 12, 2012 at 10:33:06AM +1000, Lincoln Ramsay wrote:
>> On 12/12/12 07:28, André Pönitz wrote:
>> > What about something like
>> >
>> > import QtQml from Qt 5.0
>> > import QtQuick from Qt 5.0
>>
>> +1
>
> Thanks ;-)
>
>> All t
On Wed, Dec 12, 2012 at 11:18 AM, Giuseppe D'Angelo wrote:
> On 12 December 2012 18:57, André Pönitz
> wrote:
>>
>>
>> I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
>> would need touching all source files. So
>>
>>import QtQml from TheQtIUse
>>import QtQuick from Th
On Wed, Dec 12, 2012 at 7:41 AM, Attila Csipa wrote:
> On 12/12/12 12:22, Sorvig Morten wrote:
>> On Dec 11, 2012, at 4:25 AM, Alan Alpert <4163654...@gmail.com> wrote:
>>> import Qt 5.0
>>>
>>> Which imports all QML modules in the Qt Essentials released with 5.0.0
>
> If the idea is to import the
On 12 December 2012 18:57, André Pönitz
wrote:
>
>
> I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
> would need touching all source files. So
>
>import QtQml from TheQtIUse
>import QtQuick from TheQtIUse
>
> and some one-liner somewhere that relates "TheQtIUse" with
On Wed, Dec 12, 2012 at 10:33:06AM +1000, Lincoln Ramsay wrote:
> On 12/12/12 07:28, André Pönitz wrote:
> > What about something like
> >
> > import QtQml from Qt 5.0
> > import QtQuick from Qt 5.0
>
> +1
Thanks ;-)
> All the benefits of "a group of QML modules attached to a single Qt
> r
On 12/12/12 12:22, Sorvig Morten wrote:
> On Dec 11, 2012, at 4:25 AM, Alan Alpert <4163654...@gmail.com> wrote:
>> import Qt 5.0
>>
>> Which imports all QML modules in the Qt Essentials released with 5.0.0
If the idea is to import the essentials, then call it that: "import
QtEssentials (from Qt)
On Dec 11, 2012, at 4:25 AM, Alan Alpert <4163654...@gmail.com> wrote:
>
> import Qt 5.0
>
> Which imports all QML modules in the Qt Essentials released with 5.0.0
> (except QtQuick 1). It would be the equivalent of
>
> import QtQml 2.0
> import QtQuick 2.0
> import QtQuick.Window 2.0
> import
On 11/12/12 13:25, Alan Alpert wrote:
> I've heard complaints about all the varying version numbers used in
> QML imports. I don't think we can just standardize, for example on
> 5.0, because the whole point of modularization is that modules don't
> have to move in lockstep anymore. But I did hear
On 12/12/12 07:28, André Pönitz wrote:
> What about something like
>
> import QtQml from Qt 5.0
> import QtQuick from Qt 5.0
+1
All the benefits of "a group of QML modules attached to a single Qt
release" without the performance problem of pulling them all in.
Then "Qt 5.0" is just some met
On Mon, Dec 10, 2012 at 07:25:57PM -0800, Alan Alpert wrote:
> I've heard complaints about all the varying version numbers used in
> QML imports. I don't think we can just standardize, for example on
> 5.0, because the whole point of modularization is that modules don't
> have to move in lockstep a
>
> > I understand others' concerns about "load-performance". ,
> The concern about load-performance isn't about "users now have an
> informed choice between faster development speed or faster runtime
> speed". The concern is about people using import Qt 5.0 because it's
> convenient, and then
On Tue, Dec 11, 2012 at 8:44 AM, Charley Bay wrote:
> Alan spaketh:
> I've heard complaints about all the varying version numbers used in
>>
>> QML imports. I don't think we can just standardize, for example on
>> 5.0, because the whole point of modularization is that modules don't
>> have to move
Alan spaketh:
I've heard complaints about all the varying version numbers used in
> QML imports. I don't think we can just standardize, for example on
> 5.0, because the whole point of modularization is that modules don't
> have to move in lockstep anymore. But I did hear an idea at Dev Days
> to
On Tue, Dec 11, 2012 at 6:29 AM, Mohamed Fawzi wrote:
> A way to work around that problem is to have completion on the imports with
> version number.
> This is something I am currently working on in the qmljs editor of QtCreator.
> In the future one could even think about suggesting the import gi
] Convenience Imports in QML
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea
Hi,
On Tue, Dec 11, 2012 at 4:25 AM, Alan Alpert <4163654...@gmail.com> wrote:
> import Qt 5.0
The moment I read this, I immediately had some reservations ...
... because of this:
> What's the performance impact of importing a hundred types you don't
> use? It's known to have a performance co
On segunda-feira, 10 de dezembro de 2012 19.25.57, Alan Alpert wrote:
> Even if this is a good idea, I have no answers for the following questions:
> Where will this be maintained? It practically depends on every Qt module
I think that we could implement this by a special "qmldir" file that simply
On 11/12/2012, at 1:25 PM, Alan Alpert <4163654...@gmail.com> wrote:
> APIs likely to come in later. So if we had an import QtAddons 5.0 it
> could look like this:
>
> import Qt3d 2.0
> import QtSensors 5.0
> import QtMobility.sensors 1.3
FYI QtMobility.sensors has been removed.
Lorn Potter
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (
26 matches
Mail list logo
