A couple of years ago during a hackathon, a couple of us wrote a Qt wrapper around PDFium, the open-source PDF rendering engine which is used for viewing PDFs in Chromium.  There have been a few fixes and improvements since then.  Now we (finally) have made this module available under the LGPLv3 license.

QPdfDocument can render a PDF page to a QImage, and there is QPdfBookmarkModel which can be used for a bookmarks view. There is an example application: a widget-based PDF viewer.

If you want to try it out, here’s how to get started:

git clone git://code.qt.io/qt-labs/qtpdf
cd qtpdf
git submodule update --init --recursive
qmake
make
cd examples/pdf/pdfviewer
qmake
make
./pdfviewer /path/to/my/file.pdf

There is some work in progress to add support for PDF in QtQuick, to treat it as an ordinary image format and to add support for multi-page image formats in general, but we don’t have any particular target release date yet.

The post New QtLabs PDF module appeared first on Qt Blog.

Note that throughout this blog post, the term “Apple Platforms” will be used to refer to all four Apple operating systems (macOS, iOS, tvOS, and watchOS) as a whole.

I thought it would be a good time to share some of the highlights of what’s new in Qt on Apple Platforms with the recent release of Qt 5.8.

New Platforms

To start off, Qt now has Technology Preview level support for Apple TV and Apple Watch devices beginning in Qt 5.8. This completes our offering to support all four Apple Platforms – macOS, iOS, tvOS, and watchOS.

tvOS (Apple TV)

Qt for tvOS is 95% similar to iOS (even the UI framework is also UIKit) and as a result, contains roughly the same feature set and supported modules as iOS, with the notable exception of QtWebEngine.

The major difference between the two platforms is input handling. iOS has a touch-based model that maps fairly well to a traditional point and click desktop interface from a programming perspective, while tvOS has a focus based model. This means that you don’t have a canvas which can receive input at a particular point (x,y coordinate), but rather an abstract canvas in which you “move” the focus to a particular object. When an object has focus, you can use the Apple TV Remote to trigger an action by clicking its trackpad or pressing the Menu or Play/Pause buttons.

Qt supports some aspects of the tvOS input model (scrolling and clicking are recognized), but there will be some degree of manual work handling input events in QML to build a tvOS app. Most basic navigation actions on the Apple TV Remote are exposed as keyboard events in Qt, and gesture recognizers can be used for more complex multitouch input. We are still exploring ways to provide mechanisms that make it easier to work with this new input model.

We’d also like to thank Mike Krus doing the initial work of porting Qt to tvOS, and who is now the platform’s maintainer.

watchOS (Apple Watch)

Qt for watchOS is also heavily based on iOS. However, it is not possible to run QML or any other Qt based UI on the watch using public APIs because the primary interface API is WatchKit (as opposed to UIKit). Therefore, Qt can currently only be used for non-UI tasks such as networking, audio, backend graphics processing, etc. If the available watchOS APIs change in the future then we can certainly explore the possibilities at that point.

I am also the watchOS platform maintainer, so please feel free to send me any questions or feedback.

Shared Libraries on iOS

Only static libraries were permitted for most of iOS’s existence, as many iOS developers are no doubt aware. Apple’s App Store requirements prohibited shared libraries even though the underlying operating system supported them since 1.0. Finally, with the release of iOS 8 and Xcode 6 in 2014, shared libraries/frameworks became officially supported by Apple for use in applications submitted to the App Store. Unfortunately, while this feature did not make it in time for the Qt 5.8 release… Qt 5.9 will support them too (also for tvOS and watchOS)!

To build Qt as shared libraries on iOS, all you need to do is pass the -shared option to configure (and this will be the default in the next release). Note that shared libraries require a deployment target of at least iOS 8.0, which will also be the minimum requirement for Qt 5.9.

With shared libraries, you can simplify your development workflow by not having to maintain separate code paths for static libraries on iOS and shared libraries on other platforms. Shared libraries also allow you to:

• When using App Extensions (as both your main application and your extension executables may link to the same copy of the Qt frameworks), reduce memory consumption and reduce disk space consumption on your users’ devices as your app will be smaller
• Make your code base easier to maintain through strict API boundaries and the benefits of namespacing
• Speed up linking and thus overall build time

Because the question will inevitably come up: we do not believe shared libraries will have any practical effect for LGPL users. There are other concerns that come into play with the Apple App Store (namely, DRM) which render the point moot. However, we recommend using shared libraries for the technical reasons outlined above. And as always, seek professional legal advice with regard to software licensing matters.

