Subscribe to Planet KDE feed
Planet KDE - http://planetKDE.org/
Updated: 21 min 29 sec ago

Almost Bionic

Thu, 2018/09/20 - 12:12pm

Maybe it’s all the QA we added but issues kept cropping up with Bionic.  All those people who had encrypted home folders in xenial soon found they had no files in bionic because support had been dropped so we had to add a quirk to keep access to the files.  Even yesterday a badly applied patch to the installer broke installs on already partitioned disks which it turns out we didn’t do QA for so we had to rejig our tests as well as fix the problem. Things are turning pleasingly green now so we should be ready to launch our Bionic update early next week. Do give the ISO images one last test and help us out by upgrading any existing installs and reporting back.  Hasta pronto.

 

Qt 5.11.2 Released

Thu, 2018/09/20 - 10:07am

Qt 5.11.2 is released today. As a patch release it does not add any new functionality, but provides important bug fixes, security updates and other improvements.

Compared to Qt 5.11.1, the Qt 5.11.2 release provides fixes for more than 250 bugs and it contains around 800 changes in total. For details of the most important changes, please check the Change files of Qt 5.11.2.

The recommended way for getting Qt 5.11.2 is using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal (commercial license holders) or from qt.io Download page (open source).

Offline packages are also available for those who do not want to use the online installer.

The post Qt 5.11.2 Released appeared first on Qt Blog.

Let’s Tally Some Votes!

Thu, 2018/09/20 - 8:41am

We’re about a week into the campaign, and almost 9000 euros along the path to bug fixing. So we decided to do some preliminary vote tallying! And share the results with you all, of course!

On top is Papercuts, with 84 votes. Is that because it’s the default choice? Or because you are telling us that Krita is fine, it just needs to be that little bit smoother that makes all the difference? If the latter, we won’t disagree, and yesterday Boudewijn fixed one of the things that must have annoyed everyone who wanted to create a custom image: now the channel depths are finally shown in a logical order!

Next, and that’s a  bit of a surprise, is Animation with 41 votes. When we first added animation to Krita, we were surprised  by the enthusiasm with which it was welcomed. We’ve actually seen, with our own eyes, at a Krita Sprint, work done in Krita for a very promising animated television series!

Coming third, there’s the Brush Engine bugs, with 39 votes. Until we decided that it was time to spend time on stability and polish, we thought that in 2018, we’d work on adding some cool new stuff for brushes. Well, with Digital Atelier, it’s clear that there is a lot more possible with brushes in Krita than we thought — but as you’re telling us, there’s also a lot that should be fixed. The brush engine code dates back to a rewrite in 2006, 2007, with a huge leap made when Lukáš Tvrdý wrote his thesis on Krita’s brush engines. Maybe we’ll have to do some deep work, maybe it really is all just surface bugs. We will find out!

Fourth, bugs with Layer handling. 23 votes. For instance, flickering when layers get updated. Well, Dmitry fixed one bug there on Wednesday already!

Vector Objects and Tools: with 20 votes, Text with 15 votes and Layer Styles, with 13 votes (4 less than there are bug reports for Layer Styles…): enough to show people are very much interested in these topics, but it looks like the priority is not that high.

The remaining topics, Color Management, Shortcuts and Canvas Input, Resource Management and Tagging, all get 8 votes. We did fix a shortcuts bug, though… Well, that fix fixed three of them! And resource management is being rewritten in any case — maybe that’s why people don’t need to vote for it!

Akademy 2019

Wed, 2018/09/19 - 12:33pm

DSC00064.JPG

I had the awesome opportunity to attend Akademy in Vienna this year. First off, a big thank you to the organising  team for pulling off this years Akademy without a hitch.

This Akademy was a bit more special, since it was decided to switch up the format, which in my opinion worked quite well. There were training’s that ran alongside the talk’s and BoF’s, which I think was a great idea. I signed up to the Public Speaking Training and the Non Violent Communication training, which I think were run exceptionally. I hope that these training sessions are run again next Akademy because I found them exceptionally valuable.

I also used this opportunity to sit down with TL Lim from Pine64 to discuss the needs of the Pine64 community and how KDE and Pine64 could work together to provide a great experience on Pine64 products such as Pinebook. This eventually led to the release of the KDE Neon image for the Pinebook in the past week, which everyone seems to be quite happy about ��

Overall, I’d say this was a very productive Akademy for me personally, and I thoroughly enjoyed it.

How I Got Involved in KDE

Wed, 2018/09/19 - 12:30pm

Since this blog is starting after the beginning of my contributions to KDE, the first few regular posts will be explaining my prior contributions, before moving into the present.

Continuity, right?

I’d also like to outline how I got involved in development, as an entry-level/non-programmer. I hope this will be helpful for those interested in helping, but unsure how to go about doing something useful.

