Re: [Development] New Wayland Plugin instructions (on the Wayland web site)
2012/1/29 : > Hi, > > the wayland-compositor is nowadays called Weston and lives in the Wayland > Repository. > > If you want to build wayland (which is a requirement to build qtwayland I > think), be sure to fetch the correct SHA1 from the QtWayland Repo as this is > the SHA1 used to verify that it is working correctly. This SHA1 can be found > in a Readme file in the QtWayland Repo. Is it me or other people see upside down windows when running Qt5-based apps on the QML Compositor demo? Also, I would like to know what do you think about window decorations for Wayland and how different window types will be managed (desktop window, panels, menus, etc...). Will decorations be handled by the Wayland platform plugin or by the compositor? -- "Don't let the noise of other's opinions drown out your own inner voice." (Steve Jobs) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Work on qDebug and friends
> From: David Faure > On Friday 03 February 2012 10:51:50 kai.koe...@nokia.com wrote: >> Finally I came around to actually implement something: >> >> http://codereview.qt-project.org/#change,15129 >> >> The idea is that you can customize the output by setting the >> QT_DEBUG_PATTERN environment variable. Setting it e.g. to >> >> "[%type%] %file%:%line% %function% %message%" >> >> Would generate lines like: >> >> [debug] ../helloworld/main.cpp:7 main HELLO WORLD > > Excellent idea!!! > Much better than my 6 env vars in KDE! > > Once this goes in I'll add support for %pid%, %processname% and %timestamp%, > > and we'll be all set :) > >> However, I'm not really sure whether that belongs into Qt Core or not. > > I would definitely like it to go there. > A separate module that apps have to link to and initialize, only helps the > case of "a developer working on his own application". It doesn't > help the more > general case of "an opensource developer/user debugging an existing > application, or a whole set of applications in an existing > framework/desktop". > There's no way to patch all apps just to be able to distinguish their output > > in ~/.xsession-errors. > > I agree with logging to files, sockets, syslog etc. being in a separate addon. > But I would say that making the basic output useful belongs in Qt Core, so > that *all* Qt applications in the world can benefit from it. +1 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets
On 02/03/2012 02:26 PM, gunnar.sle...@nokia.com wrote:
>
> On Feb 3, 2012, at 2:09 PM, ext Anselmo L. S. Melo wrote:
>
>> Hi,
>>
>> On 12/15/2011 07:10 PM, Olivier Goffart wrote:
>>> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
Hi there,
I would like to gather your opinion on whether we should move
QUndoStack and QUndoCommand out of QtWidgets so they could be used
without requiring this module as an extra dependency.
>>
>> +1
>>
>
> Yes I agree. These classes are useful for a significant class of applications
> we will see people writing those types of apps in QML as well as widgets in
> the future, so extracting them from the QtWidgets library might be a good
> idea.
Exactly.
> Where to put them is another question. To me, these classes fall into the
> same category as QIcon, QAction, QFileSystemModel and a probably a few
> others. They are enablers for certain UI's, but are at the same time not
> useful for a different class of apps.
> For instance mobile apps. For this reason, I do not think QtGui is the right
> place for them. As I mentioned in the previous thread on
QFileSystemModel, I think a new module of non-widgetbased desktopui enabling
would be a better location.
Yes, I agree QtGui does not seem to be the best place for such classes.
I've just read the other thread you mentioned, I like this idea of the module
for enablers.
cheers,
Anselmo
>
> cheers,
> Gunnar
>
>
After a brief investigation, I believe this could done by:
1- moving QUndoCommand entirely;
2- moving QUndoStack without moving the APIs that rely on or need
QAction (QAction *createUndoAction() and QAction *createRedoAction());
3- creating a new class (QUndoStackAction ??) inside QtWidgets and
implement the APIs mentioned above there (createUndoAction and
createRedoAction);
4- applying the same logic to QUndoGroup.
QtWebKit, for instance, would benefit from this immediately, as we aim
on removing the QtWidgets dependencies.
Suggestions, comments and any sort of feedback here would be more than
welcome.
>>> I beleive QAction should also be moved back in QtGui
>>
>>
>> I did some experiments about it yesterday, doing a mix of the two
>> suggestions sent to this thread, i.e., moving QUndo{Command,Stack,Group}
>> and QAction out of QtWidgets. QtGui was built successfully, however, before
>> procced to do the adjustments needed in QtWidgets, I considered
>> important to ask for feedback regarding this task.
>>
>> A question related to the feature freeze: Should I create a new task on JIRA
>> for it, or reopen this old one:
>> https://bugreports.qt-project.org/browse/QTBUG-3415 ?
>>
>> Back to the topic: The current status is: QUndo{Command,Stack,Group} and
>> QAction where moved out of QtWidgets and renamed to temporary (and
>> IMHO bad) names like QGuiUndo{Command,Stack,Group} and QGuiActuion, so the
>> QtWidgets subclasses would maintain the original names, to not
>> introduce additional SiC between Qt4/QtGui->Qt5/QtWidgets. Any suggestions
>> regarding names here?
>>
>> Feedback is appreciated.
>>
>>
>> Cheers,
>> Anselmo
>>
>>
>> --
>> Anselmo L. S. Melo
>> openBossa / INdT
>> http://www.indt.org
>> http://www.anselmolsm.org
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
--
Anselmo L. S. Melo
openBossa / INdT
http://www.indt.org
http://www.anselmolsm.org
signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets
On Fri, Feb 3, 2012 at 3:26 PM, wrote: > > >> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote: > >>> Hi there, > >>> > >>> I would like to gather your opinion on whether we should move > >>> QUndoStack and QUndoCommand out of QtWidgets so they could be used > >>> without requiring this module as an extra dependency. > > > Yes I agree. These classes are useful for a significant class of > applications we will see people writing those types of apps in QML as well > as widgets in the future, so extracting them from the QtWidgets library > might be a good idea. > > Where to put them is another question. To me, these classes fall into the > same category as QIcon, QAction, QFileSystemModel and a probably a few > others. They are enablers for certain UI's, but are at the same time not > useful for a different class of apps. For instance mobile apps. For this > reason, I do not think QtGui is the right place for them. As I mentioned in > the previous thread on QFileSystemModel, I think a new module of > non-widgetbased desktopui enabling would be a better location. > It seems to be just a matter of defining a module name for these kind of classes. Maybe "QtUtils" could be used until a better name or module fragmentation is defined. Br, Adriano ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets
On Feb 3, 2012, at 2:09 PM, ext Anselmo L. S. Melo wrote:
> Hi,
>
> On 12/15/2011 07:10 PM, Olivier Goffart wrote:
>> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
>>> Hi there,
>>>
>>> I would like to gather your opinion on whether we should move
>>> QUndoStack and QUndoCommand out of QtWidgets so they could be used
>>> without requiring this module as an extra dependency.
>
> +1
>
Yes I agree. These classes are useful for a significant class of applications
we will see people writing those types of apps in QML as well as widgets in the
future, so extracting them from the QtWidgets library might be a good idea.
Where to put them is another question. To me, these classes fall into the same
category as QIcon, QAction, QFileSystemModel and a probably a few others. They
are enablers for certain UI's, but are at the same time not useful for a
different class of apps. For instance mobile apps. For this reason, I do not
think QtGui is the right place for them. As I mentioned in the previous thread
on QFileSystemModel, I think a new module of non-widgetbased desktopui enabling
would be a better location.
cheers,
Gunnar
>>> After a brief investigation, I believe this could done by:
>>>
>>> 1- moving QUndoCommand entirely;
>>>
>>> 2- moving QUndoStack without moving the APIs that rely on or need
>>> QAction (QAction *createUndoAction() and QAction *createRedoAction());
>>>
>>> 3- creating a new class (QUndoStackAction ??) inside QtWidgets and
>>> implement the APIs mentioned above there (createUndoAction and
>>> createRedoAction);
>>>
>>> 4- applying the same logic to QUndoGroup.
>>>
>>>
>>> QtWebKit, for instance, would benefit from this immediately, as we aim
>>> on removing the QtWidgets dependencies.
>>>
>>> Suggestions, comments and any sort of feedback here would be more than
>>> welcome.
>> I beleive QAction should also be moved back in QtGui
>
>
> I did some experiments about it yesterday, doing a mix of the two suggestions
> sent to this thread, i.e., moving QUndo{Command,Stack,Group}
> and QAction out of QtWidgets. QtGui was built successfully, however, before
> procced to do the adjustments needed in QtWidgets, I considered
> important to ask for feedback regarding this task.
>
> A question related to the feature freeze: Should I create a new task on JIRA
> for it, or reopen this old one:
> https://bugreports.qt-project.org/browse/QTBUG-3415 ?
>
> Back to the topic: The current status is: QUndo{Command,Stack,Group} and
> QAction where moved out of QtWidgets and renamed to temporary (and
> IMHO bad) names like QGuiUndo{Command,Stack,Group} and QGuiActuion, so the
> QtWidgets subclasses would maintain the original names, to not
> introduce additional SiC between Qt4/QtGui->Qt5/QtWidgets. Any suggestions
> regarding names here?
>
> Feedback is appreciated.
>
>
> Cheers,
> Anselmo
>
>
> --
> Anselmo L. S. Melo
> openBossa / INdT
> http://www.indt.org
> http://www.anselmolsm.org
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] qtwebkit-examples-and-demos/examples/browser/cookiejar.cpp is missing "#include "
Hi there. qtwebkit-examples-and-demos/examples/browser/cookiejar.cpp is missing "#include ". Please find the patch attached. Regards, Philip Ashmore diff --git a/examples/browser/cookiejar.cpp b/examples/browser/cookiejar.cpp index d65573d..194f25b 100644 --- a/examples/browser/cookiejar.cpp +++ b/examples/browser/cookiejar.cpp @@ -61,7 +61,7 @@ #include #include - +#include static const unsigned int JAR_VERSION = 23; QT_BEGIN_NAMESPACE ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets
Hi,
On 12/15/2011 07:10 PM, Olivier Goffart wrote:
> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
>> Hi there,
>>
>> I would like to gather your opinion on whether we should move
>> QUndoStack and QUndoCommand out of QtWidgets so they could be used
>> without requiring this module as an extra dependency.
+1
>> After a brief investigation, I believe this could done by:
>>
>> 1- moving QUndoCommand entirely;
>>
>> 2- moving QUndoStack without moving the APIs that rely on or need
>> QAction (QAction *createUndoAction() and QAction *createRedoAction());
>>
>> 3- creating a new class (QUndoStackAction ??) inside QtWidgets and
>> implement the APIs mentioned above there (createUndoAction and
>> createRedoAction);
>>
>> 4- applying the same logic to QUndoGroup.
>>
>>
>> QtWebKit, for instance, would benefit from this immediately, as we aim
>> on removing the QtWidgets dependencies.
>>
>> Suggestions, comments and any sort of feedback here would be more than
>> welcome.
> I beleive QAction should also be moved back in QtGui
I did some experiments about it yesterday, doing a mix of the two suggestions
sent to this thread, i.e., moving QUndo{Command,Stack,Group}
and QAction out of QtWidgets. QtGui was built successfully, however, before
procced to do the adjustments needed in QtWidgets, I considered
important to ask for feedback regarding this task.
A question related to the feature freeze: Should I create a new task on JIRA
for it, or reopen this old one:
https://bugreports.qt-project.org/browse/QTBUG-3415 ?
Back to the topic: The current status is: QUndo{Command,Stack,Group} and
QAction where moved out of QtWidgets and renamed to temporary (and
IMHO bad) names like QGuiUndo{Command,Stack,Group} and QGuiActuion, so the
QtWidgets subclasses would maintain the original names, to not
introduce additional SiC between Qt4/QtGui->Qt5/QtWidgets. Any suggestions
regarding names here?
Feedback is appreciated.
Cheers,
Anselmo
--
Anselmo L. S. Melo
openBossa / INdT
http://www.indt.org
http://www.anselmolsm.org
signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for Qt playground space for JSON client/server
On 2/3/12 1:34 PM, "ext henry.haveri...@nokia.com" wrote: >Hello Andrew, > >Did you get any feedback on your request? I'm just wonder if the >playground process is actually working... http://codereview.qt-project.org/#admin,project,playground/qtjsonstream,inf o Cheers, Lars > >Best regards, >Henry > >On 1/5/12 7:33 PM, "ext andrew.christ...@nokia.com" > wrote: > >>Hi, >> >>I would like to set up a JSON client/server module in Qt Playground . >>The short description: >> >>"JSON objects are often used for communicating between different >>processes. This module >>provides client and server classes for sending and receiving JSON >>messages. >>It supports auto detecting JSON serialization formats (e.g., UTF-8, Qt >>Binary JSON) >>and extensible server-side authentication." >> >>I've done some work to create an initial implementation, but I expect >>that it will improve >>and evolve rapidly over time. >> >>I've been using the name "jsonstream" as a project name, but I'd be happy >>to change that. >> >>Thank you! >> >> - Andrew Christian >> >> >>___ >>Development mailing list >>Development@qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for Qt playground space for JSON client/server
Hello Andrew, Did you get any feedback on your request? I'm just wonder if the playground process is actually working... Best regards, Henry On 1/5/12 7:33 PM, "ext andrew.christ...@nokia.com" wrote: >Hi, > >I would like to set up a JSON client/server module in Qt Playground . >The short description: > >"JSON objects are often used for communicating between different >processes. This module >provides client and server classes for sending and receiving JSON >messages. >It supports auto detecting JSON serialization formats (e.g., UTF-8, Qt >Binary JSON) >and extensible server-side authentication." > >I've done some work to create an initial implementation, but I expect >that it will improve >and evolve rapidly over time. > >I've been using the name "jsonstream" as a project name, but I'd be happy >to change that. > >Thank you! > > - Andrew Christian > > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Separation of QtQuick 1 from QtDeclarative repo
On 2/3/12 12:58 PM, "ext Sergio Ahumada" wrote: >On 02/03/2012 04:32 AM, ext matthew.v...@nokia.com wrote: >> As the first part of the changes described by QTBUG-23737, we have now >>separated version 1 of Qt Quick from the qt5 qtdeclarative module. >> >> The implementation of Qt Quick 1 is now hosted in the 'qtquick1' >>repository ( http://qt.gitorious.org/qt/qtquick1 ). For maximum >>compatibility with the existing version of Qt Quick, this repository was >>created by importing the current implementation of Qt Quick from 4.8, >>using the JavaScriptCore engine, modified to build in the Qt5 >>environment. This repo is not yet integrated into the qt5 meta repo. >> >> The qtquick1 repo produces a single library (QtQuick1) containing both >>the declarative engine and the Qt Quick 1 QML elements. The 'qmlviewer' >>utility is now hosted in the qtquick1 repo, and only loads QML files >>importing version 1 of QtQuick. The 'qmlscene' utility remains in the >>qtdeclarative repo, and only loads QML files importing version 2 of >>QtQuick. >> >> Code linking against the qtquick1 implementation of Qt Quick should >>specify 'QT += quick1'. Code linking against the current version of the >>declarative engine should specify 'QT += declarative', and 'Qt += quick' >>to link against the QtQuick 2 QML elements. >> >> Matt > >Hi, > >It seems like this change broke qt/qttools, can you confirm this please ? I'd assume qttools doesn't include the qtquick1 repo as a dependency. But there's anyway another issue as we currently have duplicated class names between declarative and quick1. Afaik, Matthew is working on fixing this and renaming the QDeclarative* classes for Qt Quick 2 to Qml* Cheers, Lars > >--- >compiling qdeclarativeview_plugin.cpp >qdeclarativeview_plugin.cpp:48:37: fatal error: >QtQuick1/QDeclarativeView: No such file or directory >make[6]: *** [.obj/debug-shared/qdeclarativeview_plugin.o] Error 1 >make[5]: *** [sub-qdeclarativeview-make_default-ordered] Error 2 >make[4]: *** [sub-plugins-make_default-ordered] Error 2 >make[3]: *** [sub-src-make_default] Error 2 >make[2]: *** [sub-designer-make_default-ordered] Error 2 >make[1]: *** [module-qttools-src-make_default] Error 2 >make: *** [module-qttools-make_default] Error 2 >--- > >Cheers, > >-- Sergio Ahumada >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Separation of QtQuick 1 from QtDeclarative repo
On 02/03/2012 04:32 AM, ext matthew.v...@nokia.com wrote: > As the first part of the changes described by QTBUG-23737, we have now > separated version 1 of Qt Quick from the qt5 qtdeclarative module. > > The implementation of Qt Quick 1 is now hosted in the 'qtquick1' repository ( > http://qt.gitorious.org/qt/qtquick1 ). For maximum compatibility with the > existing version of Qt Quick, this repository was created by importing the > current implementation of Qt Quick from 4.8, using the JavaScriptCore engine, > modified to build in the Qt5 environment. This repo is not yet integrated > into the qt5 meta repo. > > The qtquick1 repo produces a single library (QtQuick1) containing both the > declarative engine and the Qt Quick 1 QML elements. The 'qmlviewer' utility > is now hosted in the qtquick1 repo, and only loads QML files importing > version 1 of QtQuick. The 'qmlscene' utility remains in the qtdeclarative > repo, and only loads QML files importing version 2 of QtQuick. > > Code linking against the qtquick1 implementation of Qt Quick should specify > 'QT += quick1'. Code linking against the current version of the declarative > engine should specify 'QT += declarative', and 'Qt += quick' to link against > the QtQuick 2 QML elements. > > Matt Hi, It seems like this change broke qt/qttools, can you confirm this please ? --- compiling qdeclarativeview_plugin.cpp qdeclarativeview_plugin.cpp:48:37: fatal error: QtQuick1/QDeclarativeView: No such file or directory make[6]: *** [.obj/debug-shared/qdeclarativeview_plugin.o] Error 1 make[5]: *** [sub-qdeclarativeview-make_default-ordered] Error 2 make[4]: *** [sub-plugins-make_default-ordered] Error 2 make[3]: *** [sub-src-make_default] Error 2 make[2]: *** [sub-designer-make_default-ordered] Error 2 make[1]: *** [module-qttools-src-make_default] Error 2 make: *** [module-qttools-make_default] Error 2 --- Cheers, -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Work on qDebug and friends
On Friday 03 February 2012 10:51:50 kai.koe...@nokia.com wrote: > Finally I came around to actually implement something: > > http://codereview.qt-project.org/#change,15129 > > The idea is that you can customize the output by setting the > QT_DEBUG_PATTERN environment variable. Setting it e.g. to > > "[%type%] %file%:%line% %function% %message%" > > Would generate lines like: > > [debug] ../helloworld/main.cpp:7 main HELLO WORLD Excellent idea!!! Much better than my 6 env vars in KDE! Once this goes in I'll add support for %pid%, %processname% and %timestamp%, and we'll be all set :) > However, I'm not really sure whether that belongs into Qt Core or not. I would definitely like it to go there. A separate module that apps have to link to and initialize, only helps the case of "a developer working on his own application". It doesn't help the more general case of "an opensource developer/user debugging an existing application, or a whole set of applications in an existing framework/desktop". There's no way to patch all apps just to be able to distinguish their output in ~/.xsession-errors. I agree with logging to files, sockets, syslog etc. being in a separate addon. But I would say that making the basic output useful belongs in Qt Core, so that *all* Qt applications in the world can benefit from it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Work on qDebug and friends
> -Original Message- > From: development-bounces+kai.koehne=nokia@qt-project.org > [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On > Behalf Of Koehne Kai (Nokia-MP/Berlin) > Sent: Tuesday, January 24, 2012 1:39 PM > To: diegoi...@gmail.com > Cc: development@qt-project.org > Subject: Re: [Development] Work on qDebug and friends > > > -Original Message- > > From: ext Diego Iastrubni [mailto:diegoi...@gmail.com] > > Sent: Tuesday, January 24, 2012 1:18 PM > > To: Koehne Kai (Nokia-MP/Berlin) > > Cc: development@qt-project.org > > Subject: Re: [Development] Work on qDebug and friends > > > > So, if I want to have also time/date on my logs, should I install a > > new message handler? > > Well, I plan to work on a simple environment switch which will enable the > default logger to show the file, line, and the log level. My idea is that an > IDE > e.g. Qt Creator sets this environment variable, and voila, you can suddenly > click on your log messages :) Finally I came around to actually implement something: http://codereview.qt-project.org/#change,15129 The idea is that you can customize the output by setting the QT_DEBUG_PATTERN environment variable. Setting it e.g. to "[%type%] %file%:%line% %function% %message%" Would generate lines like: [debug] ../helloworld/main.cpp:7 main HELLO WORLD However, I'm not really sure whether that belongs into Qt Core or not. I'm happy to move the code elsewhere if we're going for a separate plugin/module. That's why it's also not a completely polished patch (documentation is missing + there is an ugly busy wait for concurrent access in qMessageHandlerTokens. Any hints for more elegant solutions are welcome). Regards Kai Koehne PS: The code simplifying Q_FUNC_INFO output (qCleanupFuncinfo) stems from Thiago . The autotest that he also wrote is producing some failures though :( ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Separation of QtQuick 1 from QtDeclarative repo
On 2/3/12 8:54 AM, "ext aaron.kenn...@nokia.com" wrote: >Hi, > >On 03/02/2012, at 7:50 AM, ext Andreas Holzammer wrote: > >> Hi, >> >> Does this mean QtQuick 1 does not depend on V8 anymore? Are there plans >> to remove this from the qt5 qtdeclarative module? > >As Matt described, the QtQuick 1 elements, and JSC based engine they use, >now exist in a separate module. Only Qt Quick 2, and its V8 based >engine, will live in the qtdeclarative module. The reason has been that we've seen that it became increasingly difficult to keep the source compatibility promise for QtQuick 1 while bringing QtQuick 2 to where it needs to be for Qt 5. This now brings a clear separation between the two and will allow Qt Quick2 to do all the changes required for Qt5 without having to worry about breaking corner cases in Qt Quick 1. Cheers, Lars > >Cheers, > >Aaron > >> >> Thank you >> >> Andy >> >> Am 03.02.2012 04:32, schrieb matthew.v...@nokia.com: >>> As the first part of the changes described by QTBUG-23737, we have now >>>separated version 1 of Qt Quick from the qt5 qtdeclarative module. >>> >>> The implementation of Qt Quick 1 is now hosted in the 'qtquick1' >>>repository ( http://qt.gitorious.org/qt/qtquick1 ). For maximum >>>compatibility with the existing version of Qt Quick, this repository >>>was created by importing the current implementation of Qt Quick from >>>4.8, using the JavaScriptCore engine, modified to build in the Qt5 >>>environment. This repo is not yet integrated into the qt5 meta repo. >>> >>> The qtquick1 repo produces a single library (QtQuick1) containing both >>>the declarative engine and the Qt Quick 1 QML elements. The >>>'qmlviewer' utility is now hosted in the qtquick1 repo, and only loads >>>QML files importing version 1 of QtQuick. The 'qmlscene' utility >>>remains in the qtdeclarative repo, and only loads QML files importing >>>version 2 of QtQuick. >>> >>> Code linking against the qtquick1 implementation of Qt Quick should >>>specify 'QT += quick1'. Code linking against the current version of >>>the declarative engine should specify 'QT += declarative', and 'Qt += >>>quick' to link against the QtQuick 2 QML elements. >>> >>> Matt >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> >> -- >> Andreas Holzammer | andreas.holzam...@kdab.com | Software Engineer >> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company >> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 >> KDAB - Qt Experts - Platform-independent software solutions >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
