Now that Qt 5.11 is released, it is finally time to upgrade the last Qt 1.0 applications out there… No, not really. I want to take a look at how well we have kept compatibility in Qt over the years since the first official release.

Qt guarantees source and binary compatibility between minor releases, and we take that seriously. Making sure that you don’t have to rewrite (or even recompile) your application when you upgrade to a newer version of Qt is important to us. However, there are times when we need to make bigger changes in order to keep Qt up to date. This is done in major releases. Since the release of Qt 1.0 in 1996 (almost twenty-two years ago), we have broken source compatibility four times: in 2.0, 3.0, 4.0 (some of you may remember that as a painful transition), and 5.0.

We do try to keep breakages to a minimum, even in the major releases, but the changes do add up. This raises the question: How hard would it be to port a Qt application from Qt 1.0 to 5.11?

To find an answer to this question, I took the tutorial example from the Qt 1.0 release, and tried to compile it against Qt 5. Since the Qt archives only go back to version 1.41, I actually had to retrieve it from ancient history which has been preserved through four different source code control systems …but I digress. Its name is t14 because it is the 14th and final chapter of the tutorial.

Here are the steps I needed to make to get it to build and run.

• Import tutorial 14 from Qt 1.0 10 files changed, 798 insertions(+)

  This is the state of the art: the official recommendation from Troll Tech (we weren’t Trolltech yet) on how to write programs with Qt 1.0, in 1996.

• Translate to qmake 3 files changed, 2 insertions(+), 148 deletions(-)
  
  Before qmake, there was tmake. tmake was written in Perl. The basic syntax was the same, except that qmake no longer allows embedding Perl code in the project files. This is probably for the best…

  Also, tmake was not public, so we would generate Makefiles for the release packages. Having completely different internal and external build systems added excitement to the release process.

• Fix include file names 4 files changed, 8 insertions(+), 8 deletions(-)
  
  Back in the old days, Windows only allowed eight character file names. We did have proper include files on Unix, but if you wanted your code to be portable, you had to use wonderful names like "qscrbar.h" and "qbttngrp.h".
• Add missing includes 1 file changed, 3 insertions(+)

  Dependency on indirect includes was a problem back then as well.

• Change TRUE/FALSE to true/false 1 file changed, 13 insertions(+), 13 deletions(-)
  
  Kids these days. They don’t know how lucky they are. We had to make our own bool type.
• Fix things moved to the Qt:: namespace 3 files changed, 15 insertions(+), 15 deletions(-)
  
  The Qt namespace was introduced in 1998 … as a class, since we didn’t have those fancy namespaces back then.
• Remove “name” argument 6 files changed, 26 insertions(+), 26 deletions(-)
  
  All constructors of QObject subclasses used to take the object name as a parameter.
• The QScrollBar API has changed 1 file changed, 5 insertions(+), 5 deletions(-)
  
  Sometimes we have to get rid of old, bad APIs. Having individual setter functions is much better than a constructor that takes 7 arguments.
• Use QString instead of const char * 2 files changed, 2 insertions(+), 2 deletions(-)
  
  QString has been in Qt since 1994. It used to be 8 bit Latin1 with an automatic cast to const char*, so the API would use const char * arguments. Unicode support was introduced in Qt 2.0.
• warning() is called qWarning() now 1 file changed, 1 insertion(+), 1 deletion(-)

  We avoid putting identifiers into the global namespace. Except for the letter ‘Q’. We own that.

• Remove calls to old QApplication functions 1 file changed, 2 deletions(-)
  
  Qt does the right thing automatically these days. In 1996, most displays used 8 bits per pixel. You had to tell Qt if you wanted to use other colors than the 256 standard ones.
• Replace QAccel with QShortcut 1 file changed, 4 insertions(+), 3 deletions(-)
  
  QShortcut is more powerful and easier to use, and the name is not an abbreviation. It was introduced in 2004.