Konqui_dev_close_cropped.pngI was introduced to the idea of developing for KDE by Nate Graham and his Usability & Productivity goal. I was immediately drawn to the idea of polishing the applications, like I stated in my first post. But how do I get started? I mean, besides the technical stuff. How do I find something easy to work on? I’m not a programmer by trade, so while we do have the Junior Jobs, a lot of those seemed out of my reach. So what to do?

One of the Usability & Productivity posts from Nate mentioned icons being added to the menus in an app. I looked at the linked code that was changed, and noticed how simple it was! I can do that! So I searched through the Junior Jobs, and Phabricator (KDE’s development and code review platform) for applications that needed some icons added to their menu. I found some tasks, and set to work:

Check out the screenshots in those links! Here is an example:

It really makes the app look nicer, right? If you scroll down in those pages and look at the code changes, you will see they are basically simple one-liners that are copy/pasted from elsewhere, with a different icon name. Easy!

You could help do easy tasks like this too!

Visit KDE’s Get Involved page for more information, or contact me!

Multiboot Pinebook KDE neon

Wed, 2018/09/19 - 11:26am

Recently a KDE neon image for the Pinebook was announced. There is a new image, with a handful of fixes, which the KDE Plasma team has been working on over the past week and a half.

Photo of Pinebook

Pinebook running KDE neon

Here’s a picture of my Pinebook running KDE neon — watching Panic! At the Disco’s High Hopes — sitting in front of my monitor that’s hooked up to one of my openSUSE systems. There are still some errata, and watching video sucks up battery, but for hacking on documentation from my hammock in the garden, or doing IRC meetings it’s a really nice machine.

But one of the neat things about running KDE neon off of an SD card on the Pinebook is that it’s portable — that SD card can move around. So let’s talk about multiboot in the sense of “booting the same OS storage medium in different hardware units” rather than “booting different OS from a medium in a single hardware unit”. On these little ARM boards, u-boot does all the heavy lifting early in the boot process. So to re-use the KDE neon Pinebook image on another ARM board, the u-boot blocks need to be replaced.

I have the u-boot from a Pine64 image (I forget what) lying around, 1015 blocks of 1024 bytes, which I can dd over the u-boot blocks on the SD card, dd bs=1k conv=notrunc,sync if=uboot.img of=/dev/da0 seek=8, and then the same SD card, with the filesystem and data from the Pinebook, will boot on the Pine64 board. Of course, to move the SD card back again, I need to restore the Pinebook u-boot blocks.

Photo of a dusty circuit board

KDE neon Pinebook edition running on a Pine64, with console output

Here’s a picture of my Pineboard (the base is a piece of the garden fence, it’s Douglas pine, with 4mm threaded rods acting as the corner posts for my Pine64 mini-rack), with power and network and a serial console attached, along with the serial console output of the same.

The nice thing here is that the same software stack runs on the Pine64 but then has a wired network — which in turn means that if I switch on the other boards in that mini-rack, I’ve got a distcc-capable cluster for fast development, and vast NFS storage (served from ZFS on my FreeBSD machines) for source. I can develop in a high(er) powered environment, and then swap the card around into the Pinebook for testing-on-the-go.

So to sum up: you can multiboot the KDE neon Pinebook image on other Pine64 hardware (i.e. the Pine64 board). To do so, you need to swap around u-boot blocks. The blocks can be picked out of an image built for each board, and then a particular image (e.g. the latest KDE neon Pinebook) can be run on either board.

New KDE.ru website

Tue, 2018/09/18 - 1:47pm

Today, on September 18th, 2018, the Russian-speaking KDE community launches its updated website on KDE.ru.

The new website serves as the main page for the Russian-speaking community. It provides localized information about the community, product download links and the list of social network pages we maintain. It is also meant to help new members get involved in KDE’s projects, particularly in our translation and promotion efforts.

The website was created by me and Alexander Potashev on top of @JBBGameich‘s work for plasma-mobile.org. It uses Jekyll and is now hosted on official KDE servers. It replaces the old forum that has significantly lost its users in the past years.

If you like our work, please share the website with your friends and subscribers! �� If you find mistakes, report them in VK group messages, contact me or open a Phabricator revision with a fix.

We would like to thank Ben Cooksley for his help with website deployment, all the users who participated in beta testing, and everyone who helped polish the content.

Let’s take this bug, for example…

Tue, 2018/09/18 - 10:37am

Krita’s 2018 fund raiser is all about fixing bugs! And we’re fixing bugs already. So, let’s take a non-technical look at a bug Dmitry fixed yesterday. This is the bug: “key sequence ctrl+w ambiguous with photoshop compatible bindings set” And this is the fix.

So, we actually both started looking at the bug at the same time, me being Boudewijn. The issue is, if you use a custom keyboard shortcut scheme that includes a shortcut definition for “close current image”, then a popup would show, saying that the shortcut is ambiguous:

