Kubuntu 18.10 has been released, featuring the beautiful Plasma 5.13 desktop from KDE.

Codenamed “Cosmic Cuttlefish”, Kubuntu 18.10 continues our proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 4.18-based kernel, Qt 5.11, KDE Frameworks 5.50, Plasma 5.13.5 and KDE Applications 18.04.3

Kubuntu has seen some exciting improvements, with newer versions of Qt, updates to major packages like Krita, Kdeconnect, Kstars, Peruse, Latte-dock, Firefox and LibreOffice, and stability improvements to KDE Plasma. In addition, Snap integration in Plasma Discover software center is now enabled by default, while Flatpak integration is also available to add on the settings page.

For a list of other application updates, upgrading notes and known bugs be sure to read our release notes:

https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseNotes/Kubuntu

Download 18.10 or read about how to upgrade from 18.04.

Additionally, users who wish to test the latest Plasma 5.14.1 and Frameworks 5.51, which came too late in our release cycle to make it into 18.10 as default, can install these via our backports PPA. This represents only the 1st initial bugfix release of Plasma 5.14, with 4 more to be released in the coming months, so early adopters should be aware that there may more bugs to be found (and reported).

In the last episode of this series we discussed QAbstractItemModel::checkIndex().

QAbstractItemModel::checkIndex() is a function added in Qt 5.11 that allows developers of model classes to perform some validity checks on the QModelIndex objects passed to the model; specifically, on the indices passed to the APIs that model classes need to implement (rowCount(), columnCount(), data, setData(), etc.).

These validity checks can be very useful when developing (and debugging) the model itself, or when using a complicated stack of models and proxy models.

However, by its nature, checkIndex() will check just the one index passed to it. It is unable to perform consistency checks on the model “as a whole”. For instance, for a given index, a model’s reimplementation of hasChildren() must be consistent with the values returned by rowCount() and columnCount().

Enter QAbstractItemModelTester

QAbstractItemModelTester is a new class in Qt 5.11 which helps to test item models. It complements checkIndex() by checking the consistency of the entire model from the point of view of a user of the model (like a view).

(Technically speaking, it’s not really new: Qt has had a private class called ModelTest amongst its own autotests for years; ModelTest‘s usecase is the same as QAbstractItemModelTester. For Qt 5.11 I’ve took ModelTest, cleaned it up, renamed it to QAbstractItemModelTester and added it as public API in the QtTest module.)

QAbstractItemModelTester is simple and immediate to use: just create an instance, and pass to its constructor the model that needs to be tested, like this:

QAbstractItemModelTester *tester = new QAbstractItemModelTester(modelToTest);
// keep the tester object around; it will run a series of tests on modelToTest

QAbstractItemModelTester will then automatically perform a series of non-destructive checks on the model. These checks are aimed at verifying the model’s overall consistency; they will verify that the (many) function of the QAbstractItemModel API are always coherent, and will not confuse anyone using the model (like a view, or a proxy model).

Furthermore, QAbstractItemModelTester will also listen to the signals emitted by the model to test; an emission triggers further validation checks, for instance emitting that a row has been added to the model will make tester verify that the row count has been increased by exactly 1.

Example

As an example, let’s consider this very simple model class (a list model of strings):

class StringListModel : public QAbstractListModel {
    Q_OBJECT
public:
    using QAbstractListModel::QAbstractListModel;

    int rowCount(const QModelIndex &parent) const override {
        Q_ASSERT(checkIndex(parent));
        if (parent.isValid())
            return 0;
        return m_strings.size();
    }

    QVariant data(const QModelIndex &index, int role) const override {
        Q_ASSERT(checkIndex(index, QAbstractItemModel::CheckIndexOption::IndexIsValid));
        if (role != Qt::DisplayRole)
            return {};
        return m_strings[index.row()];
    }

    // appends the string at the end of the model
    void appendString(const QString &string) {
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size() + 1);
        m_strings.append(string);
        endInsertRows();
    }

private:
    QStringList m_strings;
};

The implementation of the model is straightforward: since it’s a list model, only rowCount() and data() need to be implemented. Our model also has a third function (appendString()) that allows the application code to insert a new string into the model, specifically, at the very end.

Let’s focus on this very last function. When inserting new rows into a model, we are supposed to notify the views about the change. QAbstractItemModel’s documentation tells us to use a “transactional” approach: we need to call beginInsertRows() before inserting, perform the insertion, then call endInsertRows().

The parameters to beginInsertRows() describe how many new rows are being inserted, and at which position (the documentation discusses all the details); in our case, we are adding exactly one row at the very end of the model, so we pass m_strings.size() as the position at which the new row will appear.

The third parameter is however wrong: it’s basically stating that we are going to add two rows at the end of the model, while we’re actually adding only one. If we read the documentation carefully, we notice that the parameter shall indicate the index of the last row being added; since we’re adding only one, the index of the last row being added is the same as the first row being added. In order words: the second and third parameter of beginInsertRows() should be identical, like this:

        // correct call: adds 1 row, at position m_strings.size()
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size());

These sort of mistakes (in the end, an off-by-one error) can cause lots of troubles: for instance, persistent model indexes start pointing to the wrong data, proxy models get corrupted, and so on.