Build System Enhancements

In the past several Qt releases we have also made a number of significant enhancements to the build system on Apple Platforms, including:

• @rpath in the install names of Qt libraries, providing relocatability out of the box (Qt 5.5)
• Standalone .dSYM debug symbols (Qt 5.6.1, Qt 5.6.2)
• Building asset catalogs (Qt 5.6.3 & Qt 5.7.1)
• Bitcode on iOS which allows Qt applications to take advantage of App Thinning (Qt 5.8)
• Precompiled headers on iOS, tvOS, and watchOS, reducing build time by up to 30% (Qt 5.8)
• Combined simulator and device builds, doing away with the confusing separate _simulator libraries on iOS (Qt 5.8)
• Multi-arch (“universal”) builds on macOS, back from Qt 4.x (coming in Qt 5.9)
• Automatically embedding Qt frameworks within a Qt app bundle in qmake-generated Xcode projects (coming in Qt 5.9)
• …and many other smaller bug fixes

One more thing… we’ve been changing every reference to “Mac OS X” and “OS X” that we can find into “macOS”. ��

The post What’s New in Qt on Apple Platforms appeared first on Qt Blog.

Today the Kubuntu team is happy to announce that Kubuntu Zesty Zapus (17.04) is released today. With this Alpha 2 pre-release, you can see what we are trying out in preparation for 17.04, which we will be releasing in April.

NOTE: This is Alpha 2 Release. Kubuntu Alpha Releases are NOT recommended for:

* Regular users who are not aware of pre-release issues
* Anyone who needs a stable system
* Anyone uncomfortable running a possibly frequently broken system
* Anyone in a production environment with data or work-flows that need to be reliable

Getting Kubuntu 17.04 Alpha 2
* Upgrade from 16.10, run do-release-upgrade from a command line.
* Download a bootable image (ISO) and put it onto a DVD or USB Drive

While working on the Qt Visual Studio tools, I had to think about how to locally perform and test the update process for extensions. As already known to most Visual Studio users, the IDE provides a way to setup your own private extension gallery. To do so, one has to open the Visual Studio Tools | Options Dialog and create a new Additional Extension Gallery under Environment | Extensions and Updates.

My initial try was to simply put the generated VSIX into a folder on the disk and point the URL field to this folder. After looking at the Tools | Extensions and Updates dialog, no update was highlighted for the tools. Because this was not as easy as I had thought, so some configuration file probably needed to be provided. A short search on the Internet led to the following article – there we go, it turned out that the configuration file is based on the Atom feed format.

Visual Studio uses an extended version of the Atom feed format consisting of two parts, the Header and the Entry. The header needs to be provided only once, while the entry can be repeated multiple times. Lets take a look at the header tags:

<title> The repository name.
<id> The unique id of the feed.
<updated> The date/time when the feed was updated.

Please note that even though these tags do not seem to be important for the desired functionality, it still makes sense to keep them.

The more interesting part is the Entry tag that describes the actual package you’re going to share. There seem to be a lot of optional tags as well, so I’m just going to describe the most important one. To force an update of your package, simply put an <Vsix> inside the entry tag. It must contain two other tags:

<id> The id of your VSIX.
<version> The version of the VSIX.

As soon as you increase the version number, even without rebuilding the VSIX, Visual Studio will present you with an update notice of your package. For a more advance description of the tags possible, follow this link. If you are looking for the minimum Atom feed file to start with, you can grab a copy of ours here.

So now one might ask, why did I write all that stuff? Well, while I was preparing the next Qt Visual Studio Tools release I scratched my head quite a bit on this topic. And just maybe – it might save some other developer’s day while doing a Visual Studio extension release. Last but not least, I am happy to announce the availability of an updated version of the Qt Visual Studio Tools with the following improvements:

• Bug fixes
• Making it faster
• Using the new TextMate language files in Visual Studio 2015 SP3 for QML file and QMake project file syntax highlighting

The Qt Company has prepared convenient installers for the Qt Visual Studio Tools 2.1 release. You can download it from your Qt Account or from download.qt.io. They are also available from the Visual Studio Gallery for Visual Studio 2013 and Visual Studio 2015.

For any issues you may find with the release, please submit a detailed bug report to bugreports.qt.io (after checking for duplicates). You are also welcome to join the discussions in the Qt Project mailing lists, development forums and to contribute to Qt.

The post Qt Visual Studio Tools Insights appeared first on Qt Blog.