The popup doesn’t tell where the ambiguous definition is… Only that there is an ambiguous definition. Hm… Almost everything that does something in Krita that is triggered by a shortcut is an action. And deep down, Qt keeps track of all actions, and all shortcuts, but we cannot access that list.

So we went through Krita’s source code. The action for closing an image was really created only once, inside Krita’s code. And, another bug, Krita doesn’t by default assign a shortcut to this action. The default shortcut should be CTRL+W on Linux and Windows, and COMMAND+W on macOS.

Curiously enough, the photoshop-compatible shortcut definitions did assign that shortcut. So, if you’d select that scheme, a shortcut would be set.

Even curiouser, if you don’t select one of those profiles, so Krita doesn’t set a shortcut, the default ctrl+w/command+w shortcut would still work.

Now, that can mean only one thing: Krita’s close-image action is a dummy. It never gets used. Somewhere else, another close-image action is created, but that doesn’t happen inside Krita.

So, Dmitry started digging into Qt’s source code. Parts of Qt are rather old, and the module that makes it possible to show multiple subwindows inside a big window is part of that old code.

/*! \internal */ void QMdiSubWindowPrivate::createSystemMenu() { ... addToSystemMenu(CloseAction, QMdiSubWindow::tr("&Close"), SLOT(close())); ... actions[CloseAction]->setShortcuts(QKeySequence::Close); .... } #endif

Ah! That’s where another action is created, and a shortcut allocated. Completely outside our control. This bug, which was reported only two days ago, must have been in Krita since version 2.9! So, what we do now is to make sure that the Krita’s own close-image action’s shortcut gets triggered. We do that by making sure Qt’s action only can get triggered if the subwindow’s menu is open.

d->close->setShortcutContext(Qt::WindowShortcut); QMdiSubWindow *subWindow = d->mdiArea->currentSubWindow(); if (subWindow) { QMenu *menu = subWindow->systemMenu(); if (menu) { Q_FOREACH (QAction *action, menu->actions()) { if (action->shortcut() == d->close->shortcut()) { d->close->setShortcutContext(Qt::WidgetShortcut); } } } }

That means, for every subwindow we’ve got, we grab the menu. For every entry in the menu, we check whether the shortcut is the same as the close-image action’s short. And if it is, we make sure the menu’s action only registers the shortcut if the menu is open.

Everything old is new again

Tue, 2018/09/18 - 9:26am

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 — certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though)

So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

Paris Art School Looking for Krita Teacher

Mon, 2018/09/17 - 1:30pm

An art school in Paris, France, is looking for a Krita teacher! This is pretty cool, isn’t it? If you’re interested, please mail foundation@krita.org and we’ll forward your mail to the school!

A freelance Krita teacher to learn basics to art school students, Paris 11e. November 2018.

The course has to be mainly in french (could be half in english).
That’s full-days session with differents students group (28 students x 5 classes).

  • The teacher has to have an “statut autoentrepreneur” (french freelance).
  • Price is around 50 euros per hour (6 hours days)
  •  The courses will be on : 5th, 8th, 9th,12th, 13th, 14th, 15th, 16th november 2018
  • It’s mainly about general tools of the software, and how to draw and paint with Krita
    using tablets
  • There are possibilities to work more than this first schedule, later in 2019

Profile: Game artist, Concept artist, digital painter, illustrator… please send your website if interested!

Cherche formateur auto-entrepreneur pour cours de Krita à des étudiants en Ecole d’Art, Paris 11. Novembre 2018.

Le cours doit être majoritairement donné en français, mais anglais partiel possible.
Jours pleins à l’école avec différents groupes d’étudiants (28 étudiants x 5 classes).

  • le formateur doit avoir un statut auto-entrepreneur
  • rémunération autour de 50 euros l’heure (journées de 6 heures)
  • les cours seront les : 5, 8, 9, 12, 13, 14, 15, 16 novembre 2018
  • il s’agit d’apprendre les outils de bases du logiciel, et surtout les outils de dessin et peinture avec tablette
  • Il y a des possibilités futures pour d’autres dates dans l’année 2019

Profil: Game artist, Concept artist, digital painter, illustrateur… merci d’envoyer votre site si intéressé !

kgraphviewer 2.4.3

Mon, 2018/09/17 - 12:16pm

KGraphViewer, your favourite visualiser of .dot files, has a new update.

  • Switch KgvPageLayout to QPageSize for page size handling
  • Avoid double top-level layout in KGVSimplePrintingPageSetup
  • Fix layout of page layout & size dialog
  • Remove unused dependency KIO
  • Fix minor typo
  • Update kgraphviewer docbook
  • Make sure the Graphviz library directories are known to the linker

Thanks to Pino, Michael, Yuri, Berkhard, Ben and translators for their continued gardening of this project.

Git tag v2.4.3a 4ff52f959f03291659db58554901d536356764e2