If we use our model into a QAbstractItemModelTester, we get a notification that there is something wrong going on. For instance, given this setup:

    auto model = new StringListModel;
    auto tester = new QAbstractItemModelTester(model, 
                          QAbstractItemModelTester::FailureReportingMode::Warning);

Sometime later, when appendString() is called, QAbstractItemModelTester will detect the mismatch between the rows we are promising we are adding to the model, and the ones we are actually adding to the model. Since the tester object is set to Warning mode it will print a warning on the console, like this:

FAIL! Compared values are not the same:
   Actual (model->rowCount(parent)) 1
   Expected (c.oldSize + (end - start + 1)) 2
   (qabstractitemmodeltester.cpp:669)

We can then use ordinary debugging tools (e.g. a debugger with a breakpoint) to debug what condition caused this warning. We will then notice that the call stack leading to the warning starts in our appendString() function, so we need to double check it and figure out what’s going on in there.

Lastly, note the calls to checkIndex() in the model’s functions that implement the QAbstractListModel API (by overriding rowCount() and data()). QAbstractItemModelTester and checkIndex are meant to complement each other, as the former tests the entire model, while the latter is used to validate the model indexes passed to the various functions.

Reporting failures

In case some of the checks fail, QAbstractItemModelTester has three different ways of reporting the failure to the developer, selectable via an argument to the constructor:

• By default, QAbstractItemModelTester uses the QtTest failure report mode: failures are reported through the QtTest’s logging mechanisms. This report mode is suitable if we are using QAbstractItemModelTester in a test driven by the QtTest framework, for instance when building unit tests for our model class; a problem in our model will result in the current test function being marked as failing.
• QAbstractItemModelTester is also usable outside unit tests driven by QtTest. By specifying the Warning failure mode, QAbstractItemModelTester will print a warning statement in the qt.modeltest logging category.
• Finally, the Fatal failure mode causes the application to crash immediately. In this mode, if a check fails, QAbstractItemModelTester is going to call qFatal() passing a string with a textual description of the error.

No matter which failure mode is set, QAbstractItemModelTester will print debug information about our model in the aforementioned qt.modeltest logging category, showing what kind of changes were detected by the tester class and what sorts of checks are being run. Sometimes this can be useful in order to track down bugs.

Note that this debug output needs to be explicitly enabled by the developer, for instance by setting the QT_LOGGING_RULES environment variable to contain the string qt.modeltest.debug=true. (For more information on Qt’s logging categories, see here).

Remarks

It is important to note that QAbstractItemModelTester will never perform destructive tests on a model (set new data, insert/remove rows and columns, and so on). This allows developers to safely use the tester in all conditions, including having it enabled in a full build of the application. This way models can be tested in real-world conditions, using actual data, as well as in long-running scenarios (which maybe are required to trigger some bug).

On the other hand, in order to thoroughly test a custom model, we may need to write checks for destructive changes. Since only the developer knows the exact behaviour of a model that undergoes a modification, the developer is supposed to write dedicated unit tests, thus complementing the tests done by QAbstractItemModelTester.

Finally: as I wrote in the last blog post, I believe that the model/view APIs in Qt have a narrow contract: one should never attempt to pass invalid data to a model (e.g. a model index out of range). QAbstractItemModelTester honours this, and will never attempt any illegal operation on a model. If for some reason you need to give your model a wide contract and want to test that contract, further tests (outside QAbstractItemModelTester) are needed.

That’s it for now for now, but stay tuned for more contributions to Qt!

The post New in Qt 5.11: improvements to the model/view APIs (part 2) appeared first on KDAB.

Upgrades to 18.04 are working well but maintaining twice as many builds as normal is taking its toll on our time and team of guinea pig packagers. Neon on 16.04 (xenial) base will reach End of Life on Monday.  Please update to 18.04 base to continue receiving updates.

Sebastian Labi ha sido invitado para presentar Krita en el Laboratorio de herramientas de software libre de la Universidad de La Plata. Hablará sobre ilustración digital y usará Krita para dar una demostración de cómo usar Krita para el campo de la Ilustración Digital.

El SLAD- FBA (Software libre para Arte y diseño) es una nueva unidad de de investigación y formación en la Facultad de Bellas Artes que promueve el conocimiento y uso del software libre en la capacitación académica de la Universidad de La Plata.

El evento tendrá lugar el Miércoles 31 de Octubre a las 14:00.

Sebastian Labi has been invited to present Krita in the laboratory of Free Software tools of the Unversity of La Plata.  He will talk about digital illustration and using Krita, as well as giving a hands-on demonstration of Krita. SLAD – FBA | Free Software for Art and Design is a new unit of research and training at the Faculty of Fine Arts which promotes knowledge and use of Free Software in the academic training of the University of La Plata.

SLAD is a new research and teaching group in the Faculty of Fine Art in La Plata University which wants to promote systemtatic and sustained knowledge on how Art and Open Source interacts in an academic setting.

The meeting will be on Wednesday October 31st at 14:00.

We’re glad to announce that we received donation of 100,000 USD, which is part of 300,000 USD offered to our KDE organization. Quite appropriate for a birthday present, as the KDE project just turned 22 this last weekend! It’s true recognition for KDE as one of the world’s largest open source project.