As many of you may know, QPainter has a multi-backend architecture and has two main paint engine implementations under the hood in Qt 5: the raster paint engine and the OpenGL2 paint engine, designed for OpenGL ES 2.0.

The GL Paint Engine

While in many ways the raster paint engine can be considered one of Qt’s crown jewels, let’s now talk about the other half: the GL paint engine that is used when opening a QPainter on

• a QOpenGLWindow,
• a QOpenGLWidget,
• or a QOpenGLPaintDevice, which can wrap any current context and render target, and is mainly used when targeting FBOs.

The Problem

What about modern OpenGL, though?

That is where the problems started appearing: around Qt 5.0 those who were in need of a core profile context due to doing custom OpenGL rendering that needed this ended up running into roadblocks quite often. Components like Qt Quick were initially unable to function with such contexts due to relying on deprecated/removed functionality (for example, client-side pointers), lacking a vertex array object, and supplying GLSL shaders of a version the support for which is not mandated in such contexts.

In some cases opting for a compatibility profile was a viable workaround. However, Mac OS X / macOS famously lacks support for this: there the choice has been either OpenGL 2.1 or a 3.2+ core profile context. Attempts to work this around by for instance rendering into textures in one context and then using the texture in another context via resource sharing were often futile too, since some platforms tend to reject resource sharing between contexts of different version/profile.

Progress

Fortunately, during the lifetime of Qt 5 things have improved a lot: first Qt Quick, and then other, less user-facing GL-based components got fixed up to be able to function both with core and compatibility contexts.

As of Qt 5.8 there is one big exception: the GL paint engine for QPainter.

The Last Missing Piece

The good news is, this will soon no longer be the case. Thanks to a contribution started by Krita, see here for some interesting background information, QPainter is becoming able to function in core profile contexts as well. Functionality-wise this will not bring any changes, rendering still happens using the same techniques like before.

In addition to fixing up the original patch, we also integrated it with our internal QPainter regression testing system called Lancelot. This means that in addition to raster (with various QImage formats) and OpenGL 2, there will also be a run with a core profile context from now on, to ensure the output from QPainter does not regress between Qt releases.

All in all this means that a snippet like the following is now going to function as expected.

  class Window : public QOpenGLWindow {
    void initializeGL() override {
      QSurfaceFormat fmt;
      fmt.setVersion(4, 5); // or anything >= 3.2
      fmt.setProfile(QSurfaceFormat::CoreProfile);
      setFormat(fmt);
    }
    void paintGL() override {
      QPainter p(this);
      p.fillRect(10, 10, 50, 50, Qt::red);
      ...
    }
    ...
  };

When?

Qt 5.9.

The patch has now been merged to qtbase in the ‘dev’ branch. This will soon branch out to ‘5.9’, which, as the name suggests, will provide the content for Qt 5.9. Those who are in urgent need of this can most likely apply the patch (see QTBUG-33535) on top of an earlier version – the number of conflicts are expected to be low (or even zero).

That’s all for now, have fun with QPainter in core profile contexts!

The post OpenGL Core Profile Context support in QPainter appeared first on Qt Blog.

The last post from my colleague Marc Mutz about deprecating Q_FOREACH caused quite an uproar amongst the Qt developers who follow this blog.

I personally feel that this was caused fundamentally by a perceived threat: there is a cost associated to porting away a codebase from a well-known construct (Q_FOREACH) to a new and yet-undiscovered construct (C++11’s range based for), especially when the advantages are not that clear. (With stronger advantages, maybe people would be more keen to move away).

A somehow opposite argument can be applied to Qt itself, however. There is a cost at keeping Q_FOREACH around in Qt. For instance:

• it actually generates worse code than a range-based for, so it’s not suitable for usage in a general purpose library such as Qt (remember: in a library, all the codepaths are hot codepaths for some user);
• we must maintain its code, make sure that it compiles without warnings, it gets tested and works on all the reference platforms (over 50 at the time of this writing);
• we must document its usage, have examples about it, and explain to our C++11 users (or users who come from Boost) what the differences are between Q_FOREACH, Boost.Foreach and the range based for.

On deprecated APIs in Qt

This is not going to be another post about Q_FOREACH; this is a blog post about API deprecation in general. And, indeed: all of the above arguments apply to any API that is going through the deprecation process.

Any product needs to evolve if it wants to remain competitive. If the development bandwidth is finite, from time to time there is the need to drop some ballast. This does not necessarily mean dropping working functionality and leaving users in the cold. At least in Qt most of the time this actually means replacing working functionality with better working functionality.

