1. 04 Jun, 2013 - 1 commit
  2. 23 May, 2013 - 1 commit
  3. 22 May, 2013 - 1 commit
  4. 02 Apr, 2013 - 1 commit
  5. 05 Feb, 2013 - 1 commit
  6. 10 Jan, 2013 - 1 commit
  7. 04 Jan, 2013 - 1 commit
  8. 11 Dec, 2012 - 1 commit
  9. 06 Dec, 2012 - 1 commit
    • Alan Alpert's avatar
      Change qFatal to qWarning · 425260c2
      Alan Alpert authored
      
      While the process should terminate immediately with a non-zero exit code
      on component error, it does that in the next line already. The main
      difference is dropping the backtrace, which is not useful in this case.
      
      Change-Id: I866ea00e62cb9d1b7c506b9819cd9bb2750ac81f
      Reviewed-by: default avatarJens Bache-Wiig <jens.bache-wiig@digia.com>
      425260c2
  10. 30 Nov, 2012 - 1 commit
  11. 26 Nov, 2012 - 1 commit
  12. 22 Nov, 2012 - 1 commit
  13. 09 Nov, 2012 - 1 commit
  14. 08 Nov, 2012 - 1 commit
  15. 05 Nov, 2012 - 1 commit
  16. 25 Oct, 2012 - 1 commit
  17. 23 Sep, 2012 - 1 commit
  18. 30 Jul, 2012 - 1 commit
  19. 26 Jul, 2012 - 1 commit
  20. 25 Jul, 2012 - 1 commit
  21. 17 Jul, 2012 - 2 commits
    • Charles Yin's avatar
      Add I18N support to qmlscene · d8fadcbf
      Charles Yin authored
      
      Task-number: QTBUG-22391
      Change-Id: Id567d4aabf47ce4790cf33979c4e464ba4f09357
      Reviewed-by: default avatarYunqiao Yin <charles.yin@nokia.com>
      d8fadcbf
    • Alan Alpert's avatar
      QQuickCanvas renames · feb996e3
      Alan Alpert authored
      
      QQuickCanvas is now called QQuickWindow
      QQuickCanvas::rootItem is now QQuickWindow::contentItem
      QQuickItem::canvas is now QQuickItem::window
      QQuickItem::ItemChangeData::canvas is also renamed window
      QQuickCanvas::grabFrameBuffer is now QQuickWindow::grabWindow
      The functions related to the color property have dropped the clear from
      their names.
      
      The first three changes have interim compatibility measures in place to
      ease the transition.
      
      Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d2
      Reviewed-by: default avatarMartin Jones <martin.jones@nokia.com>
      feb996e3
  22. 25 Jun, 2012 - 1 commit
  23. 19 Jun, 2012 - 2 commits
  24. 09 Jun, 2012 - 1 commit
  25. 28 May, 2012 - 1 commit
  26. 04 May, 2012 - 1 commit
  27. 21 Mar, 2012 - 1 commit
  28. 24 Feb, 2012 - 1 commit
  29. 14 Feb, 2012 - 1 commit
  30. 02 Feb, 2012 - 1 commit
  31. 30 Jan, 2012 - 1 commit
  32. 23 Jan, 2012 - 1 commit
  33. 17 Jan, 2012 - 1 commit
  34. 14 Dec, 2011 - 1 commit
  35. 12 Dec, 2011 - 1 commit
  36. 08 Dec, 2011 - 1 commit
    • Gunnar Sletta's avatar
      Implemented multiple windows and GL context sharing · fdd14a1a
      Gunnar Sletta authored
      
      What was traditionally the QQuickRenderLoop which was used
      to support one QQuickCanvas instance has now grown to support
      multiple QQuickCanvas instances and is now called
      QQuickWindowManager, of which there are two implementations.
      
      QQuickRenderThreadSingleContextWindowManager:
      One QSGContext and one OpenGL context is being used to draw
      all the windows and we alternate between which surface the gl
      context is bound to. This implementation relies on that
      swap does not block, but that the graphics pipeline is
      vsynced and will eventually block as the buffer queue is
      filled up. This is the behavior we get on Mac OS X and
      Wayland. The benefit of this implementation is that we have
      vsync'ed animations, and the synchronizaiton between GUI and
      render thread is simple. (well, simple relative to the
      alternative, that is).
      
      QQuickTrivialWindowManager:
      One QSGContext and one OpenGL context is being used on the GUI
      thread. Animations are ticked from a timer. Performance of this
      implementation will deteriorate if the driver is using blocking
      swap.
      
      Task-number: QTBUG-19455
      Change-Id: Ib961ac7d71eb49c70a057872b7cac020c4d19f3d
      Reviewed-by: default avatarSamuel Rødal <samuel.rodal@nokia.com>
      fdd14a1a
  37. 06 Dec, 2011 - 1 commit
  38. 02 Dec, 2011 - 1 commit
    • Kent Hansen's avatar
      Say hello to QtQuick module · 6c8378ea
      Kent Hansen authored
      
      This change moves the QtQuick 2 types and C++ API (including
      SceneGraph) to a new module (AKA library), QtQuick.
      
      99% of this change is moving files from src/declarative to
      src/quick, and from tests/auto/declarative to
      tests/auto/qtquick2.
      
      The loading of QtQuick 2 ("import QtQuick 2.0") is now delegated to
      a plugin, src/imports/qtquick2, just like it's done for QtQuick 1.
      
      All tools, examples, and tests that use QtQuick C++ API have gotten
      "QT += quick" or "QT += quick-private" added to their .pro file.
      
      A few additional internal QtDeclarative classes had to be exported
      (via Q_DECLARATIVE_PRIVATE_EXPORT) since they're needed by the
      QtQuick 2 implementation.
      
      The old header locations (e.g. QtDeclarative/qquickitem.h) will
      still be supported for some time, but will produce compile-time
      warnings. (To avoid the QtQuick implementation using the
      compatibility headers (since QtDeclarative's includepath comes
      first), a few include statements were modified, e.g. from
      "#include <qsgnode.h>" to "#include <QtQuick/qsgnode.h>".)
      
      There's a change in qtbase that automatically adds QtQuick to the
      module list if QtDeclarative is used. Together with the compatibility
      headers, this should help reduce the migration pain for existing
      projects.
      
      In theory, simply getting an existing QtDeclarative-based project
      to compile and link shouldn't require any changes for now -- but
      porting to the new scheme is of course recommended, and will
      eventually become mandatory.
      
      Task-number: QTBUG-22889
      Reviewed-by: default avatarLars Knoll <lars.knoll@nokia.com>
      Change-Id: Ia52be9373172ba2f37e7623231ecb060316c96a7
      Reviewed-by: default avatarKent Hansen <kent.hansen@nokia.com>
      Reviewed-by: default avatarSergio Ahumada <sergio.ahumada@nokia.com>
      6c8378ea