17 Oct 2018

feedPlanet KDE

16.04 EOL on Monday

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.

17 Oct 2018 5:41pm GMT

KDE Bugsquad – Konsole Bug Day on October 20th, 2018

We will be holding a Bug Day on October 20th, 2018, focusing on Konsole. Join at any time, the event will be occurring all day long!

This is a great opportunity for anyone, especially non-developers to get involved!

  1. Mascot_konqi-support-bughunt.pngCheck out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
  2. Log into KDE Phabricator and join the Bugsquad!
  3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
  4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!

17 Oct 2018 12:30pm GMT

16 Oct 2018

feedPlanet KDE

Krita at the University of La Plata

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.

16 Oct 2018 10:12am GMT

LaKademy 2018 – Third and Fourth Days (October 13th and 14th)

The third day of LaKademy 2018 was my last day participating on the event. During October 13th, we started the day with a promo reunion. This reunion was done to discuss about some plans and actions for the Latin American KDE community over the next year. Some decisions were made and topics were discussed involving … Continue reading LaKademy 2018 - Third and Fourth Days (October 13th and 14th)

16 Oct 2018 3:16am GMT

15 Oct 2018

feedPlanet KDE

Sizeable donation from Handshake Foundation

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.


15 Oct 2018 10:09pm GMT

Interview with Sira Argia

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?


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…"

15 Oct 2018 12:41pm GMT

And so the Fundraiser Ends

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:

1 - Papercuts 202
2 - Brush Engine 132
3 - Animation 128
6 - Vector Objects and Tools 73
5 - Layers 59
7 - Text 48
10 - Photoshop layer styles 43
4 - Color Management 29
9 - Resource Management and Tagging 20
8 - Shortcuts and Canvas Input 18

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

15 Oct 2018 10:33am GMT

digiKam Recipes 18.10.15 Released

It's time for another digiKam Recipes update. The most visible change in the latest revision is the new book cover. All screenshots were also updated to reflect changes in the current version of digiKam. In addition to the visual tweaks, the latest revision features new content. Continue reading…

15 Oct 2018 12:00am GMT

14 Oct 2018

feedPlanet KDE

Support KDE via AmazonSmile

For quite some time, the KDE e.V. - KDE's non-profit organization - is listed in the AmazonSmile program. On the AmazonSmile website it says:

AmazonSmile is a website operated by Amazon that lets customers enjoy the same wide selection of products, […]. The difference is that when customers shop on AmazonSmile (smile.amazon.com), the AmazonSmile Foundation will donate 0.5% of the price of eligible purchases to the charitable organizations selected by customers.

In other words, if you do a lot of shopping on Amazon anyways, make sure to start shopping via smile.amazon.de and choose the "KDE e.V." as organization. This way you financially support the KDE e.V., even without having to pay more. I am posting this here since I know many people who buy things on Amazon several times a week. Feel free to spread the word & happy shopping

PS: This is not supposed to be advertisement for Amazon. You can also donate to the KDE e.V. directly.

PPS: It seems the KDE e.V. is only available on German Amazon.

14 Oct 2018 8:02pm GMT

Who is Hiring?

Just as quick info: For some time, there is a sticky thread on r/cpp about who is hiring C++ developers. This thread gets cleaned quarterly, so all the open jobs listed there are likely still open. The same was just started on reddit for r/Qt5: Who's Hiring Qt Devs - Q4 2018: So if you are looking for either C++ or Qt jobs, this is a good place to have a look at from time to time. When I just looked for r/Qt5, the list was still empty, but this hopefully changes soon, given that the post was added just some hours ago.

14 Oct 2018 6:08pm GMT

The Last Day of the Krita Sprint and the Last Day of the Krita Fundraiser

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!

14 Oct 2018 4:13pm GMT

Screen reader accessibility for the Plasma desktop

It's been rather quiet when it comes to accessibility in KDE land for a while. But I'm very happy to see some movement and fresh energy, moving in a good direction.

If you're curious about making our software available to more users, improving it for everyone (for example keyboard usability), now is the time to join. We are talking on the accessibility mailing list. It's still to early to say what the exact plan will look like, but there will be progress. Thanks to the last Randa meeting, we reached the point where a few things in Plasma do work with a screen reader, enough to let a few brave souls experiment with it. Now we'll have to structure what needs improvements, I could imaging defining some workflows. Once we have broken down the big goal of making Plasma a joy to use with a screen reader, we'll have to make sure of a few things for each sub goal:

We will try to coordinate the work starting on the Plasma Accessibility Phabricator board.
I think we really need someone to take on the role of coordinator and help move this forward, listening to users what's most important and getting developers to spend a little time fixing things. This is really something anyone can help with, and I think we already have some people interested on the list.

14 Oct 2018 11:53am GMT

Please help test our initial Cosmic 18.10 RC ISOs

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.


... 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

14 Oct 2018 8:44am GMT

This week in Usability & Productivity, part 40

Welcome to an even more humongous week in KDE's Usability & Productivity initiative!

I'd like to specially highlight one very important fix this week: external hard drives are now safely powered off when unmounted. The fix is in KDE Frameworks 5.52, which will be released in approximately three weeks, and I'd like to give a big thanks to Stefan Brüns who fixed it!