This process has being going on in Qt since forever, but since Qt 5.0 we’ve started to formalize it in terms of documentation hints and macros in the source code. This was done with a precise purpose: we wanted Qt users to discover if they were using deprecated APIs, and if so, let them know what better alternatives were available.

And since the very release of Qt 5.0.0 we’ve officially deprecated hundreds of APIs: a quick grep in qtbase alone reveals over 230 hits (mostly functions, but also entire classes).

Here’s some good news: many developers are probably using deprecated APIs right now, and are not even noticing. Those APIs are working as expected, compile flawlessly, pass all the tests, and so on. Again, this has a reason: even though some API is deprecated, the Qt source compatibility promise holds. Our contract with our users is that we will keep all of our released APIs fully working for the entire Qt 5 major release, including the ones that have been deprecated.

Here’s some really bad news: many developers are probably using deprecated APIs right now, and are not even noticing! Apart from the possibility of not seeing those APIs any more in Qt 6, the real issue here is: developers are not using APIs that could make their code go faster, be more secure, or more flexible — that is, the APIs that are available right now to replace the deprecated ones.

There’s no excuse for deliberately maintaining a sub-standard codebase, so let’s get to work…

The deprecation macros

The big question is: how can Qt users figure out that they’re using deprecated APIs in the first place? Luckily for them, Qt has a solution. Every time an API gets deprecated, we tag it in the source code with a few macros. Let’s take a real-world example, from qtbase/src/corelib/tools/qalgorithms.h:

#if QT_DEPRECATED_SINCE(5, 2)
template <typename RandomAccessIterator>
QT_DEPRECATED_X("Use std::sort") inline void qSort(RandomAccessIterator start, RandomAccessIterator end) { ... }
#endif

There are two macros used here. The first one is QT_DEPRECATED_SINCE(major, minor), which conditionally expands to true or to false, depending on whether we want to enable or disable APIs deprecated up to (and including) Qt version major.minor. The parameters used in this example mean that the qSort function has been deprecated in Qt 5.2.

The second one is QT_DEPRECATED_X(text), which carries a text (there’s also a version without an argument, called QT_DEPRECATED). This macro conditionally marks the declaration as a deprecated, using a compiler-specific way; in standard C++14 this would correspond to the [[deprecated("text")]] attribute. The text argument represents a porting hint for the developer in case she gets a warning from the compiler; the warning would therefore suggest to use std::sort instead of qSort.

As you may’ve guessed, those conditionally make all the difference. Under which conditions do these macros trigger and let us know that we are using deprecated APIs? As we noted before, all of this machinery is actually disabled by default: user code compiles with no warnings even when using such APIs. The two macros work as follows:

QT_DEPRECATED_SINCE

QT_DEPRECATED_SINCE allows us to get compile-time errors if we use deprecated APIs.

QT_DEPRECATED_SINCE(major, minor) compares major, minor with the Qt version represented by the QT_DISABLE_DEPRECATED_BEFORE macro. This macro uses a version encoded as 0xMMmmpp (MM = major, mm = minor, pp = patch).

The actual comparison that happens is this:

// QT_VERSION_CHECK turns its arguments in the 0xMMmmpp form
#define QT_DEPRECATED_SINCE(major, minor) (QT_VERSION_CHECK(major, minor, 0) > QT_DISABLE_DEPRECATED_BEFORE)

If the comparison fails, the entire #if block guarded by a QT_DEPRECATED_SINCE gets discarded by the preprocessor. This means we will not get a declaration for a given name (like qSort, in our example), and therefore trying to use it in our code will trigger a compile error, just as wanted.

Unless we specify otherwise, QT_DISABLE_DEPRECATED_BEFORE is set automatically to 0x050000, i.e. Qt 5.0.0. We can easily raise the bar, for instance by adding this line into our .pro file:

# disable all the deprecated APIs in Qt <= 5.8 
DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x050800 

The reason why this deprecation functionality is versioned has to do with future-proofing. We cannot possibly foresee which APIs will get deprecated in Qt. (Actually, we can, because discussions happen in the open on the Development mailing list and on Qt’s code review system. But that’s another story.)

If we turn any usage of deprecated APIs into a hard error, we may run into problems if users of our software upgrade their Qt installation to a higher version than the one we used to develop it: our software may fail to compile on the higher version of Qt because it may use an API deprecated in that higher version but not in the one we used. And that just makes our users not happy.

Recommendation: set QT_DISABLE_DEPRECATED_BEFORE to the highest version of Qt that you developed and tested your software against.