Tar https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz

GPG Signature https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz.sig

Signed by Jonathan Riddell GPG key fingerprint ‘2D1D 5B05 8835 7787 DE9E  E225 EC94 D18F 7F05 997E’

Facebooktwittergoogle_pluslinkedinby feather

Interview with Alyssa May

Mon, 2018/09/17 - 8:00am
Could you tell us something about yourself?

I’m a graduate of the Kansas City Art Institute, but I’ve since moved back to Northwest Arkansas. When I’m not painting or playing video games, I’m enjoying the great outdoors with my wonderful husband, adorable daughter, and our 8-year-old puppy.

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

I do both! I do freelance work for clients, but I still paint for fun (and for prints).

What genre(s) do you work in?

Primarily fantasy because I love how much room for imagination there is. Nothing is off-limits! While that genre is my favorite, I also do portraiture (mostly pets) and have been dabbling a bit in children’s illustration recently.

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

Dan dos Santos is my absolute favorite artist. His rendering is gorgeous. His color is masterful. There’s a lot that can be learned just by looking at the paintings he produces, but luckily for me and anyone else who looks up to his work, he even shares some of his techniques and professional experience with the world. He works mostly in traditional media, but the concepts that he discusses are pretty universal. As far as digital artists go, I’m very fond of the work of people like Marta Dahlig and Daarken.

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

I think college was the first time that I sat down with a tablet and computer and gave the digital painting thing a go. Before that, though, I had dabbled in some other digital image-making techniques, I was more interested in the traditional stuff like oil paints and charcoal.

What makes you choose digital over traditional painting?

Once I got over that initial transitional hump from traditional to digital I was hooked. There’s no cleanup. You can’t run out of blue paint at just the wrong moment. The undo function is absolute magic. More than anything, though, it’s the control that keeps me working in a digital space. Between layers, history states, and myriad manipulation options, I can experiment without worrying about destroying anything. It’s very freeing and really strips the blank canvas of any of its intimidating qualities.

How did you find out about Krita?

Reddit. It came up in a number of threads about digital painting software. People had a lot of positive things to say about it, so when I felt like it was time to start looking at some Photoshop alternatives to paint in, it was the first one that I tried.

What was your first impression?

I was pleasantly surprised when I launched Krita the first time. The UI was polished and supported high DPI displays. All of the functionality that I was looking to replace from Photoshop CS5 was there—and it had been tuned for painting specifically. I was even able to open up the PSDs I had been working on and transition over to Krita without losing a beat. All of my layers and blending modes were intact and ready rock. Hard to ask for a smoother switch than that!

What do you love about Krita?

Aside from the pricing and the whole thing being built from the ground up with painting in mind, I think my favorite feature is actually just the ability to configure what shows up in the toolbars as much as you can in Krita. I work on a Surface Pro 4, and being able to have all of the functions I need in the interface itself so that I don’t have to have a keyboard in between me and the painting to keep repetitive functions speedy is so great.

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

Really, the brush system improvements in the last big update fixed up basically anything I could have hoped for! The only lingering thing for me probably comes down to a personal preference, but when I choose to save out a flat version of my document while working on a KRA, I’d rather the open document default to saving on the KRA on subsequent saves instead of that new JPEG/TIFF/whatever other format I selected for the un-layered copy.

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

I think the open source nature of it is a big component, but on a daily use basis, the biggest functional difference between Krita and other tools I use (like Photoshop and Illustrator) is that painting is the intended usage. The interface and toolsets are geared entirely toward painting and drawing by default, so doing that feels more natural most of the time.

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

I think my favorite Krita painting so far is my most recent—Demon in the Dark. Out of my work produced start to finish in the program, that one had the most detail to play with and I had a lot more fun balancing the composition. Cloth, smoky details, and the female figure are some of the things I enjoy painting most, and that one included all of them!

What techniques and brushes did you use in it?