More information: KDE e.V. receives a sizeable donation from Handshake Foundation.

Could you tell us something about yourself?

Hi, my name is Sira Argia. I am a digital artist who uses FLOSS (Free/Libre Open Source Software) for work. I come from Indonesia, Sanggau Regency, West Kalimantan.

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

I don’t think that I am professional in my digital painting work because there’s so much things I need to learn before I achieve something that can be called “professional”. At the beginning, it’s just a hobby. I remember my first painting artwork was very bad, haha. But now I think my artworks are far better than the first. I believe in “practice makes perferct”.

What genre(s) do you work in?

I call it “semi realistic” art style. I usually use anime/manga or Disney style for the character’s face look-alike and use realistic shading a little bit.

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

David Revoy and Sara Tepes. They inspire and help me a lot with their tutorials.

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

I started in 2014-2015. I used the traditional method (with pencil and paper) and traced it with Inkscape.

Then 2016. That’s the first time I tried digital painting because I just bought my first graphic tablet that time.

What makes you choose digital over traditional painting?

I am not in the position that I have to choose between digital or traditional painting, because if there’s a teacher, I really need to learn all of them. The reasons why I am doing digital painting at this moment is that iI can find tutorials everywhere on the internet and it’s easy to practice because I have the monitor and the digital pen for digital painting. Besides, I am working as a freelance artist and every client asks for digital raw files.

How did you find out about Krita?

2014 is the year that I first started to try Linux on my laptop, and then I knew that Windows programs don’t run perfectly on Linux even using “wine”. My curiosity about Linux and the alternative programs led me to Krita. The more time I spent with Linux, the more I fell in love with it. And finally I thought that “I’ll choose Linux as a single OS on my laptop and Krita as a digital painting program for work someday after I get my first graphic tablet.”

What was your first impression?

The first Krita that I tried is version 2.9. I followed David Revoy’s blog and youtube channel to learn his tutorials about Krita. I thought at the time that Krita was very laggy for bigger canvas sizes. But I still used it as my favorite digital painting program because I thought that Krita was a powerful program.

What do you love about Krita?

Powerful and Free Open Source Software.

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

I hope Krita will not use so much processor and ram in the future, it always gets to force close when I use many layers in a bigger canvas.

What sets Krita apart from the other tools that you use?

I’ve never used other painting programs for a long time except Krita. So I don’t know, Krita has unique features. For example, other programs have something called called “clipping layer” but Krita called it “inherit alpha”.

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

Here’s my character who is called Seira. Still my favourite because this is the first time I didn’t pick any palette colors from the internet and I
started to understand about “source light” in the digital painting.

What techniques and brushes did you use in it?

a. Sketch

I usually begin from the stickman. I thought about pose and the composition at this point. Then I start to draw the naked body from the stickman. That’s the part where I have to draw the anatomy clearly. After that, I start to draw the costume of the character. I am not really good at line art, so I let it become a sketch because for me, it’s just a guide to the next step.

b. Coloring

This is a very important part for me because I need to be clear with the shading, texture of the material, value, etc. For the brushes, the Deevad bundle and the Krita default brush bundle are more than enough.

Where can people see more of your work?

www.aflasio.com

Anything else you’d like to share?

I just want to give a message to the people who see this. “It’s better to use FLOSS (Free/Libre Open Source Software) like Krita for example, than use proprietary software (even worse if you use the cracked software). It’s bad. Really…”

Yesterday was the last day of the developers sprint^Wmarathon, and the last day of the fundraiser. We’re all good and knackered here, but the fundraiser ended at a very respectable 26,426 euros! That’s really awesome, thanks everybody!

We’ve already updated the about box for Krita 4.2 with the names or nicknames of everyone who wanted to be mentioned, and here is the final vote tally:

Now we’re going to take a short break, and then it’s rollup our sleeves and get to work!

We fully intended to make a post every day to keep everyone posted on what’s happening here in sunny Deventer, the Netherlands.

And that failed because we were just too busy! I’m triaging bugs even as I’m working on this post, too! We are on track to have fixed about a hundred bugs during this sprint. On the other hand, the act of fixing bugs seems to invite people to test, and then to report bugs, so in the past ten days, there were fifty new reports. That all makes for a very hectic sprint indeed!

All through the week, we all touched many different parts of Krita, sharing knowledge and making everyone of us more all-round when it comes to Krita’s codebase. Remember, people have been working on this code since 1999. Nobody back then expected we’d have millions of users one day!

At the Krita headquarters, one usually cooks for two or three, cooking for eight was a bit of a challenge, but cook we did, for Wolthera, Irina, Boudewijn, Dmitry, Ivan, Jouni, Emmet and Eoin. Let’s go through the days, menu and bugs!

Saturday: Minestrone

On Saturday, we merged Michael Zhou’s Summer of Code work on improving the palette docker and making it possible to save palettes in your .kra project file. Of course, that meant that all through the week we had to fix issues here and there caused by this merge, but that was to be expected. All through the week, using the nightly builds must have been a roller-coaster experience for our testers!

And we got a lot more done, too: Jouni was demonstrating his clone frames and frames cycle feature, Eoin added a global kinetic scrolling feature, where you can pan pretty much every list with the middle-mouse button. That makes Krita much nicer to use on touchscreens.