Note that this comes with a cost: any usage of deprecated APIs will cause compile errors, which must therefore be fixed immediately. If we need the software to still compile while porting away from the deprecated API, keep reading…

QT_DEPRECATED_X

QT_DEPRECATED_X is a weaker form of QT_DEPRECATED_SINCE — it lets your code compile, but makes the compiler generate warnings if deprecated APIs are used. Again, this is disabled by default; in order to actually have the compiler emit warnings, this feature needs to be explicitly enabled by defining the QT_DEPRECATED_WARNINGS macro:

DEFINES += QT_DEPRECATED_WARNINGS # warn on usage of deprecated APIs

Recommendation: always have the QT_DEPRECATED_WARNINGS macro defined.

We can even combine the QT_DEPRECATED_X and the QT_DEPRECATED_SINCE macros, for maximum effect:

# warn on *any* usage of deprecated APIs, no matter in which Qt version they got marked as deprecated ...
DEFINES += QT_DEPRECATED_WARNINGS 

# ... and just fail to compile if APIs deprecated in Qt <= 5.6 are used
DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x050600 

That’s it!

Upstreaming this work

During QtCon 2016 we realized that many Qt users do not know about these macros and do not enable them. For this reason, apart from writing this blog post, I decided to invest a little time trying to make them more visible when using Qt tooling.

Since Creator 4.2 you will find these macros enabled by default when creating a new project (commit); the same will happen when using qmake -project in Qt 5.9 (commit).

Could porting away from deprecated APIs be fully automated?

That is a very hard question to answer. At KDAB we have lots of experience with Clang-based refactoring and porting tools, and we invest considerable time to tune them for both opensource projects (such as clazy) and customer-related work.

In general, we can expect some help coming from tooling, especially when the porting involves some minimal and straightforward refactoring. In other cases, things may not be so simple (cf. the comments in Marc’s blog post about Q_FOREACH), and tooling will help only in a percentage of cases.

Anyhow, stay tuned for more news around this!

Conclusions

Deprecating APIs is a natural thing in software development. As more brand new features get added to upcoming versions of Qt, some old feature may get marked as deprecated.

Luckily, we know that thanks to the Qt source compatibility promise our software will not break; and we can easily know which deprecated APIs we are using in our projects by enabling the relative warnings or errors.

The post Un-deprecate your Qt project appeared first on KDAB.

In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State.

Using these, I shall try to derive rules for C++ implementations of what are commonly called “value types”, focusing on the bare essentials, as I feel they have not been addressed in sufficient depth up to now: Special Member Functions.

Alex Stepanov and Paul McJones gave us a whole new way of looking at this, with a mathematical theory of types and algorithms quite unlike anything ever done before. Their achievement will forever change the way you look at computer programming, but eight years after its publication, the book still does not get the widespread adoption it deserves.

Setting The Stage

Special Member Functions, of course, are those member functions of a C++ object that the compiler can write for you: The default constructor, the copy and move constructors, the copy and move assignment operators and the destructor.

A Regular Type in EoP roughly corresponds to the EqualityComparable combined with the CopyConstructible C++ concept, see the book for more details.

A C++ Value Type is a type that is defined by its state, and its state alone (note that EoP has a very different definition of value type). Take an int as an example. Two int objects of value 5 will behave identical under all regular operations (simplified: all operations except for taking the object’s address). Two Shape objects, however, both having the same position, color, texture, … still may end up a square and a triangle when drawn on screen. A Shape object is defined by its behaviour as much as its state. We call such types polymorphic.

There are many shades of grey in between those two extremes; let’s leave it at that crude distinction. See Designing value classes for modern C++ – Marc Mutz @ Meeting C++ 2014 for a somewhat more thorough treatment.

In this article, we will look at two different classes, Rect and Pen, and try to write their Special Member Functions hopefully as Stepanov would have us do.

Rect and Pen

The first, Rect, is simple: it’s an integral-coordinate rectangle class that we will define completely inline in the header file. Pen, however, will be quite a bit different: It will use the Pimpl Idiom to firewall its internals from users. See Pimp My Pimpl and Pimp My Pimpl — Reloaded for more on the idiom.

class Rect {
    int x1, y1, x2, y2;
public:

};

class Pen {
    class Private; // defined out-of-line
    Private *d;
public:

};

The first task for today is to write the default constructor.

Default Construction

EoP has this to say about the default constructor:

[It] takes no arguments and leaves the object in a partially-formed state.

Ok, so what’s a “partially-formed state”? Here comes the good part:

An object is in a partially-formed state if it can be assigned-to or destroyed.

