January 15, 2020

Following Kévin here’s the summary of what happened around KDE PIM in the last two months. While this post got slightly delayed due to the holidays, work didn’t slow down at all. More than 1300 changes by 26 contributors landed in the KDE PIM repositories, and we got the 19.12.0 release out in December.

KMail

  • Work on DKIM validation of emails continued, in particular regarding improving the parsing of authentication results.
  • KMail’s snippet system can now also insert attachments, with the attachment names being able to use the variables of the snippet system as well.
Configuration of variables in an attachment name in a KMail snippet. Customizable attachment names in KMail's snippet system.
  • The extraction engine behind the itinerary plug-in received a number of improvements described in a dedicated post.
  • Using GSSAPI authentication on IMAP servers no longer results in password prompts (bug 383279).
  • Fixed false positives in the message view external references warning (bug 415254).
  • Sanity-check collection path before performing recursive deletion in maildir backend (bug 414178).
  • Fixed automatic folder expiration not triggering correctly (bug 414839).
  • Warn when email identity settings cannot be written (bug 414171).
  • Fixed saving dialog not proposing a file name (bug 414825).

KOrganizer

  • The reminder daemon now honours the global notification inhibition.
  • Month view: Fix background color computation with dark themes (bug 413521).
  • Month view: Fix chronological sorting in day block (bug 232162).
  • Agenda view: Fix grid colors when not using system settings (bug 411608).
  • Incidence editor: Broken layout does no longer resize attendee list (bug 414977).
  • Fixed recurrence rule generation for timezones with newer libical versions.
  • Handle incidences in different time zones in KCalendarCore::MemoryCalendar.
  • Optimize date-bayed caches in KCalendarCore::MemoryCalendar.

Kleopatra

  • Redesigned certify dialog.
  • Added remark support in key views and certify dialog.
  • Fix overwriting files when exporting secret keys.

Akregator

  • Support displaying icons from Atom feeds (bug 414086).
Akregator feed tree view showing feed icons. Akregator showing icons for all feeds again.
  • Fix initial scroll position in inline article view (bug 177511).
  • Allow to show feed copyright information.
  • Fix getting the feed URL from a Youtube channel (bug 383381).
  • Make the “Add feed” option more accessible (bug 297098).

Common Infrastructure

Following the KF6 sprint in November, preparations for the migration to Qt6/KF6 also started in KDE PIM, mostly in the form of porting away from already or about to be deprecated functionality in Qt5 or KF5, such as:

  • KTcpSocket (replaced by QSslSocket)
  • QRegExp (replaced by QRegularExpression)
  • Pixmap-based icon functions (also improves scalability on high DPI displays), as well as moving to QStyle for determining icon sizes.
  • qrand() (replaced by QRandomGenerator)
  • D-Bus service monitoring in QDBusConnectionInterface (replaced by QDBusServiceWatcher)
  • KRecursiveFilterProxyModel (replaced by QSortFilterProxyModel)
  • and many more

Being able to do this in small steps and ahead of the full transition to Qt6/KF6 will make this transition much smoother than it has been in the past.

Help to make Kontact even better!

Take a look at some of the junior jobs that we have! They are simple, mostly programming tasks that don’t require any deep knowledge or understanding of Kontact, so anyone can work on them. Feel free to pick any task from the list and reach out to us! We’ll be happy to guide you and answer all your questions. Read more here…


KUserFeedback is a framework for collecting user feedback for applications via telemetry and surveys.

The library comes with an accompanying control and result UI tool.

https://download.kde.org/unstable/kuserfeedback/

Signed by Jonathan Riddell <jr@jriddell.org> 2D1D5B0588357787DE9EE225EC94D18F7F05997E

KUserFeedback as it will be used in Plasma 5.18 LTS



Plasma desktop with a Windows 10-like theme.

Today Microsoft has left Windows 7 users behind.

Redmond will no longer provide updates for the 2009 operating system. This puts almost a billion people in the difficult situation of facing increased security risks alongside a slow decline in software availability.

Folks who reject Microsoft’s forced updates are already opting to regain control over their systems by switching to the friendly and full-featured Plasma desktop, built on a design philosophy which centers freedom and respect for its users. Recent buzz about the possibilities of Plasma has brought a lot of fresh faces on board, and now they are trying to navigate a new operating system that has its differences from Windows.

If you’re one of those people, you’re probably wondering where you can find experienced users to help you get settled in.

How to make the jump with ease

Luckily, there is a wealth of resources available for those new to Plasma and the Linux world.

The best place to talk live with Plasma users, ask questions, and get to know the KDE community is the KDE Welcome room on our webchat or on Matrix. If you want to discuss Plasma and comment on the latest KDE news with other users, find r/KDE on Reddit or check out the official KDE forums.

AskUbuntu.com is the largest dedicated tech support site in the Linux world, and an invaluable resource for anyone using KDE Neon or Kubuntu. Much of the info available here even translates well to other Linux flavors. Other places for specific support questions include r/Linux4Noobs and r/LinuxQuestions on Reddit. Talking of which, another great resource is the Linux Questions forums.

Once you have a little bit of experience under your belt, if you run into trouble with a specific system component, you can always resort to the Arch Linux wiki, an in-depth hub of documentation which is often useful to users of any Linux system.

Everyone in the KDE community is familiar with the hurdles new users face when making the jump to Plasma and the Free Software world. Don’t hesitate to take advantage of KDE's welcoming community who will help you feel right at home in Plasma and make sure you get the most out of your newly upgraded system.


January 14, 2020

I bought a MacBook end of 2014. My initial reason to buy it was to improve the Kate port for macOS. Beside that, I wanted to try if the Apple ecosystem and macOS are really that great and will solve all my issues in life (short answer: no, they aren’t, at least not for me). The HiDPI screen looked nice, too :=)

After some initial “not a lot works”, if you don’t go the Homebrew or MacPorts way, the Kate port improved over the following years.

I learned a lot about standalone non-Linux deployment of applications and macOS specifics in the process.

As a side-effect of my porting efforts, with the help of others, I was able to improve the deployment of KDE Frameworks in some ways, e.g. by allowing to bundle more stuff inside Qt resources.

For example the KSyntaxHighlighting or KTextEditor frameworks are now just a library you link, you don’t need to deploy any extra data files. This is a huge improvement, if you want to bundle them with your standalone application.

Unfortunately, my initial hope, that we would get more people contributing to the macOS port (and with this to KTextEditor/Kate/…) didn’t really take off.

Beside some minimal help, not a lot happened.

I think my last self-provided bundle update for macOS was in 2016.

The binary factory still churns out new builds, you can grab them via the links on our download page.

I occasionally tried them, but they never got polished in a way like our Windows variants that we now even ship via the Windows Store.

Apple doesn’t make the world a better place with each update of macOS, see for example the now necessary notarized builds and the effort the cause for e.g. Krita (and with necessary I mean: you shall do it, otherwise your users are nagged with “do you really want to execute this…” stuff that makes a very bad impression).

In the last years, I used my MacBook more or less just to either grab some stuff from iTunes or do stuff inside my Linux VirtualBox there.

Given I anyways have a proper Windows 10 VM to take care of the Windows development for Kate (yes, Apple, Microsoft allows that officially, you can just buy a license, you can even get some ‘free’ developer VM images for a fixed time…), I just migrated my seldom used iTunes account to that machine.

With that away, I just installed purely Manjaro Linux on my MacBook last evening, who cares, I anyways don’t use macOS at all beside as VirtualBox startup environment.

I searched for some pointers in the internet, in the past I already had some parallel install. If you search a bit, you will find various hints how to do it.

If people want to do the same as me, a pure Manjaro install without keeping any macOS around, here a minimal how-to for a MacBook Pro Retina 13” (model number MGX82**/A, model id MacBookPro11,1):

  • Get the USB installer from their Manjaro Linux homepage, I used the KDE variant ;=)

  • Get it on a stick and plug it into your MacBook

  • Boot up your MacBook (pressing the ALT key)

  • Select the EFI boot option.

  • Start the live system, like on any other machine

  • If you want to have internet, which is a good idea to e.g. later easily install the Broadcom driver, use your mobile phone with USB-tethering

  • Install it normally, I used the “erase my full drive and encrypt it” variant. Be careful, your data is gone afterwards, you got warned!

  • Reboot your MacBook, you will boot into your fresh installed Manjaro

  • Install the matching Broadcom driver for your kernel, something like “linux54-broadcom-wl”

  • Install some fan control like “mbpfan-git” and enable it afterwards with “sudo systemctl enable mbpfan” + “sudo systemctl start mbpfan”

For me this did the job and the stuff is running well enough. The webcam won’t work without additional effort, not that I use it. No idea if Bluetooth or other stuff like the Thunderbolt ports work, but I never used that even on macOS.

Fortunately the HiDPI support on Linux & Qt & KDE has gone a long way since my initial try 2015 and now, with some scaling of 1.5 or 2, it is all nicely usable ;=)

Given I still have some macOS machines available at work, I might still try out some Kate bundles there from time to time, but my personal life is now macOS free.


https://zanshin.kde.org/2020/01/14/zanshin-0.5.71/

We are happy and proud to announce the immediate availability of Zanshin 0.5.71.

This updates the code to work with current libraries and apps from Kontact.

The GPG signing key for the tar is
Jonathan Riddell with 0xEC94D18F7F05997E
download.kde.org

 


We are happy and proud to announce the immediate availability of Zanshin 0.5.71.

This updates the code to work with current libraries and apps from Kontact.

The GPG signing key for the tar is Jonathan Riddell with 0xEC94D18F7F05997E.


2019

Let’s have some statistics first! Statistics are fun! (And notoriously unreliable) We started 2019 with about 450 open bugs — and that’s how we ended 2019. That said, we had 1236 new bug reports and closed 1272. Still, our 2018 fund raiser was all about getting rid of bugs, and that seems to be a tough proposition.

According to openhub, we had 2271 commits from 60 contributors. This excludes translation commits, because those are still done in a subversion repository, apart from Krita.

We had nine releases (4.2.0 to 4.2.8) in 2019, slightly less than we’d planned, we’d wanted to have twelve releases. But one of those releases was 4.2.0, which made HDR editing available to artists for the first time; no other application supported that when 4.2.0 was released in May.

We had four Google Summer of Code students, and most of their work has already been merged and will be in Krita 4.3.0: a new magnetic selection tool, the history docker and the android port.

Next to fixing bugs, we’re work on that 4.3.0 release, but the main reason why 4.3.0 didn’t happen in 2019 was because rewriting the core system for loading brushes, gradients and so turns out to be much more work than we had ever thought. We should have approached that much more gradually, but we couldn’t figure out how to make that work.

We had 2,346,618 unique downloads from the download page on this website; that excludes downloads from other download sites, downloads from release announcements or downloads from the various stores. At a guess, we’ll have topped 3,000,000 downloads in total this year.

We kicked off krita-artists.org as our new discussion and support site, and we’ve already got more than 1000 active users.

We also had the largest Krita Sprint ever.

Through the donation button on krita.org and the donation page you see after a download, we got €29,715.20 in donations. We made enough money apart from the donations from the Windows Store and Steam that this year we could hire three new full-time developers. And we got a grant from Epic, too.