Sunday: Pasta with tomato sauce

On Sunday, we really got into our stride. Wolthera updated the user manual with all the new features — if you haven’t checked out the manual, do so, we’re quite proud of it! Emmet fixed the color picker tool, which had a bit of trouble showing the correct value for the alpha channel. There were smaller and larger bug fixes, but a very nice new feature was added as well: new contributor Reptorian, after coding a bunch of new blending modes, put his teeth into a larger feature: a symmetric difference mode for the selection tools.

This is not the first time that someone with little or no background in C++ does really useful work for Krita. In fact, it happens all the time, and for this we worked together with Alberto Flores who was working on his very first patch. And he did make it!

Monday: Moussaka

On Monday, we fixed a nasty little bug where the order in which you select layers in the layerbox would influence the order in which layers would be merged. There were fixes to the animation timeline.

The big feature of Monday was making it possible to import SVG files as a vector layer. Originally, and silly enough, an SVG file would be imported as a raster layer when using the layer/import image as layer function.

Dmitry started working on making Krita’s canvas support display scaling properly.: this work would go on all through the week.

Jouni started working on fixing the sound stuttering when playing an animation. That patch is ready to land, and when we released on Thursday, it turns out that this was the thing we got most questions about.

And we fixed bugs…

Tuesday: Honey-braised pork, sesame beans and cabbage in oyster sauce

On Tuesday we did a bunch of bug triaging and assigned bugs to the people present. Then there were crash fixes, python fixes, ui polish… And we also looked into what would be needed to support HDR monitors, but that’s going to be a long slog!

Wednesday: Stuffed bellpeppers

On Wednesday, Dmitry refined the way users can modify and work with selections: now one should hover over the selection border to start moving a selection. And a lot of bugs and crashes were fixed all long day long, but we also started preparing for the release itself, by backporting all the fixes to the 4.1 branch.

Thursday: Dining out at Da Mario, and a release

This was the day we had to redo the release three times! But we did release in the end, with almost fifty bugs fixed.

But there was also fixing being done!

Eoin fixed a bug in the animation curve editor, fixed bugs in the bristle and smudge brushes. Wolthera fixed a regression in the color selector. Turns out that if you replace a division by two with a multiplication by 0.5, you shouldn’t keep dividing it…

Dmitry also pushed the final set of fixes for using display scaling correctly in Krita. That’s another very, very long standing bug finally fixed!

And it’s not just people at the sprint who are busy! Mehmet Salih Çalışkan submitted two patches, one for the text tool, one for the brush editor, and today his patches were pushed. Anna Medonosva was fixing issues with the artistic color selector.

In the afternoon, we went out for a walk and met the Deventer sheep herd, as well as the shepherd.

That evening, none of us cooked, we went out to Da Mario instead to have dinner together with one of the more local supporters of Krita.

Friday: Ajam pedis and sambal goreng beans

Emmett fixed a really hard bug where sometimes when smudging black gets mixed into the color. We’re pretty sure there are more bugs like this in the database, but we’d need some testing done to see which bugs those are. It’s one thing that makes the bugs database such a mess: we have lots of duplicates, but often the fact that they’re duplicates isn’t apparent at all.

Jouni fixed issues with the G’Mic integration, Boudewijn looked into the problem with saving a group layer with a transparency mask to OpenRaster: that needs updating the OpenRaster standard though. But he didn’t waste the entire day, he also fixed loading line end markers for vector lines on Windows and macOS. Ivan fixed macOS-specific issues in the animation timeline.

Later in the afternoon we discussed options to reduce the mess in bugzilla a bit by using a helpdesk system and/or an a question/answer type site. Bugzilla really should only contain bugs, not user support type questions!

Saturday: Runner beans and meatballs with mint sauce

Saturday was our day off. All work and no play and all that sort of thing. We visited a nearby town, called Zwolle. It’s a pretty place, a little larger than Deventer, and it has kept one of its town gates, the Sassenpoort. Previously used as the town’s archive, it’s now and then open to the public, and well worth a visit. Zwolle has been barbaric enough to close its local history museum because it wasn’t turning a profit, but there’s still the Fundatie, a modern art museum, which was showing a smallish exhibition of works by sculptors Giacometti and Chadwick.

And in the evening we went back to hacking. Jouni is this close to fixing audio playback for animations: in fact, it’s ready to be merged!

Sunday: Black pudding with beetroot and stewed pears

And today, while Jouni has already gone back to Finland, we’re back at fixing bugs! But this was one loooong sprint, more of a marathon, and we’re getting a bit frazzled now. Still, there are more bugs to be fixed!

The End

Tomorrow, our marathon coders will wend their way homewards. The fundraiser will end, at the very great amount of 25,000 euros (it’s actually more, because people have also been donating directly through Krita’s bank account, and the website doesn’t count that.). And we will be fixing bugs, and work on achieving that polish and stability that makes all the difference!

The Ubuntu release team have announced a 1st test ISO RC build for all 18.10 flavours.

Please help us test these and subsequent RC builds, so that we can have an amazing and well tested release in the coming week.

As noted below, the initial builds will NOT be the final ones.