Speaking of Stefan, he and Igor Poboiko have been doing an absolutely smashing job fixing Baloo over the past two weeks. A lot of their work is hard to blog about because it's not immediately user-facing (though I've included as much as possible below), but between the two of them, they've made an enormous number of improvements to Baloo that should make it work faster and more smoothly in a lot of subtle ways.

But obviously that's not all; take a look at the rest of the week's work:

New Features


UI Polish & Improvement

Also, I want to mention that we're aware of two high-profile issues in Discover that slipped by testing and made it into the 5.14.release:

We apologize for these bugs and we're working to get them fixed quickly!

One of the reasons why bugs like this squeak through is that we don't have enough pre-release QA testers. You could be one of them, and next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don't have to already be a programmer. I wasn't when I got started. Try it, you'll like it! We don't bite!

If my efforts to perform, guide, and document this work seem useful and you'd like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

14 Oct 2018 6:01am GMT

13 Oct 2018

feedPlanet KDE

LaKademy 2018 – Second Day (October 12th)

Every new code follows new bugs. During the second day of LaKademy I was more focused on resolution of bugs in the code that I implemented during the first day for KDE Partition Manager. During the afternoon, I decided to start RAID resizing and discussed with Andrius Stikonas on calamares IRC channel about some RAID … Continue reading LaKademy 2018 - Second Day (October 12th)

13 Oct 2018 2:29pm GMT

KF5 Static Builds

Static linking has long gone out of fashion, at least on the average Linux desktop distribution. There are however good reasons to still (or again) support this for our frameworks. One is the rise of application bundles (Flatpak, Android APK, AppImage, etc).

Bundles often only contain a single executable, so there is no benefit of sharing a library (at least in most bundle formats, Flatpak is a bit different there). Still we need to ship everything the shared libraries provide, no matter if we need it or not.

Static linking is of course not the magic solution to this, but it's a fairly generic way of allowing the compiler to drop unused code, reducing the application size. As application bundles are usually updated as a whole, we also don't benefit from the ability to update shared libraries independently, unlike with a conventional distribution.

Besides application bundles, there are also single process embedded applications that can benefit from static linking, so this is relevant for the effort of bringing KF5 to Yocto. In particular on lower powered embedded devices the startup overhead of dynamic linking can be noticeable.

Build System

In order to make our frameworks usable as static libraries, there's essentially two areas that might need a few adjustments, build system and code.

On the build system side there's two things to look at. The first one is to not force libraries to be built as shared libraries and instead allow the user to select this. That is, don't use the SHARED keyword in the add_library call. Normally CMake would default to static libraries when doing that, but ECM's KDECMakeSettings changes that for us. To actually build static libraries, you need to set the BUILD_SHARED_LIBS CMake option to OFF (example).

The other aspect that needs attention on the CMake side is how private library dependencies are handled. For shared libraries the consumer doesn't need to know anything about those as this is encoded in the shared library file. A static library however is just a simple archive of object files, without such meta data, so public and private dependencies are conveyed in the CMake config file to the consumer. This however means that the consumer needs to also look for all private dependencies in order to link against those. That's done by also listing those in the CMake config file for the static library, next to the public dependencies already listed there (example).

Static Initialization

One rather subtle but far reaching difference to dynamic libraries is how static initialization works. That is, code that is implicitly executed when loading the library (even before the application code is run). Static initialization is used in a number of places:

With dynamic libraries this works on all platforms, with static libraries it doesn't work in many cases and thus cannot be relied upon anymore. So, we need to change code affected by this.

This usually implies moving code that would run as part of static initialization to a later point in time, e.g. on first use of whatever is initialized. This can be beneficial for startup performance, but we have to be careful to not accidentally move potentially expensive operations on hot paths at runtime instead then (basic example, more exotic example).

Another potential place for such initialization code would be single entry points in to the library, such as QCoreApplication is for QtCore. The last resort approach is an explicit init() function as discussed here. That however changes API from a user point-of-view, so I'd avoid that where possible.

Identifying all affected code is not always straightforward. Broad unit test coverage provides great value there, but ultimately you probably want to look at all method calls in the .init_array section of the dynamic library (or the corresponding non-ELF counter-part on other platforms), e.g. using a tool like ELF Dissector. Not everything in there is automatically a problem, but all problems will be in there.

Further Challenges

Another thing that doesn't make much sense in a statically linked setup is usage of dlopen (or its counter-parts on other platforms), most commonly used by plug-in systems. Qt has a solution for statically linking plug-ins as part of QPluginLoader. That can be a bit of work to use in practice as all plugins need to be consumable as static libraries by the application too, and need manual Q_IMPORT_PLUGIN statements, but at least it's nothing that requires creative solutions.

Static linking of course is not the complete solution to being able to create single application bundles, frameworks relying on multi-process architectures, daemons, IPC, etc need to be addressed independently of that still.

One problem we don't have for KDE applications at least are license issues caused by static linking, that's left to proprietary users ;)

13 Oct 2018 9:45am GMT