In short, 2019 was a year when Krita saw a huge growth, almost scarily so!

If you want to play with what will become Krita 4.3.0, check out the nightly builds! (Windows, Linux, macOS)

2020

Our plans for 2020 are first and foremost to release Krita 4.3.0, with new features, lots of bug fixes, lots of performance improvements and the new resource management system. That’s going to take time, unfortunately. It’s that we’re releasing bug-fix releases that sometimes have smaller fun features all the time, otherwise it would feel like we’re doing something we shouldn’t be doing. That is, doing too big a rewrite. We are making progress, though and we’re going to have a small hacking sprint in February focused on the resources rewrite.

We’ll have our yearly large contributor sprint directly after the Libre Graphics Meeting in Rennes, France, hosted by ActivDesign. It’s the first time in many years that we’ll have a contributor get-together that’s not in Deventer!

We’ve also got lots of ideas for improving our way of working, for performance improvements to the brush engines, new features for the brush engines, workflow improvements (like a search function for the UI).


January 13, 2020

Task 1

View Task 1

Proxy types can be tricky. If we got a QChar (or a reference to a QChar) by accessing a character in a QString with the operator[] as most people would expect to, the automatic type deduction requested by auto current = hello[i] would deduce that current is of type QChar.

But QString::operator[] does not return a QChar. It returns a QCharRef. Even if we think of it as a reference to a QChar, the compiler does not, and the automatic type deduction can not remove the reference part like it would if the return type was a proper reference (QChar&).

This means that current will be a value of type QCharRef. When we modify it, it will modify the original string (contrary to what most people expect because of C++’s value semantics).

One of the solutions here is not to use automatic type deduction and explicitly specify the type of current to be QChar.

    QChar current = hello[i];

Another thing that could help is to declare the hello string to be const. It is a good practise to use const by default when declaring variables.

The second issue in the first task was that the original string ends with an exclamation mark, while the string in the Q_ASSERT does not.

Task 2

View Task 2

The problem in the second task is similar to the previous one. When we see strings being concatenated, we assume that the result is also a string.

String concatenation is slow (you can check out this post for more info) and Qt allows us to activate delayed (lazy) concatenation by defining QT_USE_QSTRINGBUILDER. Instead of operator+ returning a string, it will return a class called QStringBuilder which will keep references to all strings we want to concatenate and perform the concatenation only when we convert it to a QString.

This means that when we use the automatic type deduction – auto message = ... – we get a message variable that is not a string, but rather an object that keeps references to all the strings we want to concatenate. When we try to print it out with qDebug, it will concatenate all the strings and print out the result.

The problem is that one of the references in our example will be a dangling reference – reference to a temporary string returned by the tr function that has been destroyed before the actual concatenation is performed. So, we get undefined behavior (most likely a crash in this case).

This is easily fixed by explicitly specifying the type of message to be a QString. This will perform the concatenation before the temporary string returned by the tr function is destroyed.

Task 3

View Task 3

The final task is quite different to the previous ones. It shows a function implemented with two for loops nested into each other. The time complexity of the function is O(m*n) where m is the length of xs and n is the length of ys. The memory complexity is O(1).

If we analyze the function, we can deduce that it counts all the items in xs that are smaller than or equal to the smallest value in ys. While the provided example uses sorted vectors, it is obvious that this function also works for unsorted vectors.

One approach (a frequently submitted one) to solving this using the algorithms found in the standard library is to sort both collections and then use the lower_bound to find the first element in (now sorted) xs that is not smaller than the smallest element in ys (ys[0] after sorting). We can then use std::distance to get the count how many elements we have between xs.cbegin() and the item we just found.

The time complexity of this solution is O(n log n + m log m) which is better than the original implementation, but the memory complexity grew to O(m + n) because we need to copy the original vectors in order to sort them, which is significantly worse.

If we go a bit deeper, we can see that we are using just ys[0] so we don’t really need to have the whole vector sorted. We just need the smallest value in ys. We can find this in linear time with the std::min_element algorithm.

With this, we would end up with O(m log m + n) time complexity and O(m) memory complexity, as we are still sorting the xs. Better, but not good enough.

Now the question is whether we really need to sort the xs?

If we know the minimum of ys we need to compare xs against, it is much cheaper just to go through all the unsorted xs one by one and check which ones are smaller than to sort the xs first. This can easily be done with std::count_if:

    int counting(const std::vector<int>& xs, const std::vector<int>& ys)
    {
        if (ys.empty()) return xs.size();

        const int min_y = *std::min_element(ys.begin(), ys.end());
        return std::count_if(xs.begin(), xs.end(), [=] (int x) {
                return x <= min_y;
            });
    }

The time complexity of this solution is O(m + n) and the memory complexity is O(1) which is the best we can do for this problem.

The post KDAB Challenge Solutions appeared first on KDAB.


Late 2019 year-end post, I know. It’s been a rather busy start to the new year even when I tried to hit the ground running. Unfortunately, some things like blog posts have taken a backseat. Hopefully not for long.

2019 was a wild year for me personally and I don’t mean that in the completely good sense. One of the highlights, though, was being hired to do contractual work for KDE as a technical writer and documentation specialist. TL;DR I went through KDE’s developer docs and queried a few devs on the state of the documentation and what needs to be done to make it easier for new developers to get started using our libraries/frameworks and contribute to KDE projects.

It was definitely an honor to formally work for the community. I have been a sporadic contributor (lately more just helping out on IRC) and getting the chance to work on more technical matters again and be involved on a deeper level was exciting. Plus, the accountability definitely helped in the motivation aspect. Sadly, due to personal circumstances, I wasn’t able to follow up on the matter after the contract formally ended. Fortunately, that period is over and I can get the ball rolling again.

It’s probably no secret to both seasoned developers and those just getting their feet wet that our developer documentation is largely outdated except for a few bright points in the Community Wiki (kudos to contributors who continually update that!). Some hail from the pre-Frameworks days and some have never even seen the light of KDE4 (remember, there is no such thing as “KDE5”). They’re also a bit scattered here and there, with incomplete or even missing information. Suffice it to say, there’s plenty of things to do and plenty of ways for KDE helpers to join the game.

Here are just some of the things that need to get addressed in the coming months:

  • API documentation, a.k.a. apidocs, need filling up with more information and especially examples.
  • New or updated documentation for “hot” areas like Kirigami and Plasma/Mobile need to be written.
  • The TechBase and Community Wikis need to be cleaned up and content migrated to their proper places
  • Tutorials need to be updated or written and placed in their proper location (wiki or apidocs)
  • An improved onboarding for new contributors as well as external developers need to be developed.

You can view the initial report I submitted in June as well as an update I wrote in December here.

2019 was spent for analysis and planning so, hopefully, 2020 will be spent putting all of these into action. Writing documentation is often seen as a boring task but, especially when it comes to developer documentation, it can be the perfect opportunity to become familiar with the software and libraries, the tools and processes, and, most importantly, with the people and the community that make KDE awesome


I’ve been involved in the gbgcpp group, a part of the larger Sweden C++ community, for a couple of years. It is fun to see that there is a lot of C++ developers out there, once you start looking for them.

In the next meetup, this Wednesday, there will be both C++ and Qt. The topic is to implement Ribbons in Qt, based on a seminar by Dag Brück. If you happen to be in the vicinity of Gothenburg, I recommend you to go there!

I’d also like reach out and thank Sylog for hosting the event!


Could you tell us something about yourself?

My real world name is Andy Statia, but I go by Never Dot in the digital space. I live and grew up in Canada, for which I’m very grateful. Being in a temperate zone country, I get to experience the wild fluctuations between the seasons, which I’ve always found has really stimulated my imagination. Being able to directly experience frozen wastelands, verdant forests, and dying cities all without going anywhere has given me lots of ideas for my worlds.

I’ve always had a keen interest in both computers, drawing, and design. This meant spending my nights after school doodling and designing entire worlds then later learning to program on the family computer so I could bring those worlds to life through video games. This continued on
throughout my school years and I explored my artistic side through the creation of game art and world design. I later went to the University of Waterloo and graduated with a bachelor’s of mathematics. Since then, I’ve been working in the computing field, but always working to build up my creative side through digital art and web design.

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

For most of my life it was just a hobby, but in February 2016, I decided to try to turn professional and dedicated myself to starting a new company called Never Dot, which would be where my professional work would be created. Since then, I’ve strived to improve my art and learn professional skills.

What genre(s) do you work in?

I could easily be accused of having attention deficit disorder, because I have a hard time sticking to one genre. My current work is evidence of that, as I’ve tried to combine fantasy, science fiction, modern day life, and pretty much any other genre that I can rationalise into my world. Sticking to a single genre has always seemed unnecessarily restrictive and mashing together very different genres has always been a point of interest for me, to discover how they react to each other and work together (or not). My primary preference is creature design.

In my children’s books and comics, you can find spaceship flying dinosaurs with ray guns right alongside common vegetable folk running their shops and buying groceries (which is hopefully not just themselves). A turtle family deals with mobile phones and family issues while my main character, an octopus, has fiddled with magic to fix his computer as dragons try to steal his Halloween candy. I’m going to work pirates into this world next, most likely.

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

When I was just starting out professionally, I was sorely lacking in connection to the artistic community, which I still feel to be the case. But in the few years hence, I’ve discovered Li Chen of Exocomics who I consider to be my gold standard for what I’m trying to achieve. The quality of her artwork and the level of cuteness she brings forth in everything she does is exactly what I want to achieve in my work. If I’m ever able to match her art, I would consider my artistic life’s goal to have been met.

However, on the opposite end of the spectrum is Ross Tran, Asia Ladowska, and Laura Brouwers (Cyarine). These people have shown me it’s possible to create incredible work through practice, time, and experience. Drawing humans is my greatest fear, but I need that skill set to be able to tell the visual stories I want to tell, so these are my role models for that pursuit.

Lastly, I should note Randall Munroe of XKCD, who shows all of us that you don’t need to be a great artist to be interesting and worth paying attention to.

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

While I had been “digitally painting” in MS Paint from a very young age, I suspect my pixel art of the time isn’t what you’re interested in. For a more professional level of digital painting, I would say it was during my first co-op work term at university. It was my first period of time earning meaningful income and the first thing I set out to purchase was a drawing tablet. Since I’m quite bad with money, I opted for the largest tablet I could find, which was the Wacom ArtZ II 12×12 tablet. It was big, square, and threw off the aspect ratio on my drawing for a couple years before I clued in that I should be limiting the drawing area to correct for that. I later migrated to the Intuos line of tablets and used some Bamboo tablets at work (as I’d long since gotten used to a stylus). I am now on my second Cintiq for day-to-day work.

What makes you choose digital over traditional painting?

The inability to undo is probably the biggest reason to go with digital over traditional. I only traditionally painted in a university course and since I was already digitally painting at the time, I found that the inability to control layers, adjust effects, and such in physical media was frustrating.

I’ve never lived the traditional painting life, so digital has always been my first choice. However, I recognise that experiencing traditional painting methods has benefits that would help inform my digital painting techniques.

How did you find out about Krita?