Over the next few hours, builds will start popping on the Cosmic Final
milestone page[1] on the ISO tracker.  These builds are not final.
We're still waiting on a few more fixes, a few things to migrate, etc.
I've intentionally not updated base-files or the ISO labels to reflect
the release status (so please don't file bugs about those).

What there are, however, are "close enough" for people to be testing in
anger, filing bugs, fixing bugs, iterating image builds, and testing
all over again.  So, please, don't wait until Wednesday night to test,
testing just before release is TOO LATE to get anything fixed.  Get out
there, grab your favourite ISO, beat it up, report bugs, escalate bugs,
get things fixed, respin (if you're a flavour lead with access), and
test, test... And test.  Did I mention testing?  Please[2] test.

Thanks,

... Adam

[1] http://iso.qa.ubuntu.com/qatracker/milestones/397/builds
[2] Please.

Downloads for RC builds can be found by following the link after clicking through to ‘Cosmic Final’ on the Ubuntu ISO tracker. Please report test case results if you have a Ubuntu SSO account (or are prepared to make one). Feedback can also be given via our normal email lists, IRC, forums etc.

Upgrade testing from 18.04 in installed systems (VM or otherwise) is also a very useful way to help prepare for the new release. Instructions for upgrade can be found on the Ubuntu help wiki.

Ubuntu ISO tracker: http://iso.qa.ubuntu.com/qatracker/
Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
Kubuntu 18.10 Upgrade instructions: https://help.ubuntu.com/community/CosmicUpgrades/Kubuntu

Coming hot on the heels of Krita 4.1.3, which had an unfortunate accident to the TIFF plugin, we’re releasing Krita 4.1.5 today! There’s a lot more than just that fix, though, since we’re currently celebrating the last week of the Krita Fundraiser by having a very productive development sprint in Deventer, the Netherlands.

There are some nice highlights as well, like much improved support for scaling on hi-dpi or retina screens. But here’s a full list of more than fifty fixes:

• Associate Krita with .ico files
• Auto-update the device pixel ration when changing screens
• Disable autoscrolling for the pan tool
• Disable drag & drop in the recent documents list BUG:399397
• Disable zoom-in/out actions when editing text in rich-text mode BUG:399157
• Do not add template files to recent documents list BUG:398877
• Do not allow creating masks on locked layers. BUG:399145
• Do not close the settings dialog when pressing enter while searching for a shortcut BUG:399116
• Fill polyline shapes if some fill style was selected BUG:399135
• Fix Tangent Normal paintop to work with 16 and 32 bit floating point images BUG:398826
• Fix a blending issue with the color picker when picking a color for the first time BUG:394399
• Fix a problem with namespaces when loading SVG
• Fix an assert when right-clicking the animation timeline BUG:399435
• Fix autohiding the color selector popup
• Fix canvas scaling in hidpi mode BUG:360541
• Fix deleting canvas input settings shortcuts BUG:385662
• Fix loading multiline text with extra mark-up BUG:399227
• Fix loading of special unicode whitespace characters BUG:392710
• Fix loading the alpha channel from Photoshop TIFF files BUG:376950
• Fix missing shortcut from Fill Tool tooltip. BUG:399111
• Fix projection update after undoing create layer BUG:399575
• Fix saving layer lock, alpha lock and alpha inheritance. BUG:399513
• Fix saving the location of audio source files in .kra files
• Fix selections and transform tool overlay when Mirror Axis is active BUG:395222
• Fix setting active session after creating a new one
• Fix showing the color selector popup in hover mode
• Fix the ctrl-w close window shortcut on Windows BUG:399339
• Fix the overview docker BUG:396922, BUG:384033
• Fix the shift-I color selector shortcut
• Fix unsuccessful restoring of a session blocking Krita from closing BUG:399203
• Import SVG files as vector layers instead of pixel layers BUG:399166
• Improve spacing between canvas input setting categories
• Make Krita merge layers correctly if the order of selecting layers is not top-down. BUG:399146
• Make it possible to select the SVG text tool text has been moved inside an hidden group and then made visible again BUG:395412
• Make the color picker pick the alpha channel value correctly. BUG:399169
• Prevent opening filter dialogs on non-editable layers. BUG:398915
• Reset the brush preset selection docker on creating a new document BUG:399340
• Support fractional display scaling factors
• Update color history after fill BUG:379199

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

• 64 bits Windows: krita-x64-4.1.5-setup.exe
• Portable 64 bits Windows: krita-x64-4.1.5.zip
• Debug symbols. (Unpack in the Krita installation folder)

• 32 bits Windows: krita-x86-4.1.5-setup.exe
• Portable 32 bits Windows: krita-x86-4.1.5.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

• 64 bits Linux: krita-4.1.5-x86_64.appimage
• 64 bits Linux G’Mic-Qt plugin appimage.

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 4.1.5 on Ubuntu and derivatives. We are working on an updated snap.

OSX

• OSX disk image: krita-4.1.5.1.dmg

Note: the touch docker, gmic-qt and python plugins are not available on OSX.

Source code

• Source code: krita-4.1.5.tar.gz

md5sum

For all downloads:

• md5sum.txt

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

Clazy 1.4 has been released and brings 10 new checks.

Clazy is a clang compiler plugin which emits warnings related to Qt best practices. We’ll be showing Clazy at Qt World Summit in Boston, Oct 29-30, where we are a main Sponsor.

You can read more about it in our previous blog posts:

• How to use static analysis to improve performance
• Uncovering 32 Qt Best Practices
• Nailing 13 signal and slot mistakes with clazy 1.3

Today I’ll go through all 10 new warnings, one by one. For other changes, check the complete 1.4 Changelog. So let’s start. I’ve ordered them according to my personal preference, starting with the ones that have helped me uncover the most bugs and finishing with some exotic ones which you’ll rarely need.

1. skipped-base-method

Warns when calling a method from the grand-base class instead of the direct base class one.

Example:

class MyFrame : public QFrame
{
    Q_OBJECT
public:
    bool event(QEvent *ev) override
    {
        (...)
        // warning: Maybe you meant to call QFrame::event() instead [-Wclazy-skipped-base-method]
        return QWidget::event(ev); 
    }
};

The motivation came after hitting bugs when overriding QObject::event() and QObject::eventFilter(). I would suggest always using this check and annotating your legit cases with // clazy:exclude=skipped-base-method, to make your intention clear. The same way you would comment your fallthroughs in switch statements.

This check might get removed in the future, as in the end it’s not specific to Qt and clang-tidy recently got a similar feature.

2. wrong-qevent-cast

Warns when a QEvent is cast to the wrong derived class via static_cast.

Example:

switch (ev->type()) {
    case QEvent::MouseMove:
        auto e = static_cast<QKeyEvent*>(ev);
}

Only casts inside switch statements are verified.

3. qhash-with-char-pointer-key

Finds cases of QHash<const char *, T>. It’s error-prone as the key is just compared by the address of the string literal, and not the value itself.

This check is disabled by default as there are valid use cases. But again, I would suggest always using it and adding a // clazy:exclude= comment.

4. fully-qualified-moc-types

Warns when a signal, slot or invokable declaration is not using fully-qualified type names, which will break old-style connects and interaction with QML.

Also warns if a Q_PROPERTY of type gadget is not fully-qualified (Enums and QObjects in Q_PROPERTY don’t need to be fully qualified).

Example:

namespace MyNameSpace {

    struct MyType { (...) };

    class MyObject : public QObject
    {
        Q_OBJECT
        Q_PROPERTY(MyGadget myprop READ myprop); // Wrong, needs namespace
    Q_SIGNALS:
        void mySignal(MyType); // Wrong
        void mySignal(MyNameSpace::MyType); // OK
    };
}

Beware that fixing these type names might break user code if they are connecting to them via old-style connects, since the users might have worked around your bug and not included the namespace in their connect statement.

5. connect-by-name

Warns when auto-connection slots are used. They’re also known as “connect by name“, an old and unpopular feature which isn’t recommended. Consult the official documentation for more information.

These types of connections are very brittle, as a simple object rename would break your code. In Qt 5 the pointer-to-member-function connect syntax is recommended as it catches errors at compile time.

6. empty-qstringliteral

Suggests to use an empty QString instead of an empty QStringLiteral. The later causes unneeded code bloat.

You should use QString() instead of QStringLiteral() and QString("") instead of QStringLiteral("").

7. qt-keywords (with fixit)

Warns when using Qt keywords such as emit, slots, signals or foreach.

This check is disabled by default. Using the above Qt keywords is fine unless you’re using 3rdparty headers that also define them, in which case you’ll want to use Q_EMIT, Q_SLOTS, Q_SIGNALS or Q_FOREACH instead.

This check is mainly useful due to its fixit to automatically convert the keywords to their Q_ variants. Once you’ve converted all usages, then simply enforce them via CONFIG += no_keywords (qmake) or ADD_DEFINITIONS(-DQT_NO_KEYWORDS) (CMake).

8. raw-environment-function

Warns when putenv() or qputenv() are being used and suggests the Qt thread-safe equivalents instead. This check is disabled by default and should be enabled manually if thread-safety is important for you.

9. qstring-varargs

This implements the equivalent of -Wnon-pod-varargs but only for QString.

This check is only useful in cases where you don’t want to enable -Wnon-pod-varargs. For example on projects with thousands of benign warnings (like with MFC’s CString), where you might only want to fix the QString cases.

10. static-pmf

Warns when storing a pointer to a QObject member function and passing it to a connect statement. Passing such variable to a connect() is known to fail at runtime when using MingW.

You can check if you’re affected by this problem with the following snippet:

static auto pmf = &QObject::destroyed;
if (pmf == &QObject::destroyed) // Should be false for MingW

Conclusion and thoughts for version 1.5

Clazy has matured and it’s getting increasingly difficult to come up with new ideas for checks. For version 1.5 I won’t be focusing in writing new warnings, but instead figuring out how to organize the existing ones.

This project has come a long way, there’s now 77 checks and I feel the current classification by false-positive probability (levels 0, 1, 2, 3) is not scaling anymore. I will try to organize them by categories (bug, performance, readability, containers, etc), which would be orthogonal to levels and hopefully also answer the following questions:

• What’s the absolute sub-set of checks that every project should use ?
• Which ones should abort the build if triggered (-Werror style) ?
• How to make clazy useful in CI without getting in the way with annoying false-positives ?
• How to let the user configure all this in an easy way ?

But of course, if you know of any interesting check that wouldn’t cost me many days of work please file a suggestion or catch me at #kde-clazy (freenode) and it might make it to the next release.

The post Clazy 1.4 released appeared first on KDAB.

We are happy to announce the release of Qt Creator 4.8 Beta!

Generic Programming Language Support

In Qt Creator 4.8 we’ll introduce experimental support for the language server protocol. For many programming languages there is a “language server” available, which provides IDEs with a whole lot of information about the code, as long as they support communicating via the protocol.

This means that by providing a client for the language server protocol, Qt Creator gets (some) support for many programming languages “for free”. Currently Qt Creator supports code completion, highlighting of the symbol under cursor, and jumping to the symbol definition, as well as integrates diagnostics from the language server. Highlighting and indentation are still provided by our generic highlighter, since they are not provided via the language server protocol.

To use a language server, you first need to enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS). Then add the server in Tools > Options > Language Client, choosing a MIME type (glob patterns are in the works), server executable and any required command line arguments. The server is automatically started – just open a file of the corresponding type and start hacking :).