The authors go on to say that any other operation on partially-formed objects is undefined. In particular, such objects do not, in general, represent a valid value of the type.

The motivation for EoP to require default-construction in the first place is programmer convenience: T a = b; should be equivalent to T a; a = b;, and the user of the type should get to choose whether to write

T a;
if (cond)
   a = b;
else
   a = c;

or

T a = (cond) ? b : c;

Without default construction, if all the type’s author gave are user-defined constructors that establish a valid value, the programmer would have to use the ternary operator, whether or not that fits with line length limitations and personal preferences.

A default constructor for Rect

So, let’s try write something for Rect:

class Rect {
    int x1, y1, x2, y2;
public:
    Rect() = default;
};

What do you think? Would you have written the Rect default constructor this way?

I can tell you I wouldn’t have. Not until EoP opened my eyes. Remember that EoP only requires that the default constructor establish a partially-formed state, not a valid value. This should not surprise you. When in C++, do as the ints do:

int x;
Rect r;

In both cases, any use of the default-constructed object other than assignment or destruction is undefined, because the values of the objects are undefined (uninitialised).

If you feel uncomfortable with this implementation, you’re letting your inner Java programmer get the better of you. Don’t. This is C++. We embrace the undefined.

And, as Howard Hinnant writes in a reddit comment on this article, we give power to our users:

int x = {};  // x == 0
Rect r = {}; // r == {0, 0, 0, 0}

Next, let’s try Pen.

A default constructor for Pen

class Pen {
    class Private; // defined out-of-line
    Private *d;
public:
    Pen() : d(nullptr) {} // inline
    ~Pen() { delete d; }  // out-of-line
};

Should we have left Pen::d uninitialised, too?

No. Doing so would make destruction undefined.

Should we have newed a Pen::Private object into Pen::d in the default constructor?

That would be a no, too. We’re not required to establish a valid value in the default constructor, so in the spirit of “don’t pay for what you don’t use”, we only do the minimal work necessary to establish a partially-formed state.

To hammer this one home: Should an implementation of

Colour Pen::colour() const;

check for d == nullptr?

No the third. You can see at a glance in the source code whether an object is in a partially-formed state. There is no need for a runtime check, except for debugging purposes.

From the above, it follows that your default constructors should be noexcept. If your default constructors throw, they do too much. Of course, we’re still talking Value Types here, so let no man say that yours truly told you to make the default constructors of your RAII types noexcept.

Move-Construction And Move-Assignment

For Rect, moving and copying are the same thing, and the compiler is in the best position to implement them for you:

class Rect {
    int x1, y1, x2, y2;
public:
    Rect() = default;
    // compiler-generated copy/move special member functions are ok!
};

Once more, Pen is a bit more interesting:

class Pen {
    class Private; // defined out-of-line
    Private *d;
public:
    Pen() noexcept : d(nullptr) {} // inline
    Pen(Pen &&other) noexcept : d(other.d) { other.d = nullptr; } // inline
    ~Pen() { delete d; }  // out-of-line
};

We put moved-from Pen objects into the partially-formed state. In other words: moving from an object has the same effect as default-construction. Can it get any simpler?

We delegate move-assignment to the move constructor:

class Pen {
    class Private; // defined out-of-line
    Private *d;
public:
    Pen() noexcept : d(nullptr) {} // inline
    Pen(Pen &&other) noexcept : d(other.d) { other.d = nullptr; } // inline
    Pen &operator=(Pen &&other) noexcept                          // inline
      { Pen moved(std::move(other)); swap(moved): return *this; } 
    ~Pen() { delete d; }  // out-of-line

    void swap(Pen &other) noexcept
      { using std::swap; swap(d, other.d); }
};

Note how all special member functions except the destructor are inline so far, yet we didn’t break encapsulation of the Pen::Private class.

Controversy

Thanks in no small part to the ISO C++ standard, which describes moved-from objects (in [lib.types.movedfrom]) as follows:

Objects of types defined in the C++ standard library may be moved from. Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

the simple chain of reasoning described so far has less friends than you might think. And this is why I wrote this article.

You will probably meet a lot of resistance when trying to implement your default and move constructors this way. But think about it: What would a natural “default value” of your type be?

It’s easy to fall for the next-best choice: For int, surely the default-constructed value should be zero, and we just have to put up with this partially-formed, nay: uninitialised, values because C sucks.

I disagree. If you are using the int additively, then, yes, zero is a good default value. But if you work with multiplication, then one would be the better fit.

