The OpenUK Awards are now open for nominations.
We are looking for the best in open source, hardware and data in the UK. Who had achieved something great? Who has not been recognised? Which company or project are doing fabulous work that needs exposure?
Nominations are open until 15 June 2020 but don’t delay nominate today 
The awards final will be 20 October 2020 – 6pm, Unilever Building London, either in person or over video as appropriate.
There has been a lot of work into the Maui Project, and the Nitrux team has been actively working on the apps, the framework, and the libraries to make the convergence experience something unique and reliable for our first stable release. Since last time we posted something about the project, many things are refactored, a lot of improvements and UI/UX paper-cut fixes are introduced, and new platforms now have support. We were present at the Plasma Mobile sprint at Berlin, working on improving the Maui apps experience for such a platform. In the sprint, the UBPorts developers were also present, and we are looking forward to seeing the Maui Apps in their platform.
For those who are still not familiar with the Maui Project, let me quickly describe what it is:
A group of technologies aiming for convergence.
We have a set of apps, a UI and UX framework named MauiKit that help us provide a curated experience. We also built upon powerful technologies from the KDE community, like Kirigami, KIO, and others, and work on different platforms, devices, and screen-form-factors: phones, phablets, tablets, 2 in 1, desktops, etc. And we target platforms like Plasma Mobile, GNU/Linux distributions, Windows, Android, macOS, and iOS.
And this summary is to showcase some of the latest changes.
Following our convergence principle, it makes sense to target major platforms so our software can be used across different devices. If you use a Windows PC and an Android phone, it makes sense, for convergence’s sake, that you can use the same app with the same experience on both devices, no matter screen factor, underlying OS, or based input (touch or pointer).
The next step in our plan is to allow syncing the data across all your devices using Maui apps, and that is something in the works, some apps already have this as a preview: Vvave can sync and stream music files and Buho, can sync notes, all you need is a NextCloud server account.
About syncing and so on, we will talk later on when it is more matured, just noticed that it is an essential part of the Maui Project goal. Going back to the cross platforms support, the Maui Apps now supports Mac OS and iOS (partially), with some system integration, features still needed, this expands the support for Windows, Android, and GNU/Linux. These are some screenshots of Index (the file manager), Nota (simple text editor), and Vvave( music player) running on Windows 10, Mac OS, and iOS.
Due to the iOS file system constrains some apps, the experience is more than lacking, but in future updates, it should become more and more usable.
For the convergence experience, we also make use of a style named Maui Style, this style aims to be universal to all the supported platforms, and although it looks good on Android and GNU Linux, it still needs more love for the other platforms.
On platforms like Plasma Mobile and GNU/Linux distributions, this style is not the default one. Instead, MauiKit integrates with the system style. However, for desktop environments like elementary or Gnome, it also makes sense to ship the Maui Style as default and also for cases when the apps are distributed as AppImages.
We have already mentioned that for convergence UX, the apps would need to work for different input based systems, this is a task that MauiKit should take on, so the third-party apps using it don’t have to worry about it. To demo this, let me show you the current state of Index on a GNU Linux desktop environment with pointer input, aka mouse. Index by making use of MauiKit now can support lasso selection, keyboard shortcuts, drag, and drop, multi-selection based on touch or shortcuts, tabs, split views, and more. What does this mean? That you get a powerful file manager in all devices and not a downgraded or lesser version for mobile and better for desktop.
Pix, Vvave, Buho, and Nota have received many updates to make them more useful and feature complete. Pix gallery view is now more fluid and space-aware and supports multi-selection: lasso selection, keyboard shortcuts, and an immersive image viewing experience.
Station now sports multi-tab support and vertical or horizontal split views. Also, for touch-based devices, it has a quick action bar with shortcuts for commons actions.
Nota now has line numbers support, and initial work for search and replace feature is on the works. On desktops, it also can have an embedded terminal, and with syntax highlighting and a sidebar listing the files in a project, it could be used for hacking.
Vvave has an improved focus view, better albums, and an artist’s view, and overall a better UX experience.
The apps updates also benefit all the platforms, in this case, Android. The apps in landscape mode now work correctly and snappy.
In our spare time, we also try new things and ideas. With Qt 5.15, we will have better support for CSD (client-side decoration), and given that the release date is around the corner, we did a quick test with MauiKit to prove support for CSD.
The testing implementation allows themes and styles to set the window controls button icons, and also takes, when possible, the default window decoration style used in the base system, and even picks the right order of the window controls set system-wide.
Make sure to follow Maui Project at https://twitter.com/maui_project. For those looking to make contributions, you’re welcome to join the Telegram group at https://t.me/mauiproject.
We are happy to announce the release of Qt Creator 4.12 RC!
I’m from Switzerland and have studied art and graphic design in 90′.
It’s a hobby but I’m happy to be able to do some commissions for an RPG book lately, and I got several projects to work on in the near future.
My main focus currently are fantasy environments. But I also do character design and love to paint dragons.
There’s many artists I’m inspired by. For example Bierstadt for his romantic landscape. Also all the Russian landscape artists like Schischkin and many more. Frank Frazetta and Möbius. Of course there’s so many other old master artists throughout the history I can’t list them all. I also admire the work of A. Rocha, who is a young artist that has a similar style. There’s so many awesome artists to get inspired by and thanks to the internet it’s easy to see their work.
I think it was in 1997, when I got my first Wacom Intuos2. I didn’t really get into it and had other interests at that time. In 2010 I picked it up again for some portraits I was doing videos of, but lost interest again. It’s only in Feb 2019 where I really started again more serious with a mission in mind.
The flexibility and being able to produce things not possible or very hard in traditional. I don’t have an atelier and the resources to paint traditionally.
Since I was not keen on using Photoshop for painting (even though I worked for many years with Photoshop), I was looking for alternatives. Then I finally found Krita in 2018.
I was surprised, how many features and tools it had. The brush engines are very powerful and the UI seemed intuitive enough.
I love that it’s open source. It has many great tools for various tasks. The ability to create your own powerful brushes. I also love that you can do animations.
Performance can always be improved and it’s a very important one. Though Krita has made some big leaps in that regard. I’m often working on greater resolutions with tons of layers, and it can get somewhat laggy depending on the amount of things you put in.
Stability. There’s some parts where Krita crashes sometimes when it comes to vector tools. Though it’s not its main focus, it’s still annoying when you want to experiment with things and it won’t let you.
It has a great community, not only the users but also the developers are awesome. I was able to chat with a developer (Wolthera) to talk about color management in Krita. The developers care and are putting lots of work into making it a better program.
There’s people like Ramon Miranda who puts a lot of effort into making top notch brushes and cares a lot about the community.
The software lets you do your work and doesn’t get in the way. Easy to use yet very powerful.
I think it has to be my latest painting to date. “The Source“. It was done completely live on stream over 3 days.
It’s heavily inspired by A. Bierstadt and I think I pushed myself a little further (like I try every time on a painting like this)
This one is special as it was done with mainly only the default round brush opaque with size and opaque on pressure.
The technique is somehow comparable to painting in oil. I used a lot of layers while having the background shine through. I switch between painting and eraser a lot.
https://artstation.com/somartist
I want to thank all the people that made Krita possible. You guys are awesome.
I like to tell other artists to try Krita. I hope to inspire other people to do artwork too.
Thank you!
After more than half a year the next release is here, but the waiting was worth it! It includes the all new onboarding, which aims at better usability for new XMPP users and improved security, while minimizing additional effort by the user. For further information look at the blog post dedicated to this topic.
And even more! Now recording and sending audio and video is possible with Kaidan, as well as searching for contacts and messages. Additionally, many smaller features and fixes are included in this release. But have a look at the changelog yourself.
We sadly have to inform you that we encountered difficulties building Kaidan for Windows and building the Flatpak as one option to use Kaidan on Linux. But we are already working on fixing it and Kaidan 0.5 will hopefully be available on Windows and as a Flatpak for Linux soon™.
At the current state, it is possible to show the password with two clicks. That issue is also going to be addressed in the future.
We like to thank the DBJR (German Federal Youth Council) for supporting us financially and technically.
We would be pleased about bug reports, translations and iOS developers and testers (contact us) to help us improve Kaidan.
Features:
Bugfixes:
Notes:
Nightly builds are available on our downloads page as usual.
Some very nice performance fixes landed this week, which should substantially boost move and copy speeds for local transfers and transfers to and from Samba shares in particular. But that’s not all, and there’s more on the menu…
In Plasma 5.19, we are making a push on our Breeze Theme Evolution work. It’s proceeding, but would go faster with your help! There are tons and tons of mockups in the linked task and its child tasks, and what we really need at this point is people willing to help implement them. QML skills are helpful, and C++ is also useful for the needed work on the Breeze theme itself. If this sounds interesting to you, don’t be shy, step right up! Head over to the VDG channel to find out how you can get involved and coordinate work.
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.
Note: acceptable from the perspective of a Tetris fanatic who regularly uses jargon like SRS, lock delay, DAS, ARR, etc. For the casual player, these games are perfectly fine. Albeit, I would recommend Quadrapassel over KBlocks to casuals because of the better rotation.
Errata: I mention that KBlocks can only repeat in one direction. It can actually rotate in both directions, it just breaks the norm with its default keybindings and that confused me.
The board is the wrong size. That's all you need to know to avoid this one.
Besides the incorrect size, Quadrapassel is barely SRS conformant (albeit the rotation handling is much better than that of KBlocks, which I'll get onto in a bit.)
Timing is also way off, with no lock delay, too much DAS, and not enough ARR.
The board is the correct size, but somehow the rotation handling is even worse than Quadrapassel, because pieces rotate around the center of their occupied region and not around the center of the pieces themselves.
There is only one correct rotation method:
Additionally, you can only rotate in one direction.
Like Quadrapassel, timing is off: no lock delay, too much DAS, not enough ARR.
Nullpomino offers one thing hardcore Tetris fans love: absurd fine-tuning. Each and every aspect can be configured, from DAS, ARR, lock delay, etc.
Additionally, there's a ton of gamemodes that exercise every skill a Tetris player can exercise. From plain single-player Tetris to all sorts of specialty training modes to multiplayer, Nullpomino has it all.
Also, Nullpomino is the fan game that you see in Tetris communities.
You can tell that it was made by Tetris fans for other Tetris fans.
Tags: #libre
The beta of Focal Fossa (to become 20.04 LTS) has now been released, and is available for download.
User of Kubuntu, Ubuntu, and other flavours are invited to take part in #UbuntuTestingWeek.
This milestone features images for Kubuntu and other Ubuntu flavours.
Pre-releases of the Focal Fossa are not recommended for:
They are, however, recommended for:
The Beta includes some software updates that are ready for broader testing. However, it is an early set of images, so you should expect some bugs.
You can:
The Ubuntu Focal Fossa Release notes will give more details of changes to the Ubuntu base:
On the last few weeks I’ve been looking at KWin more closely than in the past. It’s definitely a special beast within KDE and I figured it could be useful to give some hints on how to develop and test it.
When developing something, first step is always to compile and get the code installed and usable. It’s especially delicate because when we mess up our system becomes quite unusable so it needs to be done with care. To prevent major damage, we can probably try installing it into a separate prefix (See this blog post, change kate for kwin).
Second step is to make sure that modifying the code will modify the behaviour you perceive. This is what we’ll focus on in this piece.
Bear in mind most of the things I’m saying here are possibly obvious and not news, but it’s still good to have it written in case you feel like building on this (not fun to come up with) experience.
That’s the first that we’ll probably try. It’s simple: we run a kwin_wayland instance within our system, it shows a window with whatever we’re running inside. I find it useful to run a konsole inside to trigger other applications. It’s also possible to point processes run elsewhere to that socket too but I haven’t really come across the necessity.
We’ll run something like:
kwin_wayland --exit-with-session konsole
Or even:
kwin_wayland --exit-with-session "konsole -e kate"
In any case, a good old kwin_wayland --help. The --exit-with-session bit isn’t necessary but it makes it useful to easily close it.
One of the biggest advantages of using it like this is that it’s very easy to run through gdb (just prefix with gdb --args kwin_wayland...), so still something to remember.
This works, but it’s usefulness is limited because important parts won’t be run: input, which will come from the actual session rather than from the kernel; and drm, which will go into the virtual session than to the kernel for the same reason.
TL;DR: if you’re modifying KWin to talk to the kernel, this won’t work.
Next thing to try is to run it separately. Now you’ll want to move to a tty (e.g. ctrl+alt+F2) and run the same command as earlier. Now we’ll run the same code as above. Instead of getting a window now we get it full screen and using DRM and libinput straight from the source. *yah!*
It’s still quite uncomfortable though: the output will be going to the tty which we can’t see because we have kwin on top and if it crashes we’re at a loss. Also running it with gdb is a pain because we can’t interact with it.
That’s why for this I’d recommend to ssh into the system from another one. I’ve found the sweet spot there to use a combination of ssh and tmux (screen should work as well, there’s tons of doc on how to use either online). Using ssh we find 2 main problems: if the connection breaks the whole set up is left in a weird situation and from ssh we don’t really access the tty.
If you don’t have 2 computers available, you can ssh from a phone as well, should be good enough, especially if you can get an external keyboard, although a nice screen is always useful.
So what we’ll do is:
riddell
host$ tmuxothercomputer$ ssh $IPothercomputer$ tmux aAnd then we’re seeing the same on both, and we can run kwin_wayland on either and everything will work perfectly: we’ll see debugs we may be adding, we’ll get to kill it with Ctrl+C if we please, we can run gdb, add breakpoints. Anything. Full fun.
Problem being it’s just KWin and there’s more to life than a black screen with a dancing window.
To start Plasma Wayland from a tty we run startplasma-wayland. This gives us a complete Plasma instance on Wayland. The same as if we were running it from a display manager like SDDM. Running it from another system tmux still has advantages, like we’ll get to see the debug output. Starting a kwin_wayland session under gdb is way beyond this blog post and barely useful considering the standalone approach I mentioned earlier. What we can do though is to attach to the running gdb.
From the other system (on tmux or not, although I find it useful to just put it in another tab) we can run sudo gdb --pid `pidof kwin_wayland` and it will attach. Then you can add your gdb business: breakpoints, make it crash, look at backtraces, print variables or just stare at it hoping things get fixed automatically.
There’re other things that have proved useful to me like running it on valgrind or with a custom mesa build + modified LD_LIBRARY_PATHS. This works as with any other project, except it doesn’t by default.
KWin has a safety system set in place that prevents running it on emulators like valgrind and prevents LD_LIBRARY_PATHS from being tampered with. Which is great in general but prevents us to do certain things.
To address this in our build, we can comment out the code in kwin/CMakeLists.txt where ${SETCAP_EXECUTABLE} is called on kwin_wayland. You’ll need to make sure kwin_wayland is recreated, so remember to host$ rm bin/kwin_wayland. This bit here made me waste a fair amount of hours mind you, so it’s worth keeping in mind.
It’s also worth remembering there’s a ton of debugging tools that can be used. Here’s some:
WAYLAND_DEBUG=1 environment variable to see how the wayland protocols are flowing.Also note that all of this applies for Plasma Mobile as well, where it’s also useful for applications as well, where it’s most convenient since you get a proper keyboard and screen to look at debug output and gdb traces.
Hope this was any useful to you.
Happy hacking, stay safe!