• Fix repaint logic 1 file changed, 7 insertions(+), 7 deletions(-)
  
  In the ’90s, we could just paint directly onto the widgets whenever we wanted. Nowadays everything is buffered and composed, so we have to make an update request, and later repaint the widget when we get a go-ahead. Fortunately, this simplifies the logic.
• QObject::killTimers() doesn’t exist anymore 2 files changed, 3 insertions(+), 2 deletions(-)
  
  This function was just too dangerous. It would kill all timers belonging to an object, including those used by Qt internally. Now you have to kill timers individually.
• QWMatrix is now QMatrix 1 file changed, 2 insertions(+), 2 deletions(-)

  A simple name change.

• QWidget::setBackgroundColor() is gone. 1 file changed, 3 insertions(+), 1 deletion(-)
  
  Background color is no longer a separate concept: it’s wrapped inside QPalette together with all the other color roles. Also, child widgets are now transparent by default. We have to tell Qt to draw the background.
• Can’t fill pixmap with contents of widget anymore 1 file changed, 1 insertion(+), 1 deletion(-)
  
  We use a transparent pixmap instead, since Qt supports that now.
• Rectangle painting has changed since Qt 1.0 1 file changed, 1 insertion(+), 1 deletion(-)
  
  This is the worst incompatibility so far: In Qt 4.0 QPainter::drawRect() was changed so that “a stroked rectangle has a size of rectangle.size() plus the pen width”. Therefore, we need to subtract the pen width (i.e. 1) before passing the rectangle to QPainter.

Now we have a fully functional port of the tutorial example, and here is a screenshot:

Oops… Some of the text is clipped. It turns out that the example used hardcoded sizes and positions for most of the elements, and font sizes have changed a bit since 1996. The solution is to use QLayout, which was not available in Qt 1.0 (the first version was added in Qt 1.1, and it was completely rewritten for 2.0).

• Use layouts instead of hardcoded sizes 4 files changed, 29 insertions(+), 24 deletions(-)
  

With this change, everything looks as it should:

So, what did we learn? It did not take that much effort to port tutorial 14 from Qt 1.0 to Qt 5.11. It probably took me longer to write this blog post. Most of the 1.0 API still lives on in recognizable form. The incompatible changes have improved the usability, readability and safety of Qt code.

This was just a small example, of course. Porting a full-sized application across multiple major versions would probably be more difficult. Fortunately, we have a vibrant Qt ecosystem with several companies offering consultancy services .

The post Porting guide from Qt 1.0 to 5.11 appeared first on Qt Blog.

The forthcoming new release of Plasma 5.13 will have some lovely new features such as rewritten System Settings pages and Plasma Browser Integration.  But we need testers.

Incase you missed it the Plasma 5.13 release announce has a rundown of the main features.  If you are an auditory learner you can listen to the Late Night Linux Extra podcast where Jonathan “great communicator” Riddell talks about the recent sprint and the release.

You can test it out with the KDE neon Developer Edition Git-Stable ISO which you can download now.  Git-stable includes beta builds of KDE’s software.  Or you can try the latest KDE neon Docker image which runs the desktop inside Xephyr with a simple command of neondocker -e dev-stable.

What have the public been saying about Plasma 5.13 beta? Let’s pick some random comments from Reddit:

br_shadow – Plasma is by far the best linux DE

Thanks br_shadow!

aturfer 26 points 3 days ago – I’m going to make another financial donation to the KDE project.

Good idea aturfer!

mleko69 3 days ago

> KDE Plasma

> lightweight

What a time to be alive

KDAB is a major sponsor of this event and a key independent contributor to Qt as our blogs attest.

Every year, dedicated Qt contributors gather at Qt Contributors’ Summit to share with their peers latest knowledge and best practices, ensuring that the Qt framework stays at the top of its game. Be a Contributor to Qt!

We look forward to meeting you in Oslo!

The post KDAB at Qt Contributor’s Summit 2018, Oslo appeared first on KDAB.

This weekend, Krita developers and artists from all around the world came to the sleepy provincial town of Deventer to buy cheese — er, I mean, to discuss all things Krita related and do some good, hard work! After all, the best cheese shop in the Netherlands is located in Deventer. As are the Krita Foundation headquarters! We started on Thursday, and today the last people are leaving.