Bottomline: for the vast majority of types, there is no natural default. If there isn’t, then having to establish a randomly-chosen one on every default-construction operation is wasteful, so don’t do it.

Instead, have the default constructor establish only a partially-formed state, and provide literals (or named factory functions for something more complex) for the different “default” values:

class Rect {
    static constexpr Rect emptyRect = {};
};

class Pen {
    static Pen none();
    static Pen solidBlackCosmetic();
};

Embracing Partially-Formed Objects

Partially-Formed Objects are nothing magical. They offer a simple description of the behaviour of C++ built-in types with respect to default construction, and of pimpl’ed objects with respect to move semantics, if implemented in the natural way.

In both cases, partially-formed objects are easily spotted in source code with local static reasoning, so demands for anything more fancy than the bare minimum as the result of moving from an object or default-constructing one are violating the C++ principle of “don’t pay for what you don’t use”. As a corollary, keep your default constructors noexcept.

In a future instalment, we will look at a smart pointer that encodes these guidelines for use as a pimpl-pointer.

The post Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types appeared first on KDAB.

With the Qt 5.8 release, we have added QtNetworkAuth as a Technology Preview module. It is focused on helping developers with this auth******** madness. Currently, it supports OAuth1 and OAuth2. In the future, it will feature more authorization methods.

This post is a first glance of the OAuth2 support in Qt, it covers how to use Google to authorize an application. Your application will be able to show the typical log-in/authorize app screen, just like a web application (NOTE: A browser or a webview is needed):

.

The IETF defines OAuth 2.0 as:

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

OAuth authorization is also a requirement to use the Google APIs and access user information stored in Google Services like Gmail, Drive, Youtube, Maps, and others.

If you are interested in how to create an application using OAuth2, please continue reading.

Register your new project

Before start writing code, you need to register a new project in the service provider. This step is necessary because you have to request the client credentials to identify your application. The following steps are based on Google API Console but they are similar to other providers.

Creating new project

To start the project registration, access Google API Console, then, press “Create Project”.

A “New Project” dialog appears. Type the name of your project and click the “Create” button. Now you are ready to manage your new project.

Your application is registered, the dashboard is updated and you can set different options from this screen.

Creating the credentials

You have to get credentials to identify the application. Go to the “Credentials” section in the dashboard and press the “Create credentials” button. You need to choose which type of credentials you need. Choose “OAuth client ID”.

In the next screen, you can configure a “consent screen” with your Email address, product name, homepage, product logo, … Fill it with your data and press the “Save” button.

Go back to the previous “Create client ID” screen to choose the “Application type”. Different options are available here; you need to choose “Web application”. Give it a name.

Under “Restrictions” there is an important field: the “Authorized redirect URIs”.

If the user chooses to allow your application to manage his data. The application has to receive an “access token” to be used during authenticated calls. The “access token” can be received in several ways, but the most common way is to receive a call to your web server with the “access token”. In web applications, a server path to handle the notification is enough. A desktop application need to fake it using a local browser.

Add a URI accessible by your Internet browser including the port if you are using a different one than 80. When the application is running, a basic HTTP server will receive information from the browser.

Most of the times you need to use a URI like: “http://localhost:8080/cb”.

NOTE: The path “/cb” is mandatory in the current QOAuthHttpServerReplyHandler implementation.

NOTE: You can configure different URIs. In this example, a single URI is assumed.

End the process by pressing the “Create” button and you will see a new credential in the list of credentials with an “Edit”, “Delete” and “Download” buttons at the right. Click the download button and… Finally, you get a JSON file ready to parse!

In the screenshot above you can see some new URIs and the client_id and the client_secret. There is no need to use the JSON file, you can hardcode this information directly in your application.

Writing the Google API Wrapper code

I will omit the part of defining the class and show the relevant code.

In your code create a QOAuth2AuthorizationCodeFlow object:

auto google = new QOAuth2AuthorizationCodeFlow;

Configure the scope you need to access from the application. The scope is the desired permissions the application needs. It can be a single string or a list of strings separated by a character defined by the provider. (Google uses the space character as separator).

NOTE: The scopes are different depending on the provider. To get a list of scopes supported by Google APIs click here.

Let’s use the scope to access the user email:

google->setScope("email");

Connect the authorizeWithBrowser signal to the QDesktopServices::openUrl function to open an external browser to complete the authorization.

connect(google, &QOAuth2AuthorizationCodeFlow::authorizeWithBrowser,
    &QDesktopServices::openUrl);

Parse the downloaded JSON to get the settings and information needed. document is an object of type QJsonDocument with the file loaded.

