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 know
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 Sun, Dec 16, 2012 at 4:02 AM, Attila Csipa q...@csipa.in.rs 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
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 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
release
On 12 December 2012 18:57, André Pönitz
andre.poen...@mathematik.tu-chemnitz.de 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
On Wed, Dec 12, 2012 at 11:18 AM, Giuseppe D'Angelo dange...@gmail.com wrote:
On 12 December 2012 18:57, André Pönitz
andre.poen...@mathematik.tu-chemnitz.de 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
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 ...
snip
... because of this:
What's the performance impact of importing a hundred types you don't
use? It's known to have a performance
] 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 at Dev Days
On Tue, Dec 11, 2012 at 6:29 AM, Mohamed Fawzi fawzi.moha...@digia.com 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
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 8:44 AM, Charley Bay charleyb...@gmail.com 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
I understand others' concerns about load-performance. snip,
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 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
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 meta-thing
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 an
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
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
Senior
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
19 matches
Mail list logo