Note that the client is mostly tested with Python. There will most probably be one or the other issue when you try your most favorite language. Also, we currently do not support language servers that require special handling. If you find issues, we are happy to receive bug reports, preferably including Qt Creator console output with the environment variable  QT_LOGGING_RULES=qtc.languageclient.*=true set.

C++ Support

On the C++ side we added some experimental features.

Compilation Database Projects

Open a compilation database as a project purely for editing and navigating code. A compilation database is basically a list of files and the compiler flags that are used to compile them. Some build systems and tools are able to generate such databases for use in other tools. In Qt Creator it feeds the code model with the necessary information for correctly parsing the code. Enable the plugin CompilationDatabaseProjectManager to try it.

Clang Format Based Indentation

Does auto-indentation via LibFormat which is the backend used by Clang Format. Enable the plugin ClangFormat to try it.

Cppcheck Diagnostics

Integrates diagnostics generated by the tool Cppcheck into the editor. Enable the plugin Cppcheck to try it.

Aside from many other fixes, the Clang code model can now jump to the symbol represented by the auto keyword. It also allows generation of a compilation database from the information that the code model has via Build > Generate Compilation Database.

Debugging

We added support for simultaneously running debuggers on one or more executables. When multiple debuggers are currently running, you can switch between the instances with a new drop-down menu in the debugger tool bar in Debug mode.

