On Wednesday 18 July 2012 07:26:55 gunnar.sle...@nokia.com wrote:
On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote:
2012/7/17 marius.storm-ol...@nokia.com
(2D accelerators are often bundled with GPUs and perform 2D rendering
ops faster than GPUs, but are unusable with QML
Not inside this tower ;) . But I wasn't talking about comparing to the
proliferation of an unreleased version. All the QtQuick 1 I've seen so far is
on the dead Symbian and Maemo platforms. Even if there were many of those
applications, how many are in continued development for both the old
On Behalf Of ext Donald Carr
Not inside this tower ;) . But I wasn't talking about comparing to the
proliferation of an unreleased version. All the QtQuick 1 I've seen so
far is on the dead Symbian and Maemo platforms. Even if there were
many of those applications, how many are in
On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote:
2012/7/17 marius.storm-ol...@nokia.com
(2D accelerators are often bundled with GPUs and perform 2D rendering
ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see
pvr2d).
2D accelerators bundled with GPUs
On 17.07.2012 07:47, Alan Alpert wrote:
But our Qt4Support library exists and is called QtQuick1. All the old symbols
should be there, if you want to take the easy road to saying done, ported to
Qt 5!.
Well, there is no other choice if you have a platform without hardware
graphics
2012/7/17 Sven Anderson sven.ander...@snom.com
On 17.07.2012 07:47, Alan Alpert wrote:
But our Qt4Support library exists and is called QtQuick1. All the old
symbols
should be there, if you want to take the easy road to saying done,
ported to
Qt 5!.
Well, there is no other choice if you
On terça-feira, 17 de julho de 2012 15.00.04, marius.storm-ol...@nokia.com
wrote:
Btw, does this means you are trying/wanting to run Qt 5 on PowerVR
chipsets from before 2001? All the PVR chips since Feb. 2001 (Series 4
or higher) support some form of OpenGL/GLES and/or DirectX 8.0 or higher
2012/7/17 marius.storm-ol...@nokia.com
(2D accelerators are often bundled with GPUs and perform 2D rendering
ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see
pvr2d).
2D accelerators bundled with GPUs perform 2D rendering ops faster than
GPUs? Uhmm... that sentence is
On 07/18/2012 05:17 AM, ext Andreas Aardal Hanssen wrote:
My point is simply that Qt 5 is best served with a painting backend for
QML 2 that can support non-OpenGL technologies.
I don't want to start a flame war here but I always wondered why
QtQuick 2 had to mean SceneGraph/OpenGL and why the
On Wed, 18 Jul 2012 13:28:02 ext Lincoln Ramsay wrote:
On 07/18/2012 05:17 AM, ext Andreas Aardal Hanssen wrote:
My point is simply that Qt 5 is best served with a painting backend for
QML 2 that can support non-OpenGL technologies.
I don't want to start a flame war here but I always
On Mon, Jul 16, 2012 at 2:02 AM, Alan Alpert alan.alp...@nokia.com wrote:
The theory is that you're not trying to maintain a single codebase for both
QML1 and QML2.
The point has been made before, but I'll repeat it: for libraries and
other pieces of middleware, that isn't really an acceptable
While I continue the discussion to my usual level of verbosity inline, I'm
bringing the important point up top - read it last to understand the thought
process that led me to this:
Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which
provided this overlap? It would have the
2012/7/16 Alan Alpert alan.alp...@nokia.com
Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which
provided this overlap? It would have the old method marked as deprecated
and
the new form syntax available and would provide some form of interim
overlap,
without adding
On Monday 16 July 2012 13:50:42 Alan Alpert wrote:
It's a major version change, what did you expect? It's a pain to maintain
even a QWidget application for a single Qt 4 and Qt 5 code-base, all the
assistance I'm aware of is for porting Qt4 - Qt5 in one go.
No it is not. Maintaining the same
On segunda-feira, 16 de julho de 2012 09.38.53, Andreas Aardal Hanssen wrote:
In Qt 4 we added obsolete symbols for Qt 3, and this never caused any pain
for anybody. Qt3Support was a well intended effort to either port classes
that were dropped from Qt 3, or to wrap those around Qt 4 classes
2012/7/16 Thiago Macieira thiago.macie...@intel.com
On segunda-feira, 16 de julho de 2012 09.38.53, Andreas Aardal Hanssen
wrote:
In Qt 4 we added obsolete symbols for Qt 3, and this never caused any
pain
for anybody. Qt3Support was a well intended effort to either port classes
I am afraid I am in Can't resist mode today...
On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote:
[...]
QML has a different model for allowing normal feature development
and maintenance to be interleaved with porting the GUI, perhaps it
hasn't been explained well enough.
It's not
On Mon, 16 Jul 2012 21:19:41 ext André Pönitz wrote:
I am afraid I am in Can't resist mode today...
I'm afraid that plight is communicable over email...
On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote:
[...]
It's a major version change, what did you expect? It's a pain to
On Sun, 15 Jul 2012 23:30:13 ext Robin Burchell wrote:
Hi,
Again, looking at MeeGo's components in QtQuick2 world, I notice that
some painful changes required for porting from QML1 to QML2 are in
renaming methods, or rearranging things a bit. From the documentation:
Property and Method
On Mon, 16 Jul 2012 03:18:02 ext André Pönitz wrote:
On Mon, Jul 16, 2012 at 10:02:33AM +1000, Alan Alpert wrote:
The theory is that you're not trying to maintain a single
codebase for both QML1 and QML2.
[Maybe it's about time to run reality checks on certain
theories anyway...]
It's a
20 matches
Mail list logo