I had been using Fractal Design’s Painter (now Corel’s) for many years, over a decade, and while I depended on it immensely, it was also somewhat buggy and the numerous upgrades I’d purchased were always introducing more problems than solutions for me. As such, I was pushed to find an alternative. I looked into Sai and Clip Studio Paint as being well received in the community. I was avoiding Photoshop both due to the subscription requirement and the fact it wasn’t directly targeted at natural media painting. Krita came up in my research as being a free painting tool. I checked out numerous YouTube reviews and comparisons, and being free let me try it out directly.

What was your first impression?

My first experiences with the program were that it was very smooth and easy to figure out. Coming from a Painter background, I was looking to recreate my workspace in Krita and ensure it had the same capabilities. Exploring Krita’s brushes was probably what got me hooked, as I’d found a large sponge brush that gave the effect of fog or mist. This was something I’d never effectively created in Painter and I was immediately entranced by the simple effect it produced. After I got the keyboard shortcuts figured out (or reconfigured) and tools identified, I was settled and able to get work created in Krita. Initially, I used it for effects, creating the main work in Painter. But in time I was creating entire pieces in Krita.

What do you love about Krita?

The large sponge brush, which I believe comes from David Revoy’s brush pack, was the first thing that really captured my interest. Such a brush can of course be created in other programs, but brushes are the heart and soul of these programs, so that got me hooked.

I found the reference docker to be extremely useful. Having a little docked panel on the side that automatically colour picked when I clicked on it, allowed independent panning and zooming, was probably the most useful tool I’d used in quite a long time. Since I had a lot of different characters to paint that needed consistent colouring, I would just load an unshaded picture of them to use as a palette, since I could then know which red was the body red vs. the sock red. Normal colour palettes aren’t as quick to find desired colours. Sadly, this tool was removed some versions ago and replaced with something a bit less useful.

A tool that sort of existed in Painter, using vector shapes as guides, has proven much better in Krita. The guides tool, which allows for parallel lines, ellipses, perspective drawing, etc. is extremely intuitive and useful. Particularly the vanishing point guide. Other programs attempt to display a 3D grid and provide complex controls to position it. Krita just gives you the vanishing point and two control points for each edge, which is easy to align to your sketch. For ellipses, the ghosted circles showing before I start drawing is fantastic. I’ve sometimes used this preview with the drawing constraints turned off just to help line things up.

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

A generally known gap in Krita’s toolkit is text support. I discovered right away it wasn’t even basically functional, so I use Illustrator to do all my text layout for Krita. Having easy to use text boxes would be great.

Working with vectors is somewhat more cumbersome in Krita than other applications. In most other applications, each shape is its own layer, which makes it easy to locate them, manipulate them, and create them, as it doesn’t require creating a special layer to manage them.

A persistent bug that impacts all my work is the “unable to pan after using something in the interface”. This typically happens after renaming a layer and then trying to pan immediately after with the spacebar. Instead of panning, nothing happens, and I wind up drawing a harsh line through my artwork, which I hopefully notice and undo immediately. This interrupts my workflow several times per drawing session.

As noted earlier, I haven’t found the new reference image tool to be particularly usable. A reference image should be visible and stationary while drawing. I’m often panning and zooming while working, but if the reference image gets panned or zoomed off screen, it becomes useless. I also frequently need to just have a zoomed in portion of the reference image up, so I can refine details of it, which the old docker did perfectly, since it allows for sizing that window area and zooming within it independently.

More natural media brushes is always welcome, particularly from the base install. This is one area where I sometimes look back at Painter for, as it had such a wealth of natural media brushes. Recreating them myself isn’t always possible (i.e. doesn’t produce good results).

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

Being free is an extremely impressive feature for this product. While that doesn’t relate to features, the fact that a tool of this level of capability is free is amazing. It has successfully replaced a $500 professional tool without sacrificing much of anything.

Something Krita excels at for me is being able to handle very large canvases without crashing or slowing down. This was a point of concern for me with Painter and I was amazed that Krita was able to continue running at full speed at progressively larger canvas sizes. While I do still learn about its limits, I’m able to push it farther than what I used to have.

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

I’ve done a lot of different pieces over the last three years for Never Dot, many I’m very proud of, many that I cringe at. But one of the more exciting pieces I did recently was for last Halloween, which features a lot of my characters packed into a tight scene. Highly detailed scenes have always interested me, because you can see something new time and time again when you come back to it. Playing with lighting effects is also something I quite enjoy and this one takes advantage of it a lot. I previously noted that I have a hard time sticking to one genre and if anything highlights that, it’s this scene with sci-fi, fantasy, modern day, dragons, and steampunk marching around.

What techniques and brushes did you use in it?

My work is mostly cartoon art and painted backgrounds. I created my own pen brush, as none of the ones in Krita were quite the same as what I was used to. It’s a simple solid brush with hard edges.

I use the hard light layer mode for shading, using the inherit alpha feature to limit the shadows to the foreground character. This feature has saved me immense amounts of time.

Another extremely useful capability is filling line art into a different paint layer. This saves hours of my time.

Where can people see more of your work?

I put almost all of my work up on my website and various social media accounts. You can find my comics, drawing practice, and links to my children’s books on my website at: https://neverdot.com

You can also look me up on Instagram (@neverdotworld), Twitter (@neverdot), and Reddit (/u/NeverDot). I’ve also got a YouTube channel where you can see the real me! Find that at https://youtube.com/neverdot.

I’ve self-published four children’s books featuring my world which are fully illustrated with my work. The first book used Painter and the next three were completely done in Krita! You can get those on Amazon, Indigo, and other book websites. Check out my website details on the books!

Anything else you’d like to share?

Krita being open-source is a huge victory for both the open-source movement and digital artists. Anyone with a computer now has access to a fully capable drawing solution that compromises on nothing (well, maybe text support). If my professional Never Dot work becomes highly successful, I’ll definitely be looking to financially support the Krita development team to ensure future generations of artists are able to benefit from such a polished art tool. Thank you Krita team! Your dedication to the project shows and everyone using Krita is thankful for having you working behind the scenes.


January 12, 2020

In august, Dan Vrátil wrote about Kontacy and Google integration issues. Kontact is KDE’s personal-information management suite, which builds on top of Akonadi, and includes KMail, contacts and calendaring.

The most important bit of Dan’s blog post is this:

This is due to an oversight on our side which lead to Google blocking Kontact as it did not comply with Google’s policies.

You can see the consequences of that oversight in KDE bugs, for instance kmail no longer allows addition of gmail account or Dolphin Kio-gdrive authentication with Google account fails. There are probably multiple duplicates in KDE’s bugzilla as well.

The Google account used for the integration – the one that “owns” the API tokens and a few other things – has the KDE e.V. board email attached to it. That’s sensible, since Google integration in KDE applications and frameworks is something institutional, not personal (so it wouldn’t make sense to have any individual developer’s address on it). The e.V. exists to support the community, after all.

This does mean that when things break with the integration – and they have been broken, for months now – the board gets email with questions. This is a semi-official statement from the board about what’s going on (semi-, because it is on my personal blog, and statements like “I don’t know” and “I don’t use” are personal, not institutional).

  • Why have things been broken for months? The integrations were shut down by Google for policy compliance reasons. Finding out what those policies are (board), fixing things to comply (KDE-PIM developers) and filing an appeal (board) all take time, lots of time, and then you get into the morass of waiting-for-appeal-to-go-through.

    I’ve clicked around in the application dashboard for our account, mostly going “what do they want us to do?” Frankly, I can’t tell. There’s an orange dot next to kde.org sometimes, which suggests the domain needs to be verified. I have no idea.

  • Has there been any progress? Yes, there has. kaccounts-provider has been approved for calendar and contacts (and some others), so it should start to work again. I don’t know what functionality exactly is covered by this provider (but see below).
  • Is there a workaround? You can use the one described in Dan’s blog post.

So, progress is really slow because we’re dealing with a totally opaque “adversary”. There is some progress, and we’re expecting that the KDE PIM developers will announce success soon-ish.

Update: Dan has been active behind the scenes, and calendar and contacts syncing should work again if your distribution backports some specific changes (the changes will be in the February release of KDE software). He writes

We’ve recently had to adjust which parts of Google accounts we request access to when users sign into their Google account in Online Accounts KCM. The list of requested scopes needs to be adjusted in kaccounts-providers package as well, otherwise login is refused by Google. This mostly affects KIO GDrive, which accesses user’s GDrive account through Online Accounts.

Note that GMail is not yet fixed; that’s a separate effort. Thank you Dan for clarifying!


Hello all! I am late with my blog posts, I know. One week I was too tired, the other I got sick, the other I drank and ate a little too much, the rest I was too busy. This however means I’ve had more weeks available at work to use the next environment in this series, i3, whose workflow is heavily-keyboard driven. Although it’s not a Desktop Environment, it deserves an analysis due to the mere fact it’s highly keyboard driven.

For those who aren’t acquainted with this series yet, I am in an endeavor to analyze keyboard shortcuts in most major DEs so that we, the KDE community, can decide on the best defaults for KDE Plasma. I have already taken a look at Cinnamon, MATE, XFCE and GNOME.

Preparations

This time I’ve added i3wm to my work computer, which has Kubuntu 19.04 with backports, and also tried Manjaro i3 briefly. The first was done as the previous times, for convenience; the latter was chosen simply because Manjaro ships a community edition with i3 by default, which caters to the significant Arch/Manjaro userbase of i3, but as it is a highly customized community edition of Manjaro, and thus includes about five times more keyboard shortcuts than default i3, I did not include most of its keyboard shortcuts here.

Since i3 is single-config-file-based and is hosted on github, it was easy to both check on how upstream suggests that keyboard shortcuts should be bound and keep track of keyboard shortcuts.

You may also see the default Manjaro i3 config file here if you’re curious about it. Manjaro does include several interesting QoL utilities such as i3exit and blurlock.

Despite that, this post will be considerably lengthy because, although upstream i3 has few shortcuts, several of them introduce complex concepts.

In addition, due to the nature of i3’s config file, this post is more complex and requires previous knowledge on Linux and perhaps coding before grasping how i3 works. It’s not that complicated, but it’s quite the paradigm shift compared to DEs.

The Meta/Alt dillema

Right after booting into i3, a small utility called i3-config-wizard will run and ask us if we would like to have Meta or Alt as the main modifier.

After choosing any of the two, it will promptly read the keycodes of your keyboard layout so that it can generate a config file in ~/.config/i3/config which is keysym-based.

Now, I’m not that knowledgeable about how keyboards are managed at such a low level as X, but I think what this means is that i3 lets the keyboard be detected by X, which typically associates keypresses with keycodes, similarly to how XF86 keys work. Keycodes for your keys can be seen with xev, bound with xmodmap/xbindkeys, and shortcuts for them can be set with xdotool. The i3-config-wizard utility will then notice if something in your keyboard layout differs from default US QWERTY keyboards, and sets a keysym for that keyboard shortcut to work properly.

This is better explained with an example; my keyboard layout, ABNT2, has a left-to-right sequence “hjklç”, which differs from standard US QWERTY, “hjkl;”. Thus, as i3 checks the keycodes in my keyboard layout and notices that a ccedilla ç is situated where a semicolon ; is typically located, it writes the config file as to include “ccedilla” instead of “semicolon”, the latter of which would be out of place in a typical Brazilian keyboard layout such as mine.