There have been many more improvements and fixes in Qt Creator 4.8, which you can read about in more detail in our change log.

Get Qt Creator 4.8 Beta

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8 Beta is also available under Preview > Qt Creator 4.8.0-beta1 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.8 Beta released appeared first on Qt Blog.

At least from the perspective of rendering, text is often the most complex part of a traditional two-dimensional user interface. In such an interface, the two main components are rectangular images and text. The rectangular images are often quite static, and can be represented by two triangles and four indexes into a texture atlas that is uploaded to graphics memory once and then retained. This is something that has low complexity and which the graphics hardware has been optimized to handle quickly.

Text starts as a series of indexes into an international database of writing systems (Unicode). It is then, based on some selection algorithm, combined with one or more fonts, which is in principle a collection of shapes and some lookup tables and executable programs that convert said indexes into shapes and relative positions. These shapes, basically filled paths made out of bezier curves, then have to be rasterized at a specified size, and this can range from simple and neat outlines to complex ones with lots of detail. (By rasterization, I mean finding out how much of each target pixel, or subpixel in some cases, is covered by the shape.)

Objectively the most beautiful character in the Latin alphabet. Here represented by a rasterized image of three channels, respectively giving the coverage of the red, green and blue target subpixels. Scaled by 400% to make the pixels visible.

All combined, it is a heavy process. But luckily, instead of redoing every step for every string, we can often cache intermediate results and reuse them later.

For instance, it is possible to rasterize the glyphs the first time they are used, keep this in memory, and then at each subsequent use, render these glyphs the same way images are rendered as described above: By putting the rasterized glyphs in a texture atlas and representing the glyphs by two triangles and indexes into this atlas. In fact, when the Text.NativeRendering render type is in use in Qt Quick, this is precisely what happens. In this case, we will ask the underlying font system (CoreText on macOS, GDI/DirectWrite on Windows and Freetype on Linux) to rasterize the glyphs at a specific size, and then we will upload these to a texture atlas which can later be referenced by the triangles we put on the screen.

Contents of texture atlas in a typical Qt application.

There are some limitations of this approach however: Since the font size has to be known before the glyphs are rasterized, we may end up rasterizing and caching the same glyphs multiple times if the text in the UI comes in many different sizes. For some UIs that can be too heavy both for frame rate and memory consumption. Animations on the font size, for instance, can cause us to rasterize the shapes again for every frame. This rasterization is also done on the CPU, which means we are not using the resources of the device to its full potential when preparing the glyphs.

Additionally, transformations on the NativeRendering text will give pixelation artifacts, since they will be applied to the pre-rasterized image of the glyph, not its actual mathematical shape.

So what is the alternative?