const auto object = document.object();
const auto settingsObject = object["web"].toObject();
const QUrl authUri(settingsObject["auth_uri"].toString());
const auto clientId = settingsObject["client_id"].toString();
const QUrl tokenUri(settingsObject["token_uri"].toString());
const auto clientSecret(settingsObject["client_secret"].toString());
const auto redirectUris = settingsObject["redirect_uris"].toArray();
const QUrl redirectUri(redirectUris[0].toString()); // Get the first URI
const auto port = static_cast<quint16>(redirectUri.port()); // Get the port

After parsing the file configure the google object.

google->setAuthorizationUrl(authUri);
google->setClientIdentifier(clientId);
google->setAccessTokenUrl(tokenUri);
google->setClientIdentifierSharedKey(clientSecret);

Create and assign a QOAuthHttpServerReplyHandler as the reply handler of the QOAuth2AuthorizationCodeFlow object. A reply handler is an object that handles the answers from the server and gets the tokens as the result of the authorization process.

auto replyHandler = new QOAuthHttpServerReplyHandler(port, this);
google->setReplyHandler(replyHandler);

The grant function will start the authorization process.

google->grant();

If everything was OK, you should receive a QOAuth2AuthorizationCodeFlow::granted signal and start sending authorized requests.

You can try sending a request using https://www.googleapis.com/plus/v1/people/me

auto reply = google->get(QUrl("https://www.googleapis.com/plus/v1/people/me"));

It will give you a QNetworkReply and when QNetworkReply::finished is emited you will be able to read the data.

To be continued…

The post Connecting your Qt application with Google Services using OAuth 2.0 appeared first on Qt Blog.

While we’re still working on Vector, Text and Python Scripting, we’ve already decided: This year, we want to spend on stabilizing and polishing Krita!

Now, one of the important elements in making Krita stable is bug reports. And we’ve got a lot of those! But with some bug reports, we’re kind of stuck. We cannot figure out what type of hardware or drivers it is that is causing these bugs, so we’re asking for you help.

We’ve made a Krita user survey.

In it, we ask things like what type of hardware you have, and whether you have trouble with certain hardware. That way we can figure out which drivers and hardware are problematic and maybe get workarounds. There’s also some other questions, like what you make with Krita and how you get your Krita news.

Qt has provided support for state machine based development since introduction of Qt State Machine Framework in Qt 4.6. With the new functionality introduced in Qt 5.8 and Qt Creator 4.2 state machine based development is now easier than ever before.

Qt 5.8 introduces fully supported Qt SCXML module that makes it easy to integrate SCXML based state machines into Qt. Previously SCXML has been imported to Qt from external tools, which is still possible. Now Qt Creator 4.2 introduces a new experimental visual state chart editor that allows creation and modification of state charts directly with Qt Creator IDE. Together with the new editor and other improvements in Qt Creator, state machine based development can be done completely within Qt Creator.

Here is a short screen cast that shows these new features in action. For demonstration purposes, the simple state machine driven example application with Qt Quick user interface Traffic Light is being recreated from scratch.

Note that the the editor is still experimental with Qt Creator 4.2 and the plugin is not loaded by default. Turn it on in Help > About Plugins (Qt Creator > About Plugins on macOS) to try it.

The post Qt SCXML and State Chart Support in Qt Creator appeared first on Qt Blog.

Could you tell us something about yourself?

Good day. My name is Adam and I am a 26-year-old person who is trying to learn how to draw…

Do you paint professionally, as a hobby artist, or both?

Hobby

What genre(s) do you work in?

I try to draw everything, I don’t want to get stuck in drawing only one thing over and over again and leave behind everything else.

Whose work inspires you most — who are your role models as an artist?

People who inspired me when i was younger … much younger … were Satoshi Urushihara, Masamune Shirow and DragonBall artists.

How and when did you get to try digital painting for the first time?

My first adventure with digital painting was about 4-5 years ago, when I bought my first small Wacom Bamboo tablet that I am still using.

How did you find out about Krita?

A friend of mine mentioned it.

What was your first impression?

I uninstalled it and then came back after a while

What do you love about Krita?

Everything!

What do you think needs improvement in Krita? Is there anything that really annoys you?

Maybe make it less laggy, but that can be the fault of my laptop.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

The featured image. Not really my favourite, but I don’t have anything else worth showing!

What techniques and brushes did you use in it?

It was all random without any technique! I used Pencil 2B and pencil texture, nothing more or less.

Anything else you’d like to share?

Have a nice day everyone and let the Krita grow