Hence, by not shipping a config file by default, i3 guarantees that each key is in its correct place, regardless of which key that is. I figure this should be particularly helpful with typical french AZERTY keyboards.

What I found most interesting the first time I used i3, long ago, was the extensive use of letter keys corresponding to the arrow keys. The default i3 comes with jkl;, which is vim-like, but not a clone to vim, which uses hjkl. This is so because jkl; is perfectly positioned on the home row, thus rendering it more natural for typing.

I am particularly fond of this stance since the i3wm developers decided for the assumedly better, most ergonomic choice instead of simply adhering to vim keybindings, whose defaults are kept to this day for historical reasons which no longer make sense.

For those who are unaware of vim keybindings, vim is a default editor which can be found in most linux systems—if not all of them—whose workflow attempts to keep the user’s hands near the main letter section of the keyboard, and so it avoids the arrow keys, the Home/End/PageUp/PageDown keys and the Numpad area. For that, it binds h to left, j to down, k to up and l to right. In i3 this is brought one key to the right, so j is left, k is down, l is up and ; is right. Those can be changed for whoever would like to use vim keybindings or, if they are moved away from i3 simply due to this design choice, sway adopted vim keybindings by default and is quite similar to i3, as can be seen here.

Anywho, back to the topic: i3-config-wizard serves to associate such keys dynamically for you, but it also serves to set the default modifier key for your keyboard shortcuts, namely Meta or Alt, as mentioned earlier.

This is a highly critical choice to me, at least insofar as it is problematic. In addition to the main modifier key, the Shift key is quite used as well. If one chooses Meta, then Meta would stay perhaps too close to the Shift key, potentially rendering awkward hand positions, such as Meta+Shift+Q; if one chooses Alt, then the user will see themselves encountering less awkward hand positions, but since i3 extensively uses the first-letter-for-functionality convention (such as Modifier+F, where F means fullscreen), such fairly common combinations (Alt+F) might conflict with in-application keyboard shortcuts, most notably accelerators. For instance, Alt+F is a common accelerator and keyboard shortcut for opening the File menu in applications that come with a menubar.

Despite my fair share of concerns with hand positioning, I tend to use Meta as the main modifier so as to avoid such conflicts since both my keyboards have an acceptable distance between Meta and Shift. Meta is also the default shown in the live Manjaro i3, by the way; it corresponds in the config file to Mod4, whose keycode is Super_L. The system default config file for i3 has Mod1, whose keycode is Alt_L, the left Alt key.

Let’s henceforth call the modifier key MOD for easier reference, regardless of it being Meta or Alt.

bindsymming all the way

Generally speaking, i3 doesn’t have that many keyboard shortcuts, which makes it particularly easy to maintain in terms of key semantics. All keyboard shortcuts can be set with bindsym in the config file, and searching for the word bindsym in it will render 72 results. In practice, however, the number of keyboard shortcuts we should need to remember would lie between 20 and 30, quite the low number.

For keeping this blog post short, I will only talk about keyboard shortcuts available through bindsym, and not other functionality available from the config file.

There are around four different syntax for bindsym.

The first is based on executing a command-line application, typically on the background, and the first example in the default config file.

bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ +10% && $refresh_i3status
bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume @DEFAULT_SINK@ -10% && $refresh_i3status
bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute @DEFAULT_SINK@ toggle && $refresh_i3status
bindsym XF86AudioMicMute exec --no-startup-id pactl set-source-mute @DEFAULT_SOURCE@ toggle && $refresh_i3status

If you have extra volume keys on your keyboard, run xev and press the key, your terminal should likely spout some info, among which resides something like keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume) for the lower volume key. The command bindsym will first read the keysym name shown.

If it is followed by the exec command, the next argument will run the functionality of the given CLI application, which in this case is pactl.

The other exec-based keybindings found on the default config file are as follows:

bindsym $mod+Return exec i3-sensible-terminal, which runs the terminal. I particularly liked the use of the Enter key together with the main modifier key. Enter has quite the semantic possibilities with other keys and is rather easy to type due to its size.

bindsym $mod+d exec dmenu_run, which runs the main application launcher, namely dmenu. This is fairly easy to type when MOD is Alt, but it can be a tad annoying when using Meta, and with such a keycombo you lose the speed and convenience of opening your menu with a single key, which is available on most other DEs.

bindsym $mod+Shift+e exec "i3-nagbar -t warning -m 'You pressed the exit shortcut. Do you really want to exit i3? This will end your X session.' -B 'Yes, exit i3' 'i3-msg exit'", which runs the small i3-nagbar prompt for logging out. I find this to be highly incoherent with the i3 ecosystem. Essentially everything in i3 is keyboard driven, but suddenly, to log out of your system, you have to click a small button on the upper right of your screen to confirm your exit. I understand this confirms user intent for a potentially destructive action, but I don’t effectively see a reason for this user intent confirmation to be mouse-only. The GUI feedback is desirable, but maybe its confirmation could be done with the keyboard too. The i3exit utility (which Manjaro ships by default) is way more suited to i3 I’d say.

Aside from the destructive actions avoidance, this reminds me marginally of how GNOME includes the application launcher at the bottom part of the left-sided dock, which is also an intended design choice. This is so that the user may associate the first icon of the dock with 1, so pressing Meta+1 will run the respective application. This is a consistent confusing aspect of Unity, which has the application launcher at the upper part of the left-sided dock, and so the application opened with Meta+1 is the second in the dock. In addition to that, the application launcher at the bottom necessarily guarantees user intent, and is a design choice that privileges keyboard-driven workflows. I am not particularly a fan of this, but that’s what it is, a design choice.

The next syntax for bindsym would be like these:

bindsym $mod+$left focus left
bindsym $mod+$down focus down
bindsym $mod+$up focus up
bindsym $mod+$right focus right

bindsym $mod+Left focus left
bindsym $mod+Down focus down
bindsym $mod+Up focus up
bindsym $mod+Right focus right

Which is similar to exec, but instead of executing an application the argument immediately after the keys determines the operation desired, or function, to simplify things. In the case presented, MOD+arrow keys will switch the focus to another window in cardinal directions. This is similar to how Plasma has Meta+Alt+arrows.

You see, to explain why this is particularly useful, I’ll have to explain how tiling window managers typically work, at least a bit.

Common DEs use a floating-mode for windows; windows can be placed above each other at any given position desirable, and they may follow the mouse, that is, they’re “allowed to float”. Tiling window managers use tiling for windows; creating new windows automatically places them adjusted on the screen, effectively dividing the screen with automatic window management. This is similar to how you may push a window with the mouse to a screen edge and fix it there.

The advantage of tiling arrangements is their neat organization. Since they are always positioned relative to each window and relative to the screen, their repositioning becomes easy as you don’t need to handle imperfect directions such as those in floating-mode.

It can get quite complicated if you have more than 4 windows in the same screen in your i3 setup, though.

Continuing with the previous bindsyms, another thing of note is that the i3 config file allows for variables, which can be set with… set. Since

set $up l
set $down k
set $left j
set $right semicolon

was already defined (in my case ccedilla instead of semicolon), instructions like

bindsym $mod+$left focus left

will then refer to MOD+j, whereas

bindsym $mod+Left focus left

refers to MOD+left arrow key.

There are several other keyboard shortcuts that follow this syntax:

bindsym $mod+Shift+$left move left
bindsym $mod+Shift+$down move down
bindsym $mod+Shift+$up move up
bindsym $mod+Shift+$right move right
, and their respective arrow key equivalents for moving a window to a given direction in your screen, including between screens.

bindsym $mod+h split h, which will make the creation of new windows always open horizontally, that is, one immediately to the side of the other, and bindsym $mod+v split v vertically, that is, each window is tiled one above/below the other.

bindsym $mod+f fullscreen toggle, which will toggle the fullscreen state of the window.

bindsym $mod+w layout tabbed, which will fuse the titlebar of all windows which follow this layout, effectively bringing all of them into a tabbed interface. It’s particularly effective on laptops. It does not seem to follow the first-letter convention for the sake of being able to type it easily with one hand, it seems. It does make sense with regard to hand positioning considering that w and s fit well with the position of the middle and index fingers.

bindsym $mod+s layout stacking, which will essentially do the same as the tabbed layout, but keeping each titlebar layered one above/below each other. This uses quite some vertical space, but is convenient with applications whose file path names are displayed on each titlebar.

bindsym $mod+e layout toggle split, which changes how two windows are aligned; if it’s aligned vertically, then it will become aligned horizontally, and vice-versa.

bindsym $mod+Shift+space floating toggle, which toggles whether a window will float or tile. This keyboard shortcut is particularly odd in that most keyboard shortcuts involving MOD and Shift can be typed with only the left hand, but this one absolutely requires the right hand, despite its main key being quite close to the modifier, unless MOD is Alt. In addition, MOD will be below Shift and the main key, which is unusual as it’s the only instance where this happens. If the user then attempts to use only the left-most key, the hand positioning becomes quite awkward. This keyboard shortcut must then be executed with the right hand on the main key, Space.

bindsym $mod+space focus mode_toggle, which will switch focus between tiled windows and floating windows. You see, tiling and floating are effectively containerized modes, so if one window is floating and another is tiled, MOD+arrows is unable to switch between them. This keybinding serves to cover this limitation, and it’s semantically fitting with the previous keyboard shortcut.

bindsym $mod+a focus parent and bindsym $mod+d focus child are quite peculiar. As windows can also be grouped by tiling them in specific positions, the first keyboard shortcut pertaining to parent will transfer focus to a group of windows, which can then be tiled and moved however the user wants, all at the same time, whereas child serves to restore focus to its original state, only giving focus to a single window.

bindsym $mod+Shift+minus move scratchpad and bindsym $mod+minus scratchpad show are apparently more recent additions to i3, and effectively create “minimize” functionality. The first keyboard shortcut sends the selected window to an unaccessible workspace, thus hiding the window from your computer, whereas the latter will bring it back.

There is also the following syntax:

bindsym $mod+Shift+q kill, which unlike the previous two syntax has specific i3 functionality immediately after the keybinding. In this case, it’s simply the order “close immediately/kill this window”. I am not entirely sure it sends a SIGTERM signal to the application so it is closed cleanly, though. It seems to be SIGKILL. This key combination isn’t particularly fortunate if MOD is Meta.

bindsym $mod+Shift+c reload, which will simply reload the config file. This is useful, for instance, if you want to apply your newly-written keybindings immediately to your session. This key combination isn’t as terrible as the previous hand in terms of hand position since a specific position of the left hand can be achieved with the pinky finger on Shift, thumb on MOD and index on C, far less bizarre than with Space, but awkward for exclusive-left-use nevertheless.

bindsym $mod+Shift+r restart, which will effectively restart your entire session without logging out and back in again. As stated in the config file itself, it can be used when upgrading i3 and applying changes immediately, but it may also serve to reload other display elements, such as the bar.

Lastly, bindsym $mod+r mode "resize", which requires some explanation, as it is unique. It assumes the following code prior to execution:

mode "resize" {
bindsym j resize shrink width 10 px or 10 ppt
bindsym k resize grow height 10 px or 10 ppt
bindsym l resize shrink height 10 px or 10 ppt
bindsym semicolon resize grow width 10 px or 10 ppt
bindsym Left resize shrink width 10 px or 10 ppt
bindsym Down resize grow height 10 px or 10 ppt
bindsym Up resize shrink height 10 px or 10 ppt
bindsym Right resize grow width 10 px or 10 ppt
bindsym Return mode "default"
bindsym Escape mode "default"
bindsym $mod+r mode "default"}

This block uses the second type of syntax and, essentially, serves to resize windows. This way, if the user presses $mod+r, this mode activates, and jkl; as well as the arrow keys, Enter and Esc will do different things from what they usually do. Arrow/jkl; keys by themselves will resize both the width and height of the currently selected window in 10 pixel increments, whereas the remaining keys serve to escape this mode.

The last syntax we’ll see now actually comes in another block of various keyboard shortcuts, and all of them pertain to workspace navigation. Namely:

set $ws1 "1"
set $ws2 "2"
set $ws3 "3"
set $ws4 "4"
set $ws5 "5"
set $ws6 "6"
set $ws7 "7"
set $ws8 "8"
set $ws9 "9"
set $ws10 "10"
, which sets $wsNumber as Number, but if you’d like to avoid naming each workspace as numbers, Unicode is available here in-between parenthesis. The keybinding still corresponds to each respective number, though. That can be done, for instance, with set $ws 1:WhateverNameYouWant.

bindsym $mod+1 workspace number $ws1
bindsym $mod+2 workspace number $ws2
bindsym $mod+3 workspace number $ws3
bindsym $mod+4 workspace number $ws4
bindsym $mod+5 workspace number $ws5
bindsym $mod+6 workspace number $ws6
bindsym $mod+7 workspace number $ws7
bindsym $mod+8 workspace number $ws8
bindsym $mod+9 workspace number $ws9
bindsym $mod+0 workspace number $ws10
, which switches to a specific workspace according to their number regardless of whether they were already created or not.

bindsym $mod+Shift+1 move container to workspace number $ws1
bindsym $mod+Shift+2 move container to workspace number $ws2
bindsym $mod+Shift+3 move container to workspace number $ws3
bindsym $mod+Shift+4 move container to workspace number $ws4
bindsym $mod+Shift+5 move container to workspace number $ws5
bindsym $mod+Shift+6 move container to workspace number $ws6
bindsym $mod+Shift+7 move container to workspace number $ws7
bindsym $mod+Shift+8 move container to workspace number $ws8
bindsym $mod+Shift+9 move container to workspace number $ws9
bindsym $mod+Shift+0 move container to workspace number $ws10
, which moves a given window to a specific workspace. These here for some reason use several words for its function, that is, “move container to workspace number”. Not anything particularly special with this syntax, and could arguably be said to be the same as the second syntax presented here, but it’s a bit different regardless.

Those are all very easy to understand. However, I must note a few things about workspaces in i3.

Workspaces are created dynamically, but not like DEs like GNOME. While GNOME is a 1D environment in which every new workspace gets added dynamically at the end of the axis (the bottom-most one), and each workspace is assumedly assigned a position according to the point of origin (the top-most one), i3 does not care about the position between workspaces themselves, but about their number and their respective screen.

Perhaps dynamic isn’t the most suitable word. On-demand should be more fitting? By default, i3 comes with 10 workspaces already enabled, but your access to them changes depending on your input.

To make things more clear: let’s say we have a computer with GNOME and the user currently has three workspaces: the first one being the top-most and has a window in it, the second comes immediately afterwards and also has a window in it, the third comes immediately afterwards and is empty, being the bottom-most workspace. Opening a new window in the third workspace should create a fourth one; a new window in the fourth workspace creates a fifth workspace, and so on. Every workspace is created in relation to the previous one, and can be assigned numbers according to which one came before which one. This works like so on the main monitor, whereas any other monitor won’t change workspaces.

In i3, if you have two screens, the main monitor on the left and the secondary monitor on the right, by default the main monitor contains workspace 1 and the secondary monitor contains workspace 2. If focus is on the main monitor and we move directly to workspace 3, then workspace 3 will appear immediately to the side of 1 on the main monitor, so we have 1 · 3. Moving to workspace 1 without doing anything will then delete workspace 3, as it’s empty. If we then transfer focus to the secondary monitor and move to workspace 8, then workspace 8 will appear immediately to the side of 2 on the secondary monitor. So we have 2 · 8.

It is perfectly possible to have completely random combinations such as 1 · 3 · 6 · 0 on the main monitor and 2 · 4 · 5 · 7 · 8 · 9, for instance. Each workspace number absolutely must be organized in ascending order, however, as it would be particularly cumbersome for users to keep track of workspaces otherwise.

I would call it a 1D environment, perhaps, in that each screen would have one horizontal axis, but that would have to be disregarding its numeration and displacement in relation to the keyboard sequence of numbers from 1 to 0, which is typically followed through in other 1D environments. Perhaps naming this category a Non-sequential 1D environment would be more fitting, and the previously seen 1D DEs would be Sequential 1D environments.

Another interesting thing is that, by not being sequential while at the same time using numbers for moving between workspaces, i3 manages to avoid use of cardinal directions, thus confining cardinal directions to switching focus and confining numbers to workspaces. This also forces workspace movement to be done with both hands, which differs significantly from i3’s main left-handed focus.

Conclusion

Well, generally speaking i3 is quite the unusual beast compared to the DEs analyzed in this series. Mostly because it’s simply a Window Manager and not a full-blown Desktop Environment, but also due to the way it handles workspaces.

Like GNOME, i3 keyboard shortcuts should be considered contextually, that is, in accordance with how the environment is set up. It is a particularly interesting case study, so to speak, but as far as navigation keyboard shortcuts go, it seemingly cannot be applied to Plasma, a 2D and 3D environment which necessarily uses cardinal directions for navigation. There are however several interesting ideas that i3 provides and could be implemented in Plasma if deemed appropriate, but that is for another time.

That is to say, I see several issues with hand positioning in many instances, and i3 does not always follow the same semantic scheme for defining keyboard shortcuts, but it does so rather well, and I’d say it’s a very well-made keyboard-driven environment.

It is also highly focused on using the left hand for them, with little use of the right hand, which is not approved in several available studies on RSI, which suggest using both hands so as to distribute strain—but then again, from what I researched, studies properly verifying the validity of using only one hand instead of two and vice-versa are either nonexistent or scarce. I didn’t find any systematic review evaluating this subject in particular either, but I’m not an ergonomics specialist nor am I a Physical Therapist. So there’s the benefit of the doubt there, I suppose. Regardless of using one or two hands, if you want to actually choose one, you should be consistent in doing so.


Kubuntu 19.04 Disco Dingo was released on April 18, 2019 with 9 months support. As of January 23, 2020, 19.04 reaches ‘end of life’. No more package updates will be accepted to 19.04, and it will be archived to old-releases.ubuntu.com in the coming weeks.

The official end of life announcement for Ubuntu as a whole can be found here [1].

Kubuntu 19.10 Eoan Ermine continues to be supported, receiving security and high-impact bugfix updates until July 2020.

Users of 19.04 can follow the Kubuntu 19.04 to 19.10 Upgrade [2] instructions.

Should for some reason your upgrade be delayed, and you find that the 18.10 repositories have been archived to old-releases.ubuntu.com, instructions to perform a EOL Upgrade can be found on the Ubuntu wiki [3].

Thank you for using Kubuntu 19.04 Disco Dingo.

The Kubuntu team.

[1] – https://lists.ubuntu.com/archives/ubuntu-announce/2020-January/000252.html
[2] – https://help.ubuntu.com/community/EoanUpgrades/Kubuntu
[3] – https://help.ubuntu.com/community/EOLUpgrades


This week should have a little something for everyone. We’ve got bug squashing galore in preparation for Plasma 5.18, substantial speed improvements for wifi connection and Discover launch time, some welcome new features, and the return of an old one–renaming files from the context menu in file dialogs.

New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

If you’ve got artistic talent, rev up your digital paintbrushes and try your hand at getting your work seen by millions of Plasma LTS users for years to come in our wallpaper competition: https://community.kde.org/KDE_Visual_Design_Group/Plasma_5.18_Wallpaper_Competition!

More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.


January 11, 2020

My Lavalamp

For our living room, I wanted to create a new lamp which isn’t as static as most other lamps, something dynamic but nothing too intrusive.
I was also interested in individually addressable led strips for quite some time, so I started prototyping in last year’s late summer. In december, I finished this project, and called it lavalamp after the classic decorative lamp with rising blobs of fluid which was invented in the 60s.

Lavalamp Show

The lamp uses LEDs for its lighting, there are 576 individually addressable LEDs used, which shine in four directions. The lamp can produce dynamic patterns and effects. There’s a web interface I can use to change its effect, but it also reacts to its surroundings, steered by Home Assistant, my home automation platform of choice. This means that the lamp is automatically switched off when we go to bed, leave the house or want to watch a movie. It can also be voice-controlled.

Material

The ESP8266 microchip running the LEDs

The lamp’s electronic components are an ESP8266 microchip and WS2812b addressable leds. (This means I can change the color and brightness of every single LED individually.) I’ve written custom firmware for the microcontroller (you can find it on my github page), it basically runs a small webserver on its Wifi interface, offering configuration data in JSON format to a mobile-friendly JavaScript application which can run in a browser on your phone. The LEDs are driven by the FastLED library, which is a fantastic piece of software offering fast mathematical functions and low-level data protocols to manipulate the LEDs in my lamp.
With this setup, I achieve 50 frames per second for most of the effects that I’m using in the lamp, so the animations all look smoothly and feel quite natural. I think that’s really impressive, given the rather low specs of the microchip and its price point at around 2€.

The case of the lamp has a wooden foot, sitting around a concrete block which holds the lamp firmly in place and provides some isolation in case anything goes wrong in the electronic parts. The light from the LEDs is diffused through frosted glass, giving it a nice glow.

Building the lamp was a fun project. I didn’t give myself a deadline, but rather took all the time I needed spread out over a period of four months to get all the individual parts in place. I had to learn quite some new tricks, which made this project really interesting. From cutting and building the wooden case to soldering and programming the microchip. In the end, I’m really happy how the lamp turned out. It brings live into our place, while usually not being too distracting.
For further improvements, I built a USB port into the foot of the lamp, so I can just plug in my laptop and add new effects or tweak existing ones.
I’m not quite done with it yet, I want to improve the existing effects on the lamp further, but I’ll also probably build a separate unit that analyses the music playing in our living room to make the lavalamp music-reactive.


conf.kde.in is back in 2020

Just a few more days and I’ll be off to India – Delhi – to attend conf.kde.in at the Maharaja Agrasen Institute of Technology.

Announcement poster for Calamares talk It’s been ages since I last saw Shantanu, and many of the other speakers are new to me. I’m particularly interested in the Malayalam angle presented by Subin Siby, for one thing because the Malayalam translation of Calamares is a work of art.

I’m presenting a few things at the conference – something about Calamares, and also something about using Transifex. Getting good translations for Free Software products is an important thing for making that Free Software available to the next billion Free Software contributors. (The “next billion” is something I’ll credit Samson Goddy and the Open Source Festival with; I dream of speaking there some day as well.)