For a more flexible approach, we want to actually do the rasterization on the GPU, while rendering our frame. If we can somehow get the shapes into the graphics memory and rasterize them quickly using a fragment shader, we free up CPU resources and allow both transformations and size changes without any additional penalty on performance.

There are several approaches to this problem. The way is is done in Qt is by using so-called distance fields. Instead of storing the rasterized glyphs in texture memory, we store a representation of the shapes in a texture atlas where each texel contains the distance to the nearest obstacle rather than the coverage.

A distance field of the same Q, as an 8-bit map where each value is set to the distance to the nearest point on the outline of the glyph

Once these distance fields are created and uploaded to texture memory, we can render glyphs at any font size and scale quickly on the GPU. But the process of converting the shapes from the fonts into distance field is still a bottle neck for startup time, and that in particular is what this blog is about.

So what is the problem?

Creating the distance fields is CPU-bound, and – especially on lower-end hardware – it may be very costly. By setting the QT_LOGGING_RULES environment variable to “qt.scenegraph.time.glyph=true” we can gain some insight into what that cost is. Lets for instance say that we run an example that displays 50 unique Latin characters with the Deja Vu Sans font (the simple and neat outlines further up). With the logging turned on, and on an NXP i.MX6 we have for testing in our QA lab, we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 25ms, rendering=19, upload=6


From this output we can read that generating the necessary assets for these 50 glyphs took 19 ms, over one whole frame, whereas uploading the data to the graphics memory took 6 ms. It is the 19 ms for converting into distance fields that we will be able to reduce. These 19 ms may not seem like a lot, but it will cause the rendering to skip a frame at the point where it happens. If the 50 glyphs are displayed at startup, then those 25 ms may not be as noticeable, but if it is done during an animation, it would be something a user could notice. It is worth mentioning again, though, that it is a one-time cost as long as the font remains in use.

Running the same for the HVD Peace font (linked as the complex font above), we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 1016ms, rendering=1010, upload=6


In this case, we can see that rendering the distance fields takes a full second, due to the high complexity of the outlines in use.

Another use case where we may see high costs of generating distance fields is if the number of unique glyphs is very high. So let us test an arbitrary, auto-generated “lorem ipsum” text in Chinese with 592 distinct characters:

qt.scenegraph.time.glyph: distancefield: 592 glyphs prepared in 1167ms, rendering=1107, upload=60


Again, we see that generating the distance fields takes over one second. In this case, the upload also takes a bit longer, since there is more data to be uploaded into graphics memory. There is not much to be done about that though, other than making sure it is done at startup time and not while the user is watching a smooth animation. As mentioned, though, I will focus on the rendering part in this blog.

So what is the solution?

In Qt 5.12, we will release a tool to help you improve on this for your application. It is called “Qt Distance Field Generator” and you can already find the documentation in our documentation snapshot.

The way this works is that it allows you to pregenerate the distance fields for either a selection of the glyphs in a font or all of them. Then you can append these distance fields as a new font table at the end of the font file. Since this custom font table follows SFNT conventions, the font will still be usable as a normal TrueType or OpenType file (SFNT mandates that unsupported font tables are ignored).

So the font can be used as normal and is still compatible with e.g. Qt Widgets and Text.NativeRendering, where the rasterization will still go through the system.

When the font is used in Qt Quick with Text.QtRendering, however, the special font table will be detected, and its contents will be uploaded directly to graphics memory. The cache will therefore be prepopulated with the glyphs you have selected, and the application will only have to create distance fields at runtime if they are missing from this set.

The result of this can be impressive. I repeated the experiments, but with fonts where I had pregenerated distance fields for all the glyphs that were used in the example.

First example, simple and neat “Deja Vu Sans” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 11ms


Second example, complex “HVD Peace” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 4ms


Third example, 592 Chinese characters:

qt.scenegraph.time.glyph: distancefield: 592 pre-generated glyphs loaded in 42ms


As we can see, there is a great improvement when a lot of time is spent on creating the distance fields. In the case of the complex font, we got from 1016 ms to 4 ms. When more data is uploaded, that will still take time, but in the case of the Chinese text, the upload was actually faster than when the distance fields were created on the fly. This is most likely a pure coincidence, however, caused by the order of the glyphs in the cache causing slightly different layouts and sizes.

Another peculiar thing we can see is that the complex font is faster to load than the simple one. This is simply because the glyphs in that font are square and compact, so there is not a lot of unused space in the cache. Therefore the texture atlas is a little bit smaller than for the simpler font. The complexity of the outlines does not affect the loading time of the atlas of course.

Running the same tests on my Windows Desktop workstation, we see that there is not as much overhead for generating the distance fields, but there is still some performance gain to be seen in some cases.

For 50 Latin glyphs with Deja Vu Sans, both tests clocked in at 3 ms, which was mainly spent uploading the data. For HVD Peace, however, generating the distance fields took 131 ms (versus 1 ms for just the upload) and for the Chinese text it took 146 ms (vs 11)

Hopefully this can help some of you get even better performance out of your Qt devices and applications. The feature is already available in the Qt 5.12 beta, so download the package and take it for a test drive right away.

The post Introducing the Distance Field Generator appeared first on Qt Blog.