There weren’t any particularly fancy techniques or brushes used. I like to keep it simple and sketch out my composition, broadly block in color, then progressively refine, layering in and collapsing down chunks of painting until things are reasonably polished and cohesive. To pull it off, I used my staple brushes (hard round and standard blender) for the brunt of the painting, then some more specific texture build-up brushes for hair, clouds, particles, and the like. A time lapse of the whole process is up on my YouTube channel (https://youtu.be/phPrPgK5DYQ).

Where can people see more of your work?

People can check out my work on my website, www.artofalyssamay.com, or my Instagram, @artofalyssamay. They can also find time lapses of my paintings on my YouTube channel, www.youtube.com/c/AlyssaMay!

Anything else you’d like to share?

Just my thanks to the Krita team for making and sharing such a solid program!

Proposal: .editorconfig files in every KDE Repository

Mon, 2018/09/17 - 7:18am

There’s some discussion on D15383 about the use of editorconfig in our sources, I belive that we should have this little file in *all* of our projects (actually I would put this in *every single project that exists*. This is a small file that handles common code conventions per project, for instance the tab vs spaces thing.

Before adopting it in my company my life was not good: I had to manually change tabs vs spaces in the configuration of kate multiple times a day. Working with python? spaces. working with c++? tabs. And a few projects here have those two files at the same parent-project, after adopting it life is collorfull again.

The linked branch has a working editorconfig, I beg you fellow developer, this will help windows developers, mac developers, vim / emacs developers and visual developers as editorconfig has plugins or is directly integrated in many developer tools.

 

KDE Akademy 2018

Sun, 2018/09/16 - 10:50pm

KDE Akademy 2018

Yeah I am not in the picture, but I was there! You can find me over on the left there, where several of us were cut off �� Akademy was held in the lovely city of Vienna, Austria this year. Hats off to the akademy team for a great job!

This year at akademy I spent much of my time catching up with the Blue Systems team and meeting with the KDE Sysadmin team. I am happy to report Ben Cooksley is real! Due to my flights, I missed the first and last day. It was still a productive akademy. I attended some good sysadmin and KDE Neon BoFs . I also did a bit of volunteering ��

Even though I am mostly packaging for Debian directly these days, KDE Neon is still near and dear to my heart. I hope to be able to merge debian packaging into Neon soon so that we can have better collaboration within the team.

I met with Ben in regards to getting back into sysadmin/CI work. I am working on Appimage tooling for KDE Binary factory to begin. I hope to utilize the craft tooling to make everyone’s lives easier. This of course is on my free time, but do keep an eye out!

https://binary-factory.kde.org/

Despite my shortened akademy, I still am happy with the results. It was great to see everyone! See you again next year!

Latte bug fix release v0.8.1

Sun, 2018/09/16 - 7:55am

Latte Dock v0.8.1   has been released containing important fixes and improvements!


Go get   v0.8.1  from, download.kde.orgor  store.kde.org*

-----
* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E



Fixes/Improvements (v0.8.1)




Two Latte panels in Unity mode using properly the
Unity Ambiance plasma theme


  • Most important fix is the new implementation for multi-screen environments. Frustrated as I was from the previous one I decided to make it more robust. With new architecture onPrimary docks/panels have always higher priority that the explicit ones. That change creates a more consistent behavior with Plasma. 

    At the same time a highly sophiticated code that was messing things has been totally removed. Latte was trying to be too smart and never let you without a taskmanager in a multi-screen environment. That was creating more issues than it was solving. In the future when such case for the user occurs a dialog can appear to ask the user what it would prefer to do.
  • Fixes for plasma theme support:
    -
    draw properly plasma theme panel backgrounds based on the edge that the dock or panel is present, e.g. Unity Ambiance, Nilium
    -
    do not double paint plama theme background when the theme does not contain a shadow
  • Fix previews for grouped windows (follow plasma design for window previews)
  • do not move explicit dock on primary screen
  • consider "not show background" case as full transparency
  • consider preferredSize(s) only for >0 values (case of locked analog clock disappearing at a vertical panel)
  • if there is not any active window at all, dodge set docks should reappear
  • do not crash in wayland when right clicking with touchpad
  • identify maximized window screen differently
  • place correctly a new copied dock in a multi-screen environment
  • enable blur for solid theme panels
  • fix for missing global shortcuts '9' badge
  • support unified or not global shortcuts in case the user does not want to use the Latte unified system for its applets. In master version this can be set separately for every dock/panel from its Dock Settings but for v0.8 you should follow:
    https://github.com/psifidotos/Latte-Dock/wiki/Tips-&-Tricks#q-can-i-disable-unified-global-shortcuts-feature-introduced-with-v08

This week in Usability & Productivity, part 36

Sun, 2018/09/16 - 6:01am

Greetings, KDE-loving humans! This week’s Usability & Productivity is a heavy one in terms of importance. We scored awesome fixes and improvements through the KDE software stack for subjects as varied as Libinput mouse and touchpad device handling, Task Manager icon sorting for LibreOffice, and a snazzy new unified mailbox in KMail. Have a look:

New Features
  • KMail can now display a unified inbox (Daniel Vrátil, KDE Applications 18.12.0):
Bugfixes UI Polish & Improvement

Next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters.

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

Browsing your mail with Rust and Qt

Sun, 2018/09/16 - 12:00am

Let’s write a mail viewer with Rust and Qt. This is another blog about Rust Qt Binding Generator, the project that lets you add a Qt GUI to your Rust code, or if you will, add Rust to your Qt program.

Rust Qt Binding Generator (Logo by Alessandro Longo)Rust Qt Binding Generator (Logo by Alessandro Longo)

Previous blogs about Rust Qt Binding Generator covered the initial announcement, building a simple clock, and making a todo list. Now, I’ll show a bit of how to make a more complex application: an email reader.

But first: Rust Qt Binding Generator takes an unusual approach to bindings. It is not a complete binding from the Qt API to Rust because I think that that is impossible: the C++ Qt API does not have all the safety guarantees that Rust has. So the binding API would be full of unsafe negating a big advantage of using Rust.

Instead, Rust Qt Binding Generator generates a binding for just your code to make your Rust code available to a Qt GUI.

In the first tutorial, we showed a clock. The model shared between Rust and Qt had three simple properties: hour, minute and second. The second blog was about a todo application. There, the model was a list of todo items shared between Rust and Qt.

Getting the code

This time, we move on to a more complex object: a tree.

A mail viewer written with Rust and Qt A mail viewer written with Rust and Qt

We’re keeping with the theme of personal information management and are writing an email viewer. It can read mail from MailDir folders and IMAP servers. It is completely readonly and will not even change the state of your messages from unread to read. I feel comfortable using it on my own mails alongside my real mail programs.

The code is available in my personal KDE space. It requires Rust, Cargo, Qt, CMake, OpenSSL, and ninja (or make). You can retrieve and compile it with

The code is about 2200 lines of Rust and 550 lines of QML. Parsing mails and communicating over IMAP is done by three crates: mailparse, imap-proto and imap.

The shared data model

In an email application there are usually two prominent trees: one shows the email folders and the other shows the messages in the selected folder.

First we model the list of folders. Here is the JSON object from bindings.json that does this.

The type of MailFolders is Tree. Each node in the tree has two properties: name and delimiter. Rust Qt Binding Generator generates Qt and Rust code from this. The Qt code (Bindings.cpp and Bindings.h) defines an implementation of QAbstractItemModel. This is the same base class as in the todo example. This time, it holds a tree instead of a list.

There is also Rust code generated. The file interface.rs is the binding to the Qt code. It defines a trait MailFoldersTrait that the developer needs to implement in a struct called MailFolders.

We’ll discuss some parts of the Rust implementation file.

The implementation should be backed by a structure. There are two structures: MailFolder which represents a node in the tree and MailFolders which contains all the nodes in a Vec and interfaces for communicating with other parts of the program.

In the tree, each node has a unique index. The index is used by Qt to find out information about the node, like how many children (rows) it has or to get out data like the name.

These functions correspond to the C++ virtual functions in QAbstractItemModel.

Doing the work in a thread

The user interface should stay responsive. So intense and slow work like reading and parsing email is done in a separate thread. The user interface starts a thread to do the hard work and sends commands to it via a channel.

When new data is available, the UI needs to update. This must be done by the UI thread. When the processing thread has new data it emits a signal to the UI thread. The UI thread then aquires accesses the data via a mutex that is shared between the two threads.

Communication between GUI and processing threadsCommunication between GUI and processing threads QML for the folders

The Rust-implemented model is used from the QML. The connection between the TreeView and the model is made by the line model: mailmodel.folders. Each node is rendered according to the Text delegate. When the user selects a different folder the model is notified of this by handling the onCurrentIndexChanged event.

TreeView { id: folders model: mailmodel.folders TableViewColumn { title: "Name" role: "name" width: folders.width - 20 delegate: Text { text: icon(styleData.value) + " " + styleData.value verticalAlignment: Text.AlignVCenter } } onCurrentIndexChanged: { //... mailmodel.currentFolder = path; } style: TreeViewStyle { highlightedTextColor: palette.highlightedText backgroundColor: palette.base alternateBackgroundColor: palette.alternateBase } headerVisible: false frameVisible: false } Other parts

The list of folders is one of five object defined in the model. The others are the tree for the message threads in a folder (middle pane in the screenshot above), the current email (right pane), the list of attachments for the current email and an overall object that contains all the other ones. The latter, MailModel, is the initial entry point for the user interface. The user-initiated commands are sent to the processing thread from that overall object.

Trying it out

Create a configuration file for MailDir or IMAP.

The path for the MailDir configuration is the folder that contains .inbox.directory.

and run the code

Concluding

This GUI is built with QML via Qt Quick Controls. One might as well write one with Qt Quick Controls 2, QWidgets or Kirigami. The majority of the code, the Rust code, could stay the same. With the appropriate abstractions one might even use a different GUI framework and still keep the core application logic. Just imagine: KDE and GNOME joined together by Rust.

The Krita 2018 Fundraiser Starts: Squash the Bugs!

Sat, 2018/09/15 - 9:48am

It’s time for a new Krita fundraiser! Our goal this year is to make it possible for the team to focus on one thing only: stability. Our previous fundraisers were all about features: adding new features, extending existing features. Thanks to your help, Krita has grown at breakneck speed!

Squash the bugs!

This year, we want to take a step back, look at we’ve achieved, and take stock of what got broken, what didn’t quite make the grade and what got forgotten. In short, we want to fix bugs, make Krita more stable and bring more polish and shine to all those features you all have made possible!

We’re not using Kickstarter this year. Already in 2016, Kickstarter felt like a tired formula. We’re also not going for a fixed amount of funding this year: every 4000 euros funds one month of work, and we’ll spend that time on fixing bugs, improving features and adding polish.

Polish Krita!

As an experiment, Dmitry has just spent about a month on area of Krita: selections. And now there are only a few issues left with selection handling: the whole area has been enormously improved. And now we want to ask you to make it possible for us to do the same with some other important areas in krita, ranging from papercuts to brush engines, from color management to resource management. We’ve dug through the bugs database, grouped some things together and arrived at a list of ten areas where we feel we can improve Krita a lot.

The list is order of number of reports, but if you support Krita in this fundraiser, you’ll be able to vote for what you think is important! Voting is fun, after all, and we love to hear from you all what you find  the most important things.

Practical Stuff

Practically speaking, we’ve kicked out Kickstarter, which means that from the start, you’ll be able to support our fundraiser with credit cards, paypal, bank transfers — even bitcoin! Everyone who donates from 15 September to 15 October will get a vote.

And everyone who donates 50 euros or more will get a free download of Ramon Miranda’s wonder new brush preset bundle, Digital Atelier. Over fifty of the highest-quality painterly brush presets (oils, pastel, water color) and more than that: 2 hours of tutorial video explaining the creation process in detail.

 

Go to the campaign page!

KDE Itinerary - Static Knowledge

Sat, 2018/09/15 - 9:00am

In the previous post on writing custom data extractors for the KItinerary framework, I mentioned we are augmenting extracted data with knowledge from Wikidata. This post will cover this aspect in more detail.

Static knowledge refers to information that with near certainty don’t change for the duration of your trip, or during a release cycle of our software. That’s things like name, location and timezone of an airport, or the country it belongs to, as opposed to dynamic knowledge like departure gates or platforms, delays, etc.

Use Cases

There’s two main use-cases for static knowledge here:

  • Detecting and translating human-readable identifiers of for example countries or airports into something more suited for machine use. As a human I know ‘Charles de Gaulle’ refers to the main airport of Paris, for the software the IATA airport code ‘CDG’ is much more useful. Similar, we want ISO 3166-1 codes for countries rather than possibly localized human-readable names, and so on.

  • Augmenting or completing partial information. Usually the booking confirmation data we extract doesn’t contain geo coordinates (useful for navigation to/from the airport/station), the timezone (essential for correctly converting arrival/departure times) or the country (needed for our power plug compatibility check), so we need to obtain that from elsewhere.

Data Sources

Currently we are basing this on the following free and open data sources:

Offline Data

One aspect that might be a bit counter-intuitive at first is that we don’t query this information online, but bake it into the program code. This has a number of advantages:

  • Privacy. Your email client would otherwise produce a predictable online access when opening an email containing a travel booking. Even with transport encryption this activity would still be observable on e.g. an open WiFi network, not ideal.
  • Speed. The data is encoded in the shared read-only data section of the KItinerary library, in a way that is directly usable without any parsing or additional memory allocations.
  • Offline support. That’s something quite handy when traveling, as you might be forced into flight mode or are outside of data roaming coverage.

Obviously there are some downsides to this approach as well, but they are comparatively small:

  • Outdated data. You’d need a software update to roll out data changes. This is however why we limit this to “static” data, ie. information that should be stable within one release cycle (3-4 month) with a very high certainty.
  • Size. Obviously this data needs space. It’s however surprisingly little, about 600kB for the localized country name to ISO 3166-1 mapping in KContacts, and about 400kB in KItinerary for the airport and train station databases.
Contribute

There’s an easy way to help in this area too, by improving the Wikidata content. Our code extracting the relevant knowledge from Wikidata is warning about some issues such as missing or conflicting data. These issues are usually easy to research and fix, so that might be a nice entry point into Wikidata editing (it definitely was for me).

Since the data quality is actually very good, the below is the complete list of remaining issues at this point, for the few ten thousand objects we are looking at.

The following airports have two geo coordinates assigned to them that differ by more than 20 kilometers. Few airports are that large, more commonly that’s a simple typo. A quick look on a map is often enough to determine which is the right coordinate.

Similarly, the following airports have no geo coordinate specified:

The list of train stations missing geo coordinates is a bit longer and therefore in a separate file.

A bit more elaborate are the following train stations with IBNR conflicts (an ideally unique station identifier). In the easiest case it’s just two duplicate objects that can be merged, in other cases this might require some understanding on which part of a larger station is actually addressed by the identifier.

And finally there is a more conceptual issue with Gares & connexions IDs for international destinations on SNCF tickets, as described in task T8830.

Browsing your mail with Rust and Qt

Sat, 2018/09/15 - 12:00am

Let’s write a mail viewer with Rust and Qt. This is another blog about Rust Qt Binding Generator, the project that lets you add a Qt GUI to your Rust code, or if you will, add Rust to your Qt program.

Rust Qt Binding Generator (Logo by Alessandro Longo)Rust Qt Binding Generator (Logo by Alessandro Longo)

Previous blogs about Rust Qt Binding Generator covered the initial announcement, building a simple clock, and making a todo list. Now, I’ll show a bit of how to make a more complex application: an email reader.

But first: Rust Qt Binding Generator takes an unusual approach to bindings. It is not a complete binding from the Qt API to Rust because I think that that is impossible: the C++ Qt API does not have all the safety guarantees that Rust has. So the binding API would be full of unsafe negating a big advantage of using Rust.

Instead, Rust Qt Binding Generator generates a binding for just your code to make your Rust code available to a Qt GUI.

In the first tutorial, we showed a clock. The model shared between Rust and Qt had three simple properties: hour, minute and second. The second blog was about a todo application. There, the model was a list of todo items shared between Rust and Qt.

Getting the code

This time, we move on to a more complex object: a tree.

A mail viewer written with Rust and Qt A mail viewer written with Rust and Qt

We’re keeping with the theme of personal information management and are writing an email viewer. It can read mail from MailDir folders and IMAP servers. It is completely readonly and will not even change the state of your messages from unread to read. I feel comfortable using it on my own mails alongside my real mail programs.

The code is available in my personal KDE space. It requires Rust, Cargo, Qt, CMake, OpenSSL, and ninja (or make). You can retrieve and compile it with

The code is about 2200 lines of Rust and 550 lines of QML. Parsing mails and communicating over IMAP is done by three crates: mailparse, imap-proto and imap.

The shared data model

In an email application there are usually two prominent trees: one shows the email folders and the other shows the messages in the selected folder.

First we model the list of folders. Here is the JSON object from bindings.json that does this.

The type of MailFolders is Tree. Each node in the tree has two properties: name and delimiter. Rust Qt Binding Generator generates Qt and Rust code from this. The Qt code (Bindings.cpp and Bindings.h) defines an implementation of QAbstractItemModel. This is the same base class as in the todo example. This time, it holds a tree instead of a list.

There is also Rust code generated. The file interface.rs is the binding to the Qt code. It defines a trait MailFoldersTrait that the developer needs to implement in a struct called MailFolders.

We’ll discuss some parts of the Rust implementation file.

The implementation should be backed by a structure. There are two structures: MailFolder which represents a node in the tree and MailFolders which contains all the nodes in a Vec and interfaces for communicating with other parts of the program.

In the tree, each node has a unique index. The index is used by Qt to find out information about the node, like how many children (rows) it has or to get out data like the name.

These functions correspond to the C++ virtual functions in QAbstractItemModel.

Doing the work in a thread

The user interface should stay responsive. So intense and slow work like reading and parsing email is done in a separate thread. The user interface starts a thread to do the hard work and sends commands to it via a channel.

When new data is available, the UI needs to update. This must be done by the UI thread. When the processing thread has new data it emits a signal to the UI thread. The UI thread then aquires accesses the data via a mutex that is shared between the two threads.

Communication between GUI and processing threadsCommunication between GUI and processing threads QML for the folders

The Rust-implemented model is used from the QML. The connection between the TreeView and the model is made by the line model: mailmodel.folders. Each node is rendered according to the Text delegate. When the user selects a different folder the model is notified of this by handling the onCurrentIndexChanged event.

TreeView { id: folders model: mailmodel.folders TableViewColumn { title: "Name" role: "name" width: folders.width - 20 delegate: Text { text: icon(styleData.value) + " " + styleData.value verticalAlignment: Text.AlignVCenter } } onCurrentIndexChanged: { //... mailmodel.currentFolder = path; } style: TreeViewStyle { highlightedTextColor: palette.highlightedText backgroundColor: palette.base alternateBackgroundColor: palette.alternateBase } headerVisible: false frameVisible: false } Other parts

The list of folders is one of five object defined in the model. The others are the tree for the message threads in a folder (middle pane in the screenshot above), the current email (right pane), the list of attachments for the current email and an overall object that contains all the other ones. The latter, MailModel, is the initial entry point for the user interface. The user-initiated commands are sent to the processing thread from that overall object.

Trying it out

Create a configuration file for MailDir or IMAP.

The path for the MailDir configuration is the folder that contains .inbox.directory.

and run the code

Concluding

This GUI is built with QML via Qt Quick Controls. One might as well write one with Qt Quick Controls 2, QWidgets or Kirigami. The majority of the code, the Rust code, could stay the same. With the appropriate abstractions one might even use a different GUI framework and still keep the core application logic. Just imagine: KDE and GNOME joined together by Rust.

Pages