The conference schedule is somewhat relaxed, so I expect to spend lots of time either sitting and hacking with attendees, or coming up with impromptu sessions on other topics. For season of KDE there are a couple of projects related to Rocs (a graph theory IDE) which I’m mentoring, and there’s always room for more work, more enthusiastic users.

Since there’s lots of different things happening at conf.kde.in, the start of this week, before flying, is basically filled with downloading all the things to my new Slimbook and polishing presentations.

This trip is supported by KDE India and KDE e.V., the organizations that support the KDE community in India and worldwide.


The first revision of the digiKam Recipes book in 2020 is here, and it packs new content. The latest version of digiKam features the Healing Clone tool, and the Remove dust spots and imperfections with the Healing Clone tool part explains how to use this supremely useful feature. Starting with digiKam 6.4, you can use external RAW processing engines, and the Process RAW files with UFRaw part provides information on how to work with RAW photos using the UFRaw tool.


January 10, 2020

Current state-of-the-art in KDE-FreeBSD land is that we’re all up-to-date, almost. I updated sayonara and except for Quaternion I’m all set. Quaternion has a bunch of releases after 0.0.9.4 which are all tweaks on the AppImage or FlatPak versions, not on the actual application.

Zanshin was briefly removed from FreeBSD ports because the last release isn’t compatible with current KDE Frameworks and Akonadi releases, but both Debian and openSUSE have suitable patches (some from upstream) to get it working.

KDE Frameworks 5.66 were released today, and we don’t have those yet. 5.65, though, that’s in.

Along with Qt 5.13.2, KDE release service 19.12.0 (the .1 came out two days ago, also too-soon), KDE Plasma 5.17.5 (four days old), KDevelop 5.4.4. All of that is up-to-date. Looking at the KDE Planet we’re missing the latest Kdenlive (one day old) and KTimeTracker as well. Oh, and GCompris! So I suppose you could call the FreeBSD ports tree, with respect to KDE products at least, a rolling release.

For kicks, I made a VirtualBox applicance with the latest KDE stuff installed, and a working X server and SDDM login. Exported, with the full disk (the virtual disk is 16GB), it is a 8GB image (so I won’t be sharing it; probably I should zero out the disk beforehand). If you start it up, you have a complete KDE development environment – konsole, kdevelop, git, cmake, clang, the works – at your fingertips, with ZFS for snapshots so you can even just build-and-install to the system itself for testing (and then roll back if it screws up).

I think it’s under-represented, but for KDE applications development where the platform is abstracted away, where the important thing is current Qt and current KDE Frameworks, FreeBSD is a wonderful platform to work on. Packaging always delivers the development environment for that package with it. Complete tooling is installed out-of-the-box (and then ports adds clang 8.0 and clang 9.0 so you have modern and picky compilers as well). Building any KDE application is a git clone, cmake and make away. It doesn’t matter that underneath you have ZFS and a stricter POSIX-compliance model than on other systems, since the user/application level is the same.

(For the curious, the appliance is just the product of my instant-workstation script, applied to a fresh FreeBSD 12.1 installation.)


Kdenlive 19.12.1 is out with many bug fixes and usability improvements. For the whole 19.12 release cycle we will continue focusing on polishing the rough edges in preparation the next major release in April.

 

 

  • Adjust clip borders. Commit.
  • Ensure we don’t insert thousand separator in number conversion, and only send integer coordinates on keyframe import. Commit.
  • Better qml interface scaling. Commit.
  • Update Copyright year to 2020. Commit.
  • Use project name as default render name. Commit.
  • Fix transparent rendering. Commit.
  • Fix extract zone (improve ffmpeg arguments and drop locale specific seconds conversion). Commit. See bug #411970
  • Dont’ put colon in cut clip names. Commit.
  • Add select all in bin. Commit.
  • Fix extract zone. Commit. See bug #411970
  • When a clip is dropped in bin, focus on it. Commit.
  • Fix timeline seeking not reflected on effect stack. Commit.
  • Update Appdata version. Commit.
  • Fix duplicate track compositing on project opening and broken opacity with background. Commit.
  • Fix fades offset. Commit.
  • Default to QtAngle for Windows. Commit.
  • Fix proxying of slideshow clips. Commit. See bug #415448
  • Fix possible crash in effectstack. Commit.
  • Small adjustments to timeline fades ui. Commit.
  • Don’t show unsupported effect groups in UI (causing crash). Commit.
  • Minor improvement to show clip in project bin. Commit.
  • Cleanup & fix titled background distorted. Commit.
  • Fix timeline clip duration not updated after clip reload. Commit.
  • Make title widget smaller. Commit.
  • Fix crash creating proxy on clip with subclip. Commit.
  • Fix crash caused by incorrect group saved. Commit.
  • Fix possible crash on group move (no >= in std::sort). Commit.
  • Fix monitor audio thumbnail disappearing on proxy disable. Commit.
  • Fix default font size and color for first start. Commit.
  • Make sure drag mode doesn’t persist when switching to icon view. Commit.
  • Fix clip losing thumb/length on profile switch. Commit.
  • Fix loop zone broken regression. Commit.
  • Don’t unnecessarily trigger timeline thumbnail reload. Commit.
  • Fix tests. Commit.
  • Fix tests. Commit.
  • Fix empty i18 warnings on startup. Commit.
  • Fix various 1 frame offset issues in monitor and zone handling. Commit.
  • Use new syntax. Commit.
  • Fix timeline preview not invalidated when disabling effect. Commit.
  • Fix timeline preview not disabled on render. Commit.
  • Immediatly pause when switching between play forwards/backwards. Commit.
  • Don’t use active track tag to indicate muted tracks, instead fade its clips. Commit.
  • Fix saving project with several clip groups selected discarded those groups. Commit.
  • Rename KDE_APPLICATIONS_VERSION to RELEASE_SERVICE. Commit.
  • Fix missing clips erased from timeline on opening project. Commit.
  • If clip resize not sticking to start/end. Commit.
  • Optimise group move (don’t attempt a track move if not possible). Commit.
  • Use const &values for clip/composition sorting on group move. Commit.
  • DOn’t attempt to load empty data as JSon. Commit.
  • Update qml headers for Qt 5.11. Commit.
  • Fix playing clip monitor seems to pause a few frames before end and seeking allowed past clip end. Commit.
  • * Fix model insert/delete track, so we don’tneed to reset view, makes these operation much faster. Commit.
  • Update master appdata version. Commit.
  • Update screenshots. Commit.
  • Disable assert Catch test failing on some systems. Commit.
  • Replace icon view “back” button with an “Up” icon in bin toolbar. Commit.
  • Fix playhead disappeared. Commit.
  • Adjust rendering threads for faster rendering. Commit.
  • Add flatpak nightly manifest. Commit.
  • Fix freeze on Windows switching monitor. Commit.
  • Remove debug. Commit.
  • Cleanup seeking logic, get rid of confusing blue bar indicating real MLT position, pause on seek. Commit.
  • Fix default audio mixer size. Related to #429. Commit.
  • Fix minor typo. Commit.
  • Deprecate old normalize audio (volume based) in favor of loudness. Commit.
  • Better startup layout for smaller screens. Commit.
  • Fix dragging favorite effect to master. Commit.
  • Fix drag from monitor. Commit.
  • Fix curve parameter after introducing odd only possibility. Commit.
  • Don’t show monitor audio overly for clips with no audio. Commit.
  • Fix handling of dock widget title bars. Commit.
  • Fix composition description not appearing in info box. Commit.
  • Fix some UI strings todo. Commit.
  • Fix undocked widgets losing title bar. Fixes #368. Commit.
  • Expose luma options in dissolve composition. Commit.

January 09, 2020

The year is 2020, we are living in the future, let’s see what KDE apps has brought us in the last month!

KTimeTracker ported to KDE Frameworks 5

The long-awaited modernized version of KTimeTracker is finally released.
The application is a personal time tracker for busy people which is now
available on Linux, FreeBSD and Windows. Over the course of 2019 it had been
ported to Qt5 and KDE Frameworks after being unmaintained since around 2013.


KTimeTracker

The new version is also polished and slightly modernised with the most
noticeable new features being the new Task Time Editing dialog and
live preview in the Export dialog as seen in the picture below.


Export dialog in KTimeTracker

https://download.kde.org/stable/ktimetracker/5.0.1/src/
It is available through your Linux distro or as a Windows installer and there’s even untested MacOS builds built nightly.

The release is announced in the blog of the maintainer Alexander Potashev

KStars 3.3.9

Astronomy program KStars got new features in 3.3.9.

Images can have fine changes in Shadows, Midtones, and Highlights allowing the faintest of stars to be seen.

Alternative constellations from the Western Sky Culture which is fascinating to read about.

Western Sky Culture

KStars is available for Android, Windows, MacOS, Snap store and from your Linux distro.

Common Frameworks - KNewStuff

Here on the Apps Update we focus on the apps rather than coding libraries. But new features in the common libraries will mean new features in all your apps :)

This month saw a redesigned UI for KNewStuff, the framework to download addons for your applications. The browse and download dialog was redesigned and the comments section can now be filtered. It’ll be appearing in all your apps and settings modules shortly starting with the Global Theme module in System Settings.

Filters on Comments

Redesigned Browse Dialog

Bugfixes

KDevelop’s monthly bugfix update 5.4.6 fixed a longstanding problem where the GPL and LGPL headers were mixed up, grab it from your distro or Appimage to make sure your licencing is correct.

Latte Dock 0.9.7 fixed some features with Qt 5.14 and removed some crashes.

Dolphin Plugins 19.12.1 fixed a broken SVN Commit dialog.

There was improved file indexing in Elisa. It also fixed some compilation issues on Android and without Baloo.

The new release of KPat was declaired to have no OARS relevant age restrictions.

Okular fixed a crash when closing the print preview dialog.

This month’s release of Kdenlive video editor had an impressive number of fixes best of all was updating the screenshots used in the meta info. It also has dozens of improvements and fixes in timeline and preview handling.

New JavaScript support is now in Kate’s LSP client.

Enjoy KDE on the Flathub Store

KDE is embracing all the app stores. We can now deliver more and more of our programs directly to you the user. One of the leading app stores on Linux is Flathub which uses the FlatPak format.

You may well already have Flatpak and Flathub configured on your system and ready to use in Discover or other app installers. For example KDE neon has set it up by default on installs for over a year now. If not it’s a quick setup process for all the major distros.

If you’re interested in the techy details you can browse KDE’s Flatpak packaging repo and read the KDE Flatpak guide.

But probably what you’re interested in is the apps so take a look at what the Flathub store has under KDE.

KDE on Flathub

LabPlot now on Chocolatey

Chocolatey is a package manager for Windows. If you want full control over what software is installed on your Windows machine or whole office of machines then Chocolatey gives you easy control over that just like you are used to on Linux.

LabPlot is KDE’s app for interactive graphing and analysis of scientific data and it is now available through Chocolatey. Give it a try!

LabPlot blog

LabPlot on Chocolatey

Website Updates

