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
> >
> > > (2D accelerators are often bundled with GPUs and perform 2D rendering
> > > ops faster than GPUs, but are unusable with QML 2 / SceneGraph; se
> 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
> 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 Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote:
> 2012/7/17
> > (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 fa
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 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
2012/7/17
> > (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 conflicting in my head,
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
On 17/07/2012 06:02, ext Andreas Aardal Hanssen wrote:
>> 2012/7/17 Sven Anderson > 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, ther
2012/7/17 Sven Anderson
>
> 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 pla
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 accel
On Mon, 16 Jul 2012 09:38:53 ext Andreas Aardal Hanssen wrote:
> 2012/7/16 Alan Alpert
>
> > 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 prov
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
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
On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote:
> 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
2012/7/16 Thiago Macieira
> 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
>
> Qt3Support did enable so
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
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 sam
2012/7/16 Alan Alpert
> 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 functions to QtQuick 2
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 ol
On Mon, Jul 16, 2012 at 2:02 AM, Alan Alpert 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 answer. As
a library
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...]
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...]
> > [...] Is there really that much pain in having a
> > depreca
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 M
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 Changes
ListView's highlightMoveSpeed and highlightResizeS
25 matches
Mail list logo