Image by David Revoy

Events like these are very important: bringing people together, not just for serious discussions and hacking, but for lunch and dinner and rambling walks makes interaction much easier when we’ve gone back to our IRC channel, #krita. We didn’t have a big sprint in 2017, the last big sprint was in 2016.

So… What did we do? We first had a long meeting where we discussed the following topics:

• 2018 Fund Raiser. We currently receive about €2000 a month in donations and have about eighty development subscribers. This is pretty awesome, and goes a long way towards funding Dmitry’s work. But we still want to go back to having a yearly fund raiser! We aim for September. Fund raisers are always a fun and energizing way to get together with our community. However, Kickstarter is out: it’s a bit of tired formula. Instead we want to figure out how to make this more of a festival or a celebration. This time the fund raiser won’t have feature development as a target, because…
• This year’s focus: zarro bugs. That’s what bugzilla used to tell you if your search didn’t find a single bug. Over the past couple of years we’ve implemented a lot of features, ported Krita to Qt5 and in general produced astonishing amounts of code. But not everything is done, and we’ve got way too many open bug reports, way too many failing unittests, way too many embarrassing hits in pvs, way too many features that aren’t completely done yet — so our goal for this year is to work on that.
• Unfinished business: We identified a number of places where we have unfinished business that we need to get back to. We asked the artists present to rank those topics, and this is the result:
  • Boudewijn will work on:
    • Fix resource management (https://phabricator.kde.org/T379).
    • Shortcut and canvas input unification and related bugs
    • Improved G’Mic integration
  • Dmitry will work on:
    • Masks and selections
    • Improving the text layout engine, for OpenType support, vertical text, more SVG2 text features.
    • SVG leftovers: support for filters and patterns, winding mode and grouping
    • Layer styles leftovers
  • Jouni will work on animation left-overs:
    • frame cycles and cloning
    • Transform mask interpolation curves
  • Wolthera will work on
    • Collecting information about missing scripting API
    • Color grading filters
• Releases. We intend to release Krita 4.1.0 June 20th. We also want to continue doing monthly bug-fix releases. We’ve asked the KDE system administrators whether we can have nightly builds of the stable branch so people can test the bug fix releases before we actually release them. Krita 4.1 will have lots of animation features, animation cache swapping, session management and the reference images tool — and more!

We also discussed the resource management fixing plan, worked really hard on making the OpenGL canvas work even smoother, especially on macOS, where it currently isn’t that smooth, added ffmpeg to the Windows installer, fixed translation issues, improved autosave reliability, fixed animation related bugs and implemented support for a cross-channel curves filter for color grading. And at the same time, people who weren’t present worked on improving OpenEXR file loading (it’s multi-threaded now, among other things), fixed issues with the color picker and made that code simpler and added even more improvements to the animation timeline!

And that’s not all, because Wolthera, Timothee and Raghukamath also finished porting our manual to Sphinx, so we can generate off-line documentation and support translations of the manual. The manual is over 1000 pages long!

There were three people who hadn’t attended a sprint before, artist Raghukamath, ace windows developer Alwin Wong and Valeriy Malov, the maintainer of the KDE Plasma desktop tablet settings utility, who improved support for cintiq-like devices during the weekend.

And of course, there was time for walks, buying cheese, having lunch at our regular place, De Rode Kater, and on Sunday the sun even started shining! And now back to coding!

Image by David Revoy.

The 2018 Krita sprint was sponsored by KDE e.V. (travel) and the Krita Foundation (accommodation and food).

After more than a year of work, I’m pleased to release another version of heaptrack, the Linux memory profiler! The new version 1.1.0 comes with some new features, significant performance improvements and – most importantly – much improved stability and correctness. If you have tried version v1.0 in the past and encountered problems, update to the new v1.1 and try again!

Notable Changes

The most effort during this release cycle was spent on improving the correctness of heaptrack. The initial version suffered from bugs that could lead to corrupted or truncated data files. Heaptrack v1.1 is generally much better in this regard, and you should be able to use it in more situations than before. Furthermore, attaching heaptrack to an already-running process will catch more allocations and thus produce more accurate data. To verify the quality of the heaptrack code base, more tests have been added as well. These tests also finally enable us to use Valgrind or the Sanitizers on most of the heaptrack code, which wasn’t possible previously.

Additionally, some important new features have been added which greatly improve the usability of heaptrack:

1. When extended debug information is available, stack traces now include inlined frames.
2. Split debug information in separate files is now supported.
3. Compressed debug information is properly handled.
4. The embedded flamegraph view is now searchable.

Finally, quite some work went into optimizing heaptrack to further reduce its overhead. The initial version was quite good already from a performance point of view, but version 1.1 is even better! Most notably, the analysis of large data files is now often much faster. This is in great parts due to the new optional dependency on zstd. This fantastic state-of-the-art compression algorithm greatly reduces the CPU overhead during recording while compressing the heaptrack data. But not only that – decompression at analysis time is significantly reduced compared to the standard gzip compression. In case you wonder: Data files are now often slightly smaller too!

Last but not least, heaptrack v1.1.0 can be downloaded as a portable AppImage which should run on most 64bit Linux systems in use these days!

Download heaptrack v1.1.0

If possible, wait for your distribution to provide you with an updated package for heaptrack v1.1.0. Otherwise, download the AppImage, make it executable and run it. If neither of these two options works for you, grab the sources and compile the code for your target platform:

• 64bit AppImage: heaptrack-v1.1.0-x86_64.AppImage (GPG signature)
• Sources: heaptrack-1.1.0.tar.xz (GPG signature)

The GPG signatures have been created by Milian Wolff with the key A0C6B72C4F1C5E7C.

Many thanks to the various people who contributed to this release. Please continue to hand in your patches, preferably via KDE’s phabricator instance or via heaptrack on GitHub. Bugs can be reported on bugs.kde.org.

If your company needs commercial support for heaptrack, then get in touch with us at KDAB. We offer workshops and trainings specifically about profiling and debugging on Linux.

The post Heaptrack v1.1.0 release appeared first on KDAB.

WebAssembly is now supported by all major web browsers as a binary format for allowing sand-boxed executable code in web pages that is nearly as fast as native machine code. Qt for WebAssembly makes it possible to run Qt applications on many web browsers without any download steps or special server requirements (other than serving the wasm file).

To give you a closer look, we compiled some demos. For best performance, use Firefox.

Here is the complete list along with some descriptions:

http://example.qt.io/qt-webassembly/opengl/hellowindow/hellowindow.html
An example which renders a Qt logo using OpenGL calls. This example shows that you can also use this for custom OpenGL code.

http://example.qt.io/qt-webassembly/SensorTagDemo/SensorTagDemo.html
A larger example of an interesting industry automation use case. In principle, it is possible to show live data retrieved using Qt WebSockets, but this is just showing generated dummy data for illustration purposes.

http://example.qt.io/qt-webassembly/quickcontrols2/gallery/gallery.html
A gallery of available controls in Qt Quick Controls 2. This shows that you can use Qt Quick and Qt Quick Controls 2 to make your web-deployed applications.

http://example.qt.io/qt-webassembly/widgets/richtext/textedit/textedit.html
A simple text editor, written with Qt Widgets. This example shows that you can also use Qt Widgets to create your web-deployed applications.

As always, let us know what you think!

The post Qt for WebAssembly – check out the examples! appeared first on Qt Blog.

Are you using Kubuntu 18.04, our current LTS release?

We currently have the Plasma 5.12.5 LTS bugfix release available in our Updates PPA, but we would like to provide the important fixes and translations in this release to all users via updates in the main Ubuntu archive. This would also mean these updates would be provide by default with the 18.04.1 point release ISO expected in late July.

The Stable Release Update tracking bug can be found here: https://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1768245

A launchpad.net account is required to post testing feedback as bug comments.

The Plasma 5.12.5 changelog can be found at: https://www.kde.org/announcements/plasma-5.12.4-5.12.5-changelog.php

[Test Case]

* General tests:
– Does plasma desktop start as normal with no apparent regressions over 5.12.4?
– General workflow – testers should carry out their normal tasks, using the plasma features they normally do, and test common subsystems such as audio, settings changes, compositing, desktop affects, suspend etc.

* Specific tests:
– Check the changelog:
– Identify items with front/user facing changes capable of specific testing. e.g. “weather plasmoid fetches BBC weather data.”
– Test the ‘fixed’ functionality.

Testing involves some technical set up to do, so while you do not need to be a highly advanced K/Ubuntu user, some proficiently in apt based package management is advisable.

Details on how to enable the propose repository can be found at: https://wiki.ubuntu.com/Testing/EnableProposed.

Unfortunately that page illustrates Xenial and Ubuntu Unity rather than Bionic in Kubuntu. Using Discover or Muon, use Settings > More, enter your password, and ensure that Pre-release updates (bionic-proposed) is ticked in the Updates tab.

Or from the commandline, you can modify the software sources manually by adding the following line to /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu/ bionic-proposed restricted main multiverse universe

It is not advisable to upgrade all available packages from proposed, as many will be unrelated to this testing and may NOT have been sufficiently verified as updates to assume safe. So the safest but a little involved method would be to use Muon (or even synaptic!) to select each upgradeable packages with a version containing 5.12.5-0ubuntu0.1 (5.12.5.1-0ubuntu0.1 for plasma-discover due to an additional update).

Please report your findings on the bug report. If you need some guidance on how to structure your report, please see https://wiki.ubuntu.com/QATeam/PerformingSRUVerification. Testing is very important to the quality of the software Ubuntu and Kubuntu developers package and release.

We need your help to get this important bug-fix release out the door to all of our users.

Thanks! Please stop by the Kubuntu-devel IRC channel or Telegram group if you need clarification of any of the steps to follow.

Yes, folks. This year SIGGRAPH 2018 is in Canada and we’ll be there at the Qt booth, showing off our latest tooling and demos. These days, you’d be surprised where Qt is used under the hood, even by the biggest players in the 3D world!

SIGGRAPH 2018 is a five-day immersion into the latest innovations in CG, Animation, VR, Games, Digital Art, Mixed Reality and Emerging Technologies. Experience research, hands-on demos, and fearless acts of collaboration.

Meet us at SIGGRAPH 2018!

Book your place for the most exciting 3D event of the year!

The post KDAB at SIGGRAPH 2018 appeared first on KDAB.

KDAB is proud to be bronze sponsor at Italian C++ Conference, the largest conference in Italy specifically focused on C++ development for professionals, students and businesses using C++.

It’s free, organized by the Italian C++ community, and there’s Italian icecream to think about too… It’s an offer you can’t refuse ��

Sign up and see you in Milan in June!

The post KDAB at Italian Cpp 2018 appeared first on KDAB.

Once more in Florence, QtDay Italy is almost upon us and we’ll be there.

Giuseppe D’Angelo will be giving a talk on Gammaray, KDAB’s open source profiling and debugging tool.

GammaRay is a “high-level debugger”, able to show the status of various Qt subsystems inside an application, with an easy to use interface (that does not require any knowledge of Qt internals). GammaRay can, amongst other things, show the properties of any QObject in the application, show the status of all state machines, inspect and debug layouting and stacking of both widgets and Qt Quick applications, analyze raster painting, show the 3D geometry in a Qt3D scene, and much more.

This talk introduces the basics of GammaRay usage, with some interesting cases as examples of problem solutions.

See you in Florence!

The post QtDay Italy, May 23-24 appeared first on KDAB.

@tetris4 wrote:

Also available in Italian and Taiwanese Mandarin.

Hello everyone!

On your next system upgrade you will receive all the latest versions of KDE’s Plasma, Applications and Frameworks, in addition to several other package updates. For more details and the full changelogs on KDE’s software releases, you can read the official announcements:

• Plasma 5.12.5
• Applications 18.04.1
• Frameworks 5.46.0

Other noteworthy package updates include wine 3.8, skypeforlinux 8.20.0.9 and pypy 6.0.0.

konqi.png800x580 281 KB

Konqis by KDE under CC BY-SA

It should be safe to answer yes to any replacement question by the package manager application. If in doubt or if you face another issue in relation to this update, please ask or report it below.

Most of our mirrors take 12-24 hours to synchronize with the central repositories on the origin server. Use the mirror status web page to see when your mirror of choice last synchronized.

Enjoy!

Posts: 1

Participants: 1

Read full topic

Now that the beta 1 release of Qt 3D Studio 2.0 is out, let’s go through the steps involved in trying it out for real.

Pre-built runtime binaries

As outlined in last year’s post, the runtime component of Qt 3D Studio has undergone significant changes. This means that the Viewer application that is launched whenever pressing the green “Play” button in Qt 3D Studio and, more importantly, the C++ and QML APIs with the engine underneath, have all been rewritten in the familiar Qt-style C++ on top of Qt 3D. In practice the runtime is an ordinary Qt module, providing both C++ libraries with classes like Q3DSWidget, Q3DSPresentation, etc. and a QML plugin Studio3D and friends.

The releasing of the pre-built binaries for the runtime has improved a lot for version 2.0: there is now a dedicated entry in the Qt installer which will install the necessarily files alongside the normal Qt installation, so pulling in the runtime via QT += 3dstudioruntime2 or by import QtStudio3D 2.0 in QML will work out of the box in a fresh Qt installation. No more manual building from sources is needed (except when targeting certain platforms).

Let’s Install

At the moment Qt 3D Studio binaries are provided for Windows and macOS. Linux may be added in future releases. It is worth noting that this does not mean the runtime is not suitable for running on Linux (or Android or QNX or INTEGRITY, for that matter) – it, like the most of Qt, will build (cross-compile even) and run just fine, assuming a well-working OpenGL implementation is available for your platform. (however, glitches can naturally be expected with less stable and complete graphics stacks) So while we expect the design work in the Qt 3D Studio application done on Windows or macOS for now, Qt applications using the created 3D presentations can be developed on and deployed to all the typical Qt target platforms.

When launching the online installer, take note of the following entries. Note that the layout and the location of these items may change in the installer in beta 2 and beyond. What is shown here is how things look as of 2.0 beta 1.

The runtime depends on Qt 5.11, meaning it must be installed together with 5.11.0 (or a future release, here we will use the release candidate).

In the example run shown on the screenshots we opted for Visual Studio 2015, but choosing something else is an option too – the installer takes care of downloading and installing the right set of pre-built binaries for the Qt 3D Studio runtime.

Once installation is finished, you will have the Qt 5.11 RC, a recent version of Qt Creator, Qt 3D Studio 2.0 beta 1, and the necessary runtime libraries all in place.

Let’s Design

Launching Qt 3D Studio and opening the example project from <installation root>\Tools\Qt3DStudio-2.0.0\examples\studio3d\SampleProject should result in something like the following.

For details on what can be done in the designer application, check the documentation. Speaking of which, the documentation for Qt 3D Studio has been split into two parts in version 2.0: the runtime has its own documentation set with the API references, introduction, system requirements, and other topics. (the links are currently to doc-snapshots, the contents will move to doc.qt.io later on)

Let’s Code

Designing the presentation is only half of the story. Let’s get it into a Qt application.

Here we will code an example from scratch. Regardless, you may want to look at the runtime’s examples first. These ship in <installation root>examples\Qt-5.11.0\3dstudioruntime2.

The qmldatainput example in action

For now, let’s start with an empty project. Launch Qt Creator and create a new, empty Qt Quick project targeting Qt 5.11.

The application template gives us a main QML file like this:

When the runtime is installed correctly alongside Qt, we can add the following to make our Qt Quick application load up a Qt 3D Studio presentation and compose it with the rest of the Qt Quick scene.

    ...
    import QtStudio3D 2.0
    
    Window {
        ...
        Studio3D {
            anchors.fill: parent
            anchors.margins: 10
            Presentation {
                source: "file:///c:/QtTest/Tools/Qt3DStudio-2.0.0/examples/studio3d/SampleProject/SampleProject.uip"
            }
        }
    }

(replace c:\QtTest as appropriate)

In many real world applications it is quite likely that you will want to place the presentation’s files and assets into the Qt resource system instead, but the raw file references will do as a first step.

Launching this gives us quite impressive results already:

What we see there is the live Qt 3D Studio presentation rendered by the new Qt3D-based engine into an OpenGL texture which is then used by the Qt Quick scenegraph when drawing a textured quad for the Studio3D element. The keyframe-based animations should all run as defined in the Qt 3D Studio application during the design phase.

Now, a common misconception is that Qt 3D Studio is merely a designer tool and the scenes created by it are static with no runtime modifications possible when loaded up in Qt applications. This is pretty incorrect since applications have full control over

• the timeline (both the main and the Component timelines),
• the current slide,
• and many attributes (properties) of the objects (e.g. the 3D models and the corresponding materials) in the scene.

Future versions of Qt 3D Studio are expected to extend the capabilities further, for example with adding APIs to spawn and destroy objects in the scene dynamically.

Let’s change that somewhat annoying text in the middle of the scene, using a button from Qt Quick Controls 2. Whenever the button is clicked, the attribute corresponding to the text rendered by the Text node in the Qt 3D Studio scene will be changed.

Option 1: Direct Attribute Access

When digging down the scene structure at the left of the timline pane, take note of the fact that the Text node has a convenient, unique name already (DateAndTime). This is good since it means we can refer to it without further ado in the application code:

...
import QtQuick.Controls 2.2

Window {
    ...

    Studio3D {
        anchors.fill: parent
        anchors.margins: 10
        Presentation {
            id: pres
            source: "file:///c:/QtTest/Tools/Qt3DStudio-2.0.0/examples/studio3d/SampleProject/SampleProject.uip"
        }

        Button {
            text: "Change text"
            anchors.bottom: parent.bottom
            anchors.horizontalCenter: parent.horizontalCenter
            onClicked: pres.setAttribute("DateAndTime", "textstring", "Hello World")
        }
    }
}

For details on this approach, check out the documentation for Presentation and the attribute name table.

Clicking the button results in changing the ‘textstring’ property of the Text node in the Qt 3D Studio presentation. The change is then picked up by the Qt 3D Studio engine, leading to changing the rendered text.

Option 2: Data Input

While changing properties via setAttribute & co. is simple and effective, Qt 3D Studio also supports another approach: the so-called data inputs. With data inputs, the designers of the 3D scene decide which attributes are controllable by the applications and assign custom names to these. This way a well-known, fixed interface is provided from the designers to the application developers. The example presentation we are using here exposes the following data inputs. (and note the orange-ish highlight for Text String in the Inspector Control in the bottom right corner)

The name dateAndTime is associated with the textstring property of the DateAndTime Text node. Let’s control the value via this approach:

...
import QtQuick.Controls 2.2

Window {
    ...

    Studio3D {
        anchors.fill: parent
        anchors.margins: 10
        Presentation {
            id: pres
            source: "file:///c:/QtTest/Tools/Qt3DStudio-2.0.0/examples/studio3d/SampleProject/SampleProject.uip"

            property string text: ""
            DataInput {
                name: "dateAndTime"
                value: pres.text
            }
        }

        Button {
            text: "Change text"
            anchors.bottom: parent.bottom
            anchors.horizontalCenter: parent.horizontalCenter
            onClicked: pres.text = "Hello World"
        }
    }

Here the Text node starts up with a textstring value of “” (but note there is no actual reference to “textstring” anywhere in the application code), while clicking the button results in changing it to “Hello World”. What’s more, we can now use the usual QML property binding methods to control the value.

That is all for now. Expect more Qt 3D Studio related posts in the near future.

The post Get Started with Qt 3D Studio 2.0 beta 1 appeared first on Qt Blog.