The recently revived KDE Web Team has been updating a bunch of our older themed sites. The newly relaunched KPhotoAlbum website is a lovely example, updated and refreshed for our photo storage and search app.

And if you want to show off a simple to use but full featured local music player but were ashamed by the old looking website, JuK has just had an updated website too.

New KPhotoAlbum website

Releases 19.12.1

Some of our projects release on their own timescale and some get released en-masse. The 19.12.1 bundle of projects was released today and should be available through app stores and distros soon. See the 19.12.1 releases page. This bundle was previously called KDE Applications but has been de-branded to become a release service to avoid confusion with all the other applications by KDE and because it is dozens of different products rather than a single whole.


The year is 2020, we are living in the future, let’s see what KDE apps has brought us in the last month!

KTimeTracker ported to KDE Frameworks 5

The long-awaited modernized version of KTimeTracker is finally released. The application is a personal time tracker for busy people which is now available on Linux, FreeBSD and Windows. Over the course of 2019 it had been ported to Qt5 and KDE Frameworks after being unmaintained since around 2013.


KTimeTracker

The new version is also polished and slightly modernised with the most noticeable new features being the new Task Time Editing dialog and live preview in the Export dialog as seen in the picture below.


Export dialog in KTimeTracker

https://download.kde.org/stable/ktimetracker/5.0.1/src/ It is available through your Linux distro or as a Windows installer and there’s even untested MacOS builds built nightly.

The release is announced in the blog of the maintainer Alexander Potashev

KStars 3.3.9

Astronomy program KStars got new features in 3.3.9.

Images can have fine changes in Shadows, Midtones, and Highlights allowing the faintest of stars to be seen.

Alternative constellations from the Western Sky Culture which is fascinating to read about.

Western Sky Culture
Alternative constellations

KStars is available for Android, Windows, MacOS, Snap store and from your Linux distro.

Common Frameworks - KNewStuff

Here on the Apps Update we focus on the apps rather than coding libraries. But new features in the common libraries will mean new features in all your apps :)

This month saw a redesigned UI for KNewStuff, the framework to download addons for your applications. The browse and download dialog was redesigned and the comments section can now be filtered. It’ll be appearing in all your apps and settings modules shortly starting with the Global Theme module in System Settings.

Filters on Comments
Filters on Comments
Redesigned Browse Dialog
Redesigned Browse Dialog

Bugfixes

KDevelop’s monthly bugfix update 5.4.6 fixed a longstanding problem where the GPL and LGPL headers were mixed up, grab it from your distro or Appimage to make sure your licencing is correct.

Latte Dock 0.9.7 fixed some features with Qt 5.14 and removed some crashes.

Dolphin Plugins 19.12.1 fixed a broken SVN Commit dialog.

There was improved file indexing in Elisa. It also fixed some compilation issues on Android and without Baloo.

The new release of KPat was declaired to have no OARS relevant age restrictions.

Okular fixed a crash when closing the print preview dialog.

This month’s release of Kdenlive video editor had an impressive number of fixes best of all was updating the screenshots used in the meta info. It also has dozens of improvements and fixes in timeline and preview handling.

New JavaScript support is now in Kate’s LSP client.

Enjoy KDE on the Flathub Store

KDE is embracing all the app stores. We can now deliver more and more of our programs directly to you the user. One of the leading app stores on Linux is Flathub which uses the FlatPak format.

You may well already have Flatpak and Flathub configured on your system and ready to use in Discover or other app installers. For example KDE neon has set it up by default on installs for over a year now. If not it’s a quick setup process for all the major distros.

If you’re interested in the techy details you can browse KDE’s Flatpak packaging repo and read the KDE Flatpak guide.

But probably what you’re interested in is the apps so take a look at what the Flathub store has under KDE.

KDE on Flathub

LabPlot now on Chocolatey

Chocolatey is a package manager for Windows. If you want full control over what software is installed on your Windows machine or whole office of machines then Chocolatey gives you easy control over that just like you are used to on Linux.

LabPlot is KDE’s app for interactive graphing and analysis of scientific data and it is now available through Chocolatey. Give it a try!

LabPlot blog

LabPlot on Chocolatey

Website Updates

The recently revived KDE Web Team has been updating a bunch of our older themed sites. The newly relaunched KPhotoAlbum website is a lovely example, updated and refreshed for our photo storage and search app.

New KPhotoAlbum website

And if you want to show off a simple to use but full featured local music player but were ashamed by the old looking website, JuK has just had an updated website too.

Releases 19.12.1

Some of our projects release on their own timescale and some get released en-masse. The 19.12.1 bundle of projects was released today and should be available through app stores and distros soon. See the 19.12.1 releases page. This bundle was previously called KDE Applications but has been de-branded to become a release service to avoid confusion with all the other applications by KDE and because it is dozens of different products rather than a single whole.


January 09, 2020. Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE’s release service.

Today they all get new bugfix source releases.

Distro and app store packagers should update their application packages.

Press Contacts

For more information send us an email: press@kde.org.


January 08, 2020

What’s XMPP’s biggest problem? - Accessibility!

Sure, it is accessible for the people who are really interested in XMPP or want to be more secure, but the normal user doesn’t want to study XMPP before they know what to do.

That’s why we work on an easy-to-use registration, which makes all decisions for a new user, but still ensures the highest possible security and decentralization. This means that even the password is randomly generated (it is changeable later on). In the end it only takes a few clicks to get to your new account, which is hosted by an automatically chosen public server which supports all of Kaidan’s features.

The user may choose to use the suggested server, username and password or to use own values. So, now switching from your old messenger to Kaidan (or other XMPP-based clients) is much easier. Therefore, you can invite your friends to XMPP and instantly start chatting with them.

Our aim is to make XMPP more accessible for everyone.

This is our first step towards that goal.

So, here is a quick look at the new registration that will come in Kaidan 0.5.0:

At first, you’re asked whether you already own an account or want to create a new one. If you have an own account, you can log in manually or by scanning a QR code which contains your credentials. After that, the user is asked whether the (automatic) “9-seconds-registration” should be used or the manual registration.

If you choose the automatic registration, in most cases you only need to solve a CAPTCHA and you’re done.

If you choose the manual registration, you can enter a display name and choose a server which is also randomly pre-selected. If it is possible, the server is selected depending on your system’s country settings. In the next step, Kaidan generates a username for you by alternating vowels and consonants but you are free to choose an own one.

The next step is choosing a password. If you don’t enter a password yourself, Kaidan will generate a secure one for you. It is changeable at any time. Depending on the server, the last step might be to enter further information or to solve a CAPTCHA. And then you can start chatting! If you only want to chat like with the dominating chat services and don’t care about the server, username or password, your choice is the automatic registration. It takes only nine seconds to start chatting. If you want to choose an own server, username or password like you can do with most XMPP clients, the manual registration is for you. No matter which way you choose, you will be ready for chatting without any hassle.

The registration is fast and simple, perfect for new users!

If an account is not used anymore, it can be deleted from the client and server too.

The presented features are not part of Kaidan yet, but will come with the new Kaidan 0.5.0.

All choices are depicted by cool cliparts, making it clearer what happens when you press any button. Special thanks to MBB, who made those cliparts.


The Libre Graphics Meeting (LGM) is the annual international convention for the discussion and development of free and open source graphics software.

This year it will happen in Rennes, France, from May 26th to 29th. We are welcoming all relevant projects to submit a proposal for a talk and/or a workshop. We already expect Krita and Kdenlive teams to be present. The Krita sprint will be held after the meeting and Kdenlive are planning to have a sprint around that time too. It would be awesome to also see some people from Plasma team working on graphics tablet support and color management, or any other topic of interest for developers and users of graphics creation application.

LGM are now asking for talks, workshops, BoF meetings and lightning talks for the conference. Please don't be shy and submit your proposal.

KDE e.V. has agreed to support the event by providing travel support to KDE contributors. If you are interested, make sure to file your reimbursement request before January 31st.


LGM 2019



A fully functional Plasma desktop with a Windows 7 theme.

Microsoft will stop providing updates for Windows 7 on January 14 2020.

There won't be any more patches that correct bugs or even dangerous vulnerabilities. This will leave Windows 7 users exposed to all sorts of bad stuff. But that is not a huge concern for Microsoft. With this move, Redmond hopes to encourage users to upgrade to Windows 10.

But why should we care? Maybe because Windows currently holds 77% of the global desktop market share (all Linux desktops combined hold less than 2%). Of that 77%, nearly 30% belongs to Windows 7. That is nearly a billion people still holding on to Windows 7 because they are resisting the move to Windows 10. Apart from the natural human resistance to change, Windows 10 has earned a bad rap as an operating system that will gladly leak your data back to Microsoft and lace your desktop with intrusive advertisements as a matter of course.

Helping people regain control over their systems and protecting their data is precisely what Free Software communities do best, making this the perfect opportunity to help Windows 7 users upgrade to something much better: To the Plasma desktop!

How you can help

We need you to help convince Windows 7 users to move to the Plasma desktop. We have set up a task where we are brainstorming ideas, advice and resources. You can contribute your thoughts too. Get your KDE Identity today and join the conversation.

You can also join the Promo team live on Matrix and help us run this campaign.

Or fly solo! Talk to your friends, family, classmates and colleagues. Even if you convince just one person to make the transition to any Linux-based system, you will have done something valuable and helped the FLOSS movement.


The Windows 7-like theme shown above was put together (from many parts created by many generous contributors) by Dominic Hayes, creator of Feren OS, a cool-looking Ubuntu-based Linux distro aimed squarely at end users. Check it out!

Dominic used the following elements to re-create the look and feel of the desktop:

Plasma Theme: Seven Black
Window Decorations: Seven Black
Application Style: gtk2
GTK Theme: Windows Se7en by Elbullazul
Icons: Darkine
Colours: Breeze Light
Cursors: DMZ White
Splash Screen: Feren OS
Panel: 38 height
Widgets: Default Apps Menu, I-O Task Manager, Stock System Tray, Feren Calendar or Event Calendar, Win7 Show Desktop


January 07, 2020

Except if you lived under a rock, you might have noticed that we’re in 2020 now. I thought it would be a good point in time to write a retrospective blog about 2019 (although I admit it touches sometimes on years before 2019 for context reasons). Expect something somewhat less KDE centered than usual (although it will of course talk a fair bit about KDE). Since I don’t want to bore everyone to death and to try to keep that post short, I will cover what I consider the four big topics of 2019.

Health Issues

You found me less active lately? Well… there’s a reason for it, since the end of 2018 I got some health issues and it massively spilled over 2019 as well. It all started with a pneumonia in October 2018. I never felt sicker in my life, it was really excruciating and immediately derailed all the plans I had post-Akademy 2018. After I recovered I spent a full year getting sick around once a month. Even a small cold would badly degenerate and put me on my knees. Rather unpleasant, but kind of expected since you’re apparently fairly immunosuppressed for a year after a pneumonia.

It led to me attending Akademy 2019 without even presenting anything (the first time ever!) because a) I needed to take it more relaxed than usual and b) I didn’t really have much to talk about. And what happened a couple of weeks after Akademy 2019? Another pneumonia… and they say lightning never strikes twice the same place. Of course it took some time to fully recover again.

So far it looks like things calmed down though, I got the usual seasonal cold without it getting out of control unlike previously. Hopefully it’ll stay like this for the coming months and I’ll be my usual self in 2020 again. I hope to churn at least some more work to have something to show at Akademy 2020, we’ll see.

Switching Jobs

I jumped into my first job unrelated to public research right after my PhD. I worked there for something which looked like a couple of weeks… I blinked… and I stayed there more than eleven years! I don’t regret it of course, it was a nice space for growth, I learned a lot and hopefully became expert in a couple of specific fields.

Still, after so many years, either I kept digging in the same expertise fields and probably would do so for the remaining of my career, or I would try something different. That was the main reason for leaving for another mother ship. I had a few interesting contacts and in the end I joined enioka Haute Couture.

It is still services but the positioning is very different. Instead of aiming at being a company expert into a couple of technical fields, it’s aiming at being best in class to help customers be in control of their own developments. On most projects, this means being involved in the very early phases of the project when the technical stack is being picked. It also means helping the people we work with to grow and making sure they master the tools and techniques necessary to the project success.

It’s really awesome so far, I’m really enjoying it a lot. As far as technology is concerned I’ve learned a tremendous amount of new things in a very short time:

  • improved quite a bit my Python skills;
  • discovered Typescript;
  • worked with 3D engines in the browser;
  • reviewed GraphQL APIs and making recommendations around them;
  • and much more!

Obviously this means I’ve been doing a lot of work both on the server side and the client side (both rich clients and web clients). After years working almost exclusively on Qt based rich clients, this is really exploring more ground.

Interestingly, I end up doing more mentoring than before both for our internal and customer needs which replaces nicely my former trainer role. It’s still about teaching but in a very different setup, I enjoy it quite a bit as well.

And last but not least, the enioka Haute Couture team is Free Software friendly which means we’re also pursuing projects which are helpful to communities we like. As an example, you might have noticed we became active around KDE lately (both as patrons and contributors). There is some other work and discussions around FOSS going on too, but that’s less directly relevant to KDE.

Finding My Place in KDE

Talking about KDE, I started working with the community in 2003… it means that during the next spring I’ve been around for a whooping 17 years! I’ll never beat someone like David Faure at the “oldest dino still around” contest but that starts to be a very respectable number of years I guess. Of course, on such a long period of time I added roles or changed roles several times.

The two most demanding projects I ever undertook were facilitating the creation of the KDE Manifesto and the transition from kdelibs to KDE Frameworks. Add to that that both happened around the same time (although one ended earlier) and I can tell you that around 2015 I was very much burnt out. That’s in part why I decided to focus only on Zanshin for a while, but had troubles to sustain even this.

I thus took kind of a longer break which got extended due to my son being born. As I was finally coming back to ramping up again on Zanshin and started my work on Community Data Analytics (more on that below), that’s when the first pneumonia kicked in (see above) ruining all my efforts to keep my pace.

And then end of 2019, we started talking about Qt 6 and KDE Frameworks 6… that’s my chance to somewhat come back. I’m not at full capacity yet, but as you might have noticed I participated in the KF6 Kickoff Sprint, I’m helping with the organizational work and reporting about progress. So let’s say for now I’m having a light stewardship role in KDE Frameworks. That’s a good area to keep in touch and do more, in particular through my new job as hinted at above.

Of course I’m not loosing hope doing more in Zanshin again and resuming my Community Data Analytics explorations. We’ll see what 2020 brings on that front.

Community Data Analysis on Hold?

As I mentioned earlier in this post, my Community Data Analytics explorations didn’t progress much during the past year. Well, it’s only partly true. My series of posts and the public exploration of communities have been on hold for the past year indeed. That being said, a lot has been happening in the shadows!

It turned out that the scripts and methods I was using for my posts were very useful for enioka Haute Couture as well. Remember I mentioned we were present in early phase of projects to select the technology stack? Well, if you lean toward several potential FOSS solutions to your problem, it’s actually not a bad idea to get a feel of the community health in order to choose. For instance, all other factors being equal, I’d choose the solution with the stronger community over the one with the marketing hype.

And of course, since we get a lot of freedom at enioka Haute Couture and since ComDaAn (the set of scripts I use) are useful, we decided to have an intern working on ComDaAn for a few months. In the end, we’ve been very lucky and got a really good intern. She did a tremendous job on ComDaAn for the past few months I’m really glad we had her. She finished her internship on the last day of 2019 but I’ll have another post here (hopefully soon) covering in part what she did with us.

Onwards And Upwards

So as we can see, the past 18 months or so haven’t been all perfect but they also brought their share of (sometimes unexpected) goodness. It’s life I guess, somewhat chaotic… but with nice opportunities too if you look for them. I’m wondering what 2020 will bring!


The number of bugs has risen to 457 as it was a vacation season. Also, Dmitry is on parental leave, so the increase is quite normal. As Boud is back from vacation, he is sharing his time between, bug fixing & triaging and administration stuff.


While the concept of multithreading may be straightforward, code with threads is responsible for some wicked bugs, which can be nearly impossible to reproduce or track down. This makes writing bullet-proof code using threads a tall order. Let’s look a little deeper into why that is.

First, you need better than average knowledge about the internals of your frameworks, language, and compiler to know how to avoid threading trouble-spots. Second, you need to know about synchronization primitives and appropriate design patterns so you can create multi-threaded code that operates correctly under all conditions. And finally you need to understand how to use debugging tools with multiple threads to be able to find those tricky to reproduce issues that are inherent in multithreading bugs.

When it comes to Qt and multithreading, it’s especially true that you need to know your framework and design patterns. Qt gives you the power to make amazing multithreaded apps – as well as shoot your foot off. We’ve honed our multi-threading expertise over the years by finding and fixing threading bugs in both the Qt framework and Qt client code. Here’s a short list of our top rules for avoiding the most common pitfalls to have your Qt apps run right the first time:

1. Never call QThread::sleep()

Although there’s an API to allow your thread to sleep, that is QThread::sleep() – if you’re calling it you should really consider an event-driven design. By changing “threads that sleep” into “threads that wait for events” (or, better all, no threads at all), you’ll save a huge amount of system resources that are otherwise wasted by idle threads. QThread::sleep() is also bad for timing since the amount of time it takes before control is returned is poorly constrained. Sleeping threads can also theoretically cause problems during application termination; foreground threads can prevent the application from terminating until they awake, while background threads may never reawaken, preventing clean finalization.

2. Never do GUI operations off the main thread

Qt’s GUI operations are not thread safe, so non-main threads cannot safely perform any GUI operation. That means no widgets, QtQuick, QPixmap, or anything that touches the window manager. There are some exceptions: GUI functions that only manipulate data but don’t touch the window manager can be called on secondary threads, things like QImage and QPainter. Be careful though, as classes like QBitmap or QPixmap actually are not safe. Check the documentation for each API: if you don’t see a note at the top of the documentation saying that the function is reentrant, it’s not safe to be called except from the main thread.

3. Don’t block the main thread

Don’t call any function that can block for an unspecified amount of time on the main thread (like QThread::wait()). Since these functions stop the main thread from running, all event processing halts and your UI freezes. If you wait long enough, the OS application manager will think your app is frozen and ask the user if they want to kill it – not cool. Both are recipes for an unfriendly app.

4. Always destroy QObjects on the thread that owns them

Qt isn’t designed to allow you to destroy a QObject from any thread that doesn’t own it. That means that before a QThread is destroyed, all QObjects that the thread owns need to be destroyed first. Failing to clean up properly can cause data integrity issues, like the ever popular memory leaks and/or crashes.

How do you ensure the correct thread is the one destroying your QObject? Either create it as an automatic variable inside the QThread’s run() method, connect QThread::finished() to QObject::deleteLater(), or delay the destruction by moving the QObject to another thread with moveToThread(). Note that once you move a QObject away from the thread that owns it, you cannot touch it any more using that thread; you must use the new thread that owns the object.

5. Don’t trust your intuition when it comes to synchronization

A very common design pattern is that one thread signals its status to a monitoring thread, usually by writing to a boolean state variable that the monitoring thread can poll. With a data structure of a single word, only one thread writing to it, and only one thread reading it, it seems like this situation wouldn’t actually require concurrency protection since the read is guaranteed to happen eventually, right? Actually, even this simple case isn’t safe.

The C++ standard says that thread synchronization is mandatory and anything outside of the specification can result in undefined behaviour. If you’re not synchronizing – even in a “simple” case – you’re asking for trouble. In fact, some serious bugs have been found in the Linux kernel, in situations exactly as described here. The best thing to do is to not overthink what is safe or not – if there are concurrent accesses to the same data from multiple threads, no matter how unlikely they are to cause problems, protect them with appropriate synchronization mechanisms.

6. Act as if QObject is non-reentrant

A reentrant function means that as long as different threads are dealing with different data, it can be safely used without synchronization. The Qt documentation indicates that QObject is reentrant, but there are many caveats to this re-entrancy:

  • Event-based classes aren’t reentrant (timers, sockets, etc.)
  • Event dispatching for a given QObject happens in the thread it has affinity with; this can cause races within Qt if you touch the object from another thread
  • All QObjects in the same parent/child tree must have the same thread affinity
  • You must delete all QObjects owned by a thread before deleting the QThread
  • You can only call moveToThread() on an object from the thread the object has affinity with

To avoid all of these special cases, it’s usually easier to just act as if QObject isn’t reentrant. In practice, this means that you should only touch a QObject on the thread that owns it. This will keep you out of all the non-obvious corner cases that can cause trouble.

7. Avoid adding slots to QThread

Because QThread objects have affinity to the original thread that created them and (perhaps unintuitively) do not have affinity to themselves, this causes issues when trying to use signals and slots on a non-main thread. Although a design where a non-main thread uses a slot can be done, since it needs to side-step a lot of non-obvious gotchas our recommendation is that you just avoid this design.

If you don’t need to override QThread:run(), then don’t subclass QThread at all; just create an instance of it and you’ll avoid problems with slots (see links at the end of this blog post for my talk for how to do this with workers).

8. Use standard library threads if it’s more natural

Finally, both the C++ standard library as well as other third party libraries have a wide array of threading classes that aren’t part of Qt – parallel algorithms, coroutines, latches, barriers, atomic smart pointers, continuations, executors, concurrent queues, distributed counters, and the like.

Qt’s multi-threading capabilities are still better in some cases: for example, Qt has thread pools while the C++ standard still does not. The good news is that the C++ classes are all compatible with Qt and can be freely incorporated into your code. In fact, unless a thread manipulates QObjects and you must use Qt threads, either C++ or Qt threading classes can be used depending on what you prefer.


If you liked this short summary, you may want to watch my full QThread talk given at QtCon or see my presentation slides on this topic. These delve much deeper into the reasons behind these rules, as well as providing code samples for the dos and don’ts.

About KDAB

If you like this blog and want to read similar articles, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post The Eight Rules of Multithreaded Qt appeared first on KDAB.


About my Qt times, and a Qt for Python voice assistant

I spent a short time @Qt, but a fruitful one. I was lucky to work with the great Qt for Python team that made me feel very welcomed. I was also lucky to have had a great mentor, Cristián Maureira-Fredes, that was super supportive and cool to work with.



Older blog entries