February 18, 2018

The Machine

The Raspberry Pi3 is a small single board computer that costs around $35 (USD). It comes with a network port, wifi , bt , 4 usb ports , gpio pins , camera port , a display out, hdmi, a TRRS for analog A/V out. 1GB of ran and 4 ~1GHz armv8 cores Inside small SOC. Its storage is a microSd card they are a low cost and low power device. The Touchscreen kit is an 800×480 display that hooks to the Gpio for touch and dsi port for video. To hold our hardware is the standard touch screen enclosure that often comes with the screen if you buy it in a kit.

Raspian?

Most of the time it is sufficant to run Raspian the official distro that is made for the raspberry pi. raspian is a fork of debian as much like debian it has some old packages. Inorder to build AtCore (with the gui) you need at least qt5.8 raspian comes with 5.7. This is not a show stopper but compling qt does take quite some time and can easily take a week if we were to build it on the rpi itself. Setting up a cross complier will save you alot of time but even on my fastest machine it will still take some hours to build qt for the pi. I decided it would instead be faster to install a completely unsupported OS on the device. I was going to install install arch linux on the rpi. Arch is a rolling distro that ships with qt 5.10.

Doubly Unsupported

Arch linux on the raspberry pi is what you might call “doubly unsupported” That is that the raspberry pi foundation does not support running arch on the pi. You only get support from the arch community. Arch Linux is not officially supported on platforms other then x86_64 the rpi running on arm. Worry not for the Arch community has some forks such as archlinux-arm this is what we will be installing. Like most things arch you get some instructions. After getting the os installed its still arch so you only get a cli interface on your first boot and are left to set up the rest of the system.

Post Install

For my system I installed plasma-meta , xf86-video-fbturbo-git and sddm. With those I was able to have a working plasma shell. I also installed dolphin, kate and konsole as well as the few atcore dependencies. I then added my user to the uucp group so I was able to r/w to serial devices and restarted. When all the dependencies are installed you can proceed to build atcore. Since this is arch we can simplify the building part just by using atcore-git from the aur. Im Happy to say it took only 5minutes and 48 seconds to build atcore-git on the rpi. I then used pacman to install the atcore-git pacakage and it was time to see how our gui was looking on such a small screen.

The Result

At first the contents of the atcore-gui spill off the screen due to the way our docks are tabbed, however since they are docks you can just adjust them to make a quick usable interface. After adjusting the gui AtCore worked exactly the same as it does on other systems. Below you can see a picture and video.

Can do better

There is lots of room for improvement. Atcore-gui does not save any settings. You’ll need to move the docks around each time you launch the program. Atcore-gui can not automaticly connect to a device on launch. again for reasons of not saving settings This gui is of course not really made for use on a touch screen and it does seam to work good enough to use. Some non atcore changes on the system itself would be nice. A few services running on the pi would improve this over all. Mjpeg streamer or another method of streaming video from the attached camera on my printers extruder. Uploads are done via stfp thats not always easy for everyone. The pi does not launch atcore-gui on start up . Small stuff like this could easily be adjusted. I was really just playing around to see how atcore ran on the rpi. I was very happy when this worked well.

By supporting me on Patreon, you’re helping me provide the focus, direction, support, and technical contributions that work to turn the KDE software suite into a lean, mean, bug-free productivity machine, and get it distributed well so that our users have great options for getting our software.

Of course, I’m only one man; what really matters is not me, but rather you! KDE’s greatest strength is its passionate community of developers and users, who work tirelessly to develop, improve, polish, promote, and use KDE software. I truly couldn’t do this without all of you, and in fact, I wouldn’t even want to! All of you are the reason why I work so hard on KDE software. Thank you, so very much.

We’ve been focusing like crazy on the Krita 4 release. We managed to close some 150 bugs in the past month, and Krita 4 is getting stable enough for many people to use day in, day out. There’s still more to be done, of course! So we’ll continue fixing issues and applying polish for at least another four weeks.

One of the things we’re doing as well is redesigning the set of default brush presets and brush tips that come with Krita. Brush tips are the little images one can paint with, and brush presets are the brushes you can select in the brush palette or brush popup. The combination of a tip, some settings and a smart bit of coding!

Our old set was fine, but it was based on David Revoy‘s earliest Krita brush bundles, and for Krita 4 we are revamping the entire set. We’ve added many new options to the brushes since then! So, many artists are working together to create a good-looking, useful and interesting brushes for Krita 4.

It’s still work in progress! But we want your feedback. So… Download the new Krita 4 development builds, and start doodling, sketching, painting, rendering… And then tell us what you think:

Apart from the new brushes, and the bug fixes, there’s also news for Linux users: we updated our AppImage build scripts, and the new appimage includes Python scripting and the Touch UI docker. Note: by default all scripts are disabled, so you need to go to Settings/Configure Krita/Python scripts and enable the scripts you want to use.

Help with the release!

We’re having our hands full with tasks like coding, bug fixing, manual updating… More than full! One task that looks like it’s going to slip is creating a cool what-new-in-4 release video. So: if you’re good at creating videos and want to help the team, please join us on #krita on irc.freenode.net and help us out!

Windows

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

Linux

On Linux, you need to download the gmic-qt appimage separately. You can configure the location of gmic-qt in Krita’s settings. Krita requires the “XDG_DATA_DIRS” environment variable to be set. Most distributions do this, but if yours doesn’t, set “XDG_DATA_DIRS” to “/usr/local/share/:/usr/share/” as a workaround. Next build Krita will do this by itself.

This is going to be a double-header: today we’re discussing Discover as well as Kirigami–KDE’s UI framework that facilitates writing convergent apps that look and feel good on both the desktop and a mobile device.

…At least that’s the idea. The truth is, KDE users have voiced a lot of criticism for how well this works out in practice. An especially common complaint is that the desktop user experience gets short shrift, and Kirigami apps feel like big phone apps.

We’ve heard this feedback, and we’re acting on it. Over the past week, we’ve been hard at work to make Kirigami UI components behave more appropriately on the desktop, and have Discover make use of them instead of its custom components.

No more huge header with the picture of the coffee cup that nobody liked! This is not the final appearance; there’s still polish work to be done, and we are heavily iterating over Kirigami to improve it to make the Desktop UI a first-class citizen. But it’s a model for what we’re going for.

We also added some other much-requested user-centric features to Discover, such as making reviews more prominent. Have a look!

Discover now shows the top three reviews right on the app page (KDE bug 380514, implemented in KDE Plasma 5.13):

Discover’s review submission pop-up is now more user-friendly and makes it impossible to accidentally submit a one-star review (KDE bug 390426 and Phabricator revision D10500, improved in Plasma 5.13): Note the presence of a close button! Another much-requested feature for Kirigami pop-ups.

You can now use Discover to write an app’s first review (KDE bug 390339 and KDE Phabricator revision D10476, fixed in KDE Plasma 5.12.1):

Discover’s “show more reviews” button now always shows the correct number of reviews, has slightly better text, and no longer lets you write the first review for apps that you haven’t installed yet (KDE Phabricator revisions D10527 and D10525, Fixed in KDE Plasma 5.13)

Items in app lists now have better top padding, so they don’t touch the header (KDE Phabricator revision D10548)

Improved the metadata for the KDE Nightly Builds Flatpak repo so it has a more appropriate name, in preparation for encouraging our users to try it out (more on that soon…):

Well there you have it. We never stop working on improving Discover, and we really do listen to user feedback. Mark my words, Discover is going to become one of the most-loved Linux software centers, you heard it here first! Help is always appreciated, so feel free to start contributing and making a difference to a project that truly matters. You don’t have to be a programmer to have an impact!

And if you look at my efforts and like what you see, consider donating on Patreon to help me do it full-time, rather than squeezing it in before and after my regular job. With your support, I could bring forth even more for KDE!

February 16, 2018

I was working on adding sounds to Pixel Wheels rescue helicopter, so I started SFXR Qt and after a few experiments I came up with a decent sound. Unfortunately it did not sound that good in the game. It was much more dull than in the app. Listening again to the sound in SFXR Qt I realized there were subtle variations between each plays, which made the sound more interesting.

Initial investigation

At first I was puzzled, how could the sound differ from play to play? After a more thorough code inspection I found the culprit: the noise buffer. When you select a noise wave form, the app generates a 32 item long array of random floats between -1 and 1, and go through it in a "segment" (a sound can be made of multiple segments). When a new segment starts, the buffer is regenerated, causing the sound to be subtly different each time it is repeated.

Let's make it sound dull

I want SFXR Qt sounds to sound like they are going to sound in the game, so I set out to get rid of those variations.

I picked the sound created the first time you click on the "Explosion" generator button as my guinea pig. It sounds like this:

My first fix attempt was to create a long buffer with as many items as there are samples in the sound, and reuse it as the sound was being replayed. That failed: the noise was much more high pitched.

Debugging random noise buffers is hard, or at least, I am not used to working on this kind of topics. One change I made to make behaviors more deterministic was to make the noise buffer generators of both the master branch and my work branch use their own, fixed random seed, separated from the seed used by the generator buttons. This made it possible to compare the sounds generated by running both versions side by side.

I could hear the difference but I was getting nowhere, why did my noise buffer sound differently than the original implementation? And then I had a revelation: the original buffer contains 32 items, and the code using it looks like this:

sample=noise_buffer[phase*32/period];

Where period is the duration of the current segment, and phase is the sample index in the segment.

As you can see, there is no modulo: the noise buffer is stretched to fill the segment. This means that each value in the buffer is used period / 32 times consecutively before the next value is used. Using the same noise values longer means less variations, which translate into lower pitched noises.

Armed with this revelation, I reworked the code to use a fixed 32 item buffer and reuse it between segments. The result was less high pitched, but it was also a lot less noisy:

More head scratching led to the second revelation: reusing the same noise buffer across segments caused the creation of regular waves with a frequency of 1 / period. The buffer needs to contain different values for each segments to avoid creating those low frequency waves.

My third implementation fixed this by creating a list of 32 item noise buffers, one for each segment, and reusing the same list each time the sound is replayed. This finally produced the same result as the original. Victory!

Simplifying

Using a list of buffers worked, but it felt over-complicated. My first simplification attempt was to use one long buffer again, but go through it by slices of 32 items. That worked, but the code was not much simpler.

I eventually came up with a simpler approach: what I needed was a random value generator which returned the same value for period / 32 calls, and which could be reset to produce the same pseudo-random sequence each time the sound restarts. This can be implemented by keeping the last value returned and changing it at the right time. Reproducibility can be achieved by resetting the random seed each time the sound restarts. I implemented this in a NoiseGenerator class:

Back to this helicopter sound

Now that I can trust SFXR Qt to play sounds faithfully, the next step is ironically to make it capable of producing the sound it produced before by accident, but this time in a way which can be used in Pixel Wheels. To do so I plan to add an option to set a number of repeats so that it can generate N times the same sound with noise variations. But that's a story for another week...

Igor Ljubuncic of Dedoimedo is at it again, and has just published a list of high-profile KDE Plasma bugs and papercuts. As a Plasma fan, his intention is to call attention rather than criticize, and I’ve put together a response for every issue he raised. For the full list, scroll down.

Here’s the thing: reporting issues is important. QA is important. Raising awareness of problems is important. But as you’ll see from the list below, nearly every legitimate issue that Igor brings up is already known and tracked in Bugzilla. Many are already fixed, in fact.

The problem is lack of resources, not lack of awareness of issues. Fixing bugs requires developers. And we need more in order to fix them all at the rapid pace that our users expect. We know about the bugs. We want to fix the bugs. But we need your help to do it!

The best way is to start submitting some patches. You don’t even need to know any programming! Here is a non-programming patch I submitted just today, for example. A lot of my patches are utterly trivial in nature, like this one or this one. These are easy fixes; low-hanging fruit. Anyone with some technical knowledge can get started today! There’s a ton of support.

If you want to help propel KDE to the great heights it’s capable of, climb on board!

And now, for the full list, if you dare:

[C] Widget button on the left side is too close to the desktop folders.

[C] Widgets list always opens on the left side, regardless of the button placement.

This isn’t a bug. The widget list can be opened from multiple interfaces; if it always followed the Desktop Toolbox, it would just be inconsistent with something else. Still, we may be able to make some usability improvements: https://bugs.kde.org/show_bug.cgi?id=390575

[C] Wireless icon (when not connected) is too pale and may be mistaken for a gap in the system area in the panel.

[F] Menu session end buttons all have the same result, regardless of what you click on. Whether you choose suspend, reboot or shutdown, you still have a 30-sec timeout screen with the same options presented again. A confirmation is nice, but it should also correlate to the chosen action. Clicking suspend or reboot and then choosing shutdown a few seconds later negates the first choice.

It already does; the action you chose is the one that’s selected in the confirmation screen.

[C] The system menu does not differentiate between several versions of the same application, if installed. For example, the standard repo and the snap version of VLC 3.0 both show exactly the same, and the only way to tell them apart is by the icon (lower-res for the snap), or alternatively, by launching the program to check which version it is.

[F] The order of different versions of the same application as listed in the system menu changes based on usage/launches.

That’s a feature, not a bug. For an app list based on frequency of use, you should expect each version of an app to appear separately and have its own ordering. If you didn’t care about them being separate, you wouldn’t install multiple versions of the same app.

[C] Panel height resize is done using a drag/slider rather than a precise input value. Both options ought to exist, so that both methods can be used. Hand sliding, especially without an external mouse pointer, is tedious and inaccurate.

[C] Default font anti-aliasing settings are sub-optimal in all tests I have performed, including different laptops, with Intel and Nvidia graphics. The system defaults should be set to RGB and slight hinting.

[F] Spectacle does not have an option to remove/disable shadows when taking a screenshot of an active window area. The shadow size also depends on the selected theme – and may be impacted by compositing, which can lead to inconsistent results. It is also not apparent whether there are shadows in created screenshots or not while they are being taken.

[F] Spectacle usage model is complicated – Save & Exit is the same button that opens the preferences menu, and it is not immediately apparent this is the case. It also makes no sense to place the two under the same hierarchy element.

[F] The installation of new themes, icons and other decoration is vague and broken. Sometimes, there are multiple install options that do not clearly signify to the user what they’re installing, and these installations often fail due to misconfigured third-party resources. Even when installed, decorations may not show up in relevant lists due to unlisted incompatibilities. It may take a full session restart (log out, log in) to see the effects of newly applied decorations.

A known issue. This is a big task, too big for a Bugzilla ticket. But it’s on our radar screens.

[F] System customization should include a backup and restore-to-defaults options, including a desktop/system wide configuration, as well as individual options. This may also be realized as preview function, so the users can see what the new theme/decoration will do before it is applied.

[F] Discover seemingly keeps on checking for updates, even though the action is not happening and/or it should have completed already.

This is very distro-specific, and we haven’t seen it in quite a while with recent versions of Discover. Anyone who sees this should file a bug! Just complaining about it isn’t enough; we need for people who experience it to file bugs!. If you want to be QA, then you have to be willing to use the appropriate channels to report issues, or else it’s just noise. See https://community.kde.org/Get_Involved/Bug_Reporting

[F] Discover search results are broken; programs that can be found using the command-line package manager utility do not show in the UI when the same search string is used.

Discover is not a package manager. By design, it only shows packages with AppStream metadata. The goal is that users shouldn’t ever need to do manual package management. If anything ever doesn’t show up in Discover that should, this is the your distro’s fault, but you can help us fix it!

[F] It is difficult to find the option to configure/enable the desktop session restart (X kill), normally activated by the Ctrl + Alt + Backspace combo. There are no less than three different options to configure and use keyboard shortcuts. You have normal and advanced settings, but then you also have the hardware configuration, and it’s the last one that you actually need for this.

This is an advanced feature that shouldn’t be required for normal users during normal use; why would we want to make it more prominent?

[C] There’s no easy way to quickly remove/hide entries in the Dolphin sidebar, except by removing the entire category.

Sure there is:

[C] The list of devices in Dolphin seems random – devices should include both label, device name and size through a configurable setting, and there should be an option to allow the user to sort the devices based on their preference.

[C] The panel clock is too big – full height – while the rest of the system area icons are smaller. The use of the alternative gadget Event Calendar helps, but this should be a customizable option in Plasma defaults.

This is caused by limitations in the kinds of software allowed on iOS.

[F] iPhone/iOS devices will not be auto-mounted in Dolphin; you may need to use a manual configuration to identify and mount them.

Never seen this; my iPhone works fine. A detailed bug report would be helpful here.

[F] The mount prompt in the system area (regardless of the device/phone/camera) type is vague. It offers several mount options, associated with programs, but it does not identify the mount protocol, e.g. MTP or PTP. This only becomes apparent after the device has been mounted and presented in the file manager.

Not a bug; the mount protocol is (or should be) irrelevant to a normal user. No other OS includes this kind of super technical information there.

[F] Media playback (music and video) from Samba shares does not work well. There is no unified approach to how the remote filesystems should be treated, and it is up to individual applications to handle authentication and playback.

[C] Not all media players have system integration, and/or some have their individual icons + media playback button in the system area.

This is entirely up to those media players to conform to the MPRIS spec. Blame them, not us.

[F] Accessibility options are vaguely defined or executed. They should be available out of the box and configured for immediate use, including the lock and login screens.

A legitimate concern. We will investigate this.

[F] Open file dialogs for different applications behave in different ways, including how directory trees and files are displayed. Often, paths and names are truncated, and there’s no standard display method.

These are most often Qt bugs, but still a priority in my list.

The above issues are high-profile and will earn their fixers a lot of praise, and will likely be featured here. So go on and fix some bugs! It’s easier than you think.

In the last post, we discussed a new approach to design time and build time integration of external tools in Visual Studio using MSBuild rules and targets. This will be included in the upcoming release of version 2.2 of the Qt VS Tools. In this post, we will discuss the performance improvements that are also included in this new version.

We’ll focus on two situations where users of the current version (2.1) of the Qt VS Tools have reported sub-standard performance:

Adding new header files, especially to projects with many configurations

Converting Qt projects (.pro files) with many files

We’ll look at the scale of these problems and why they occur, then discuss the steps that have been taken to fix the problems and the improvements that have been achieved.

Adding Header Files to a Project

To understand the scale of this problem and the effectiveness of our solution, we ran the same set of tests using both the current and the new version. These tests consisted of adding several header files containing Qt macros to projects with varying numbers of configurations. For more information on the test setup and a detailed analysis of the results, please refer to the section “Measuring Performance”, at the end of this post.

Looking into the results of testing version 2.1, we found that the time to add files to a project got progressively worse, up to several minutes, the more configurations were defined in the projects. The worst case scenario was just under 45 minutes for adding 10 files to a project with 20 configurations. It was possible to determine that the performance degradation is closely related to the approach previously followed, where files generated by moc were explicitly added to the project in order to be included in the C++ compilation. The time spent modifying properties of generated files accounted for 98% of total time.

As we discussed in the previous post, the new approach based on MSBuild rules and targets allows source files to be added to the build process while it is ongoing. This way, instead of adding the files generated by moc as static project items, they are added dynamically to the C++ compilation during the processing of the moc target. This should represent a significant improvement to the cost of adding new header files to a project. The test results from version 2.2 show that this is indeed the case: the time spent on each test case was, on average, 95% less than that of version 2.1, and what was previously the worst case scenario (10 files added to a project with 20 configurations) now took only 3,2 seconds to complete.

This improvement in performance is not limited to the action of adding header files to projects. It will have an impact in all operations that handle generated files as project items. The following is a list of other use cases that should also benefit from the increase in performance (especially in projects with several configurations):

Importing Qt projects (see next section);

Creating new Qt classes;

Manually adding/removing the Q_OBJECT macro in a file;

Changing the Qt version;

Changing the path to the moc, rcc and uic generated files.

Importing Qt Projects

The problem described above also applies when importing a .pro file, since properties of generated files are also accessed and modified during import; in fact, the import procedure modifies properties of all project files. To avoid this problem, in the new version of the Qt VS Tools, the Visual Studio project that is generated by qmake is not immediately loaded into Visual Studio; all modifications are carried out as an XML transformation on the project file. Only then is it loaded into Visual Studio. This way we avoid any project-wide processing while the project is loaded.

To test this optimization, we imported the Qt example project demobrowser. Below is a recording of this test using version 2.1 (left) and version 2.2 (right) of the Qt VS Tools (the recording also includes building and running the program). We found that the time to import the project decreased from over 30 seconds in the current version to less than 6 seconds in the new version.

Measuring Performance

To measure the scale of the performance problem when adding new header files, we ran a series of tests with an instrumented build of the Qt VS Tools that recorded the number and duration of calls to every function. As the performance seemed to be influenced by the number of project configurations, we tested with several projects containing respectively 2, 5, 10, 20 and 40 configurations. As the number of files added also seemed to be a factor, we tested each project with 5, 10, 20 and 40 files added, for a total of 20 test cases. We will use the variable C to represent the number of configurations, and the variable F to represent the number of files added.

The results of testing with version 2.1 of the Qt VS Tools show that the performance degrades significantly as we increase the number of configurations and the number of files added. The graph below summarizes the test results. Some tests were interrupted after 45 minutes; this is noted in the graph by grayed-out bars. The blue bar on the left serves as a 1 minute scale.

Looking further into the test data, we find that most of the elapsed time was spent calling functions of the Visual Studio SDK. For example, in the test case C=20,F=10, which took almost 45 minutes to complete, 98% of that time was spent in the following calls:

These functions were called while adding generated files to the project – files generated by moc must be added to the project in order to be included in the C++ compilation. For every header file added, one generated file per configuration will also be added to the project, i.e. F×C generated files. In the test case of C=20,F=10, this accounts for the 200 calls, e.g. to the AddFile function.

Each one of the F×C generated files can only be compiled if the corresponding project configuration is active. For all other configurations, the file must be set to “excluded from build”. This is the reason for the larger number of calls to the set_ExcludedFromBuild function, i.e. F×C×(C-1) calls to that function. In the example of the C=20,F=10 test case, this accounts for the 3800 calls to set_ExcludedFromBuild.

We’ve also found that the functions of the Visual Studio SDK tend to become slower as the number of calls increases. In the case of set_ExcludedFromBuild, we see that the average time per call went from 11 milliseconds, when calling the function 10 times, to 535 milliseconds per call for 3800 calls:

With the approach followed in version 2.1, which requires that generated files be added to the project, there doesn’t seem to be much room for improvement in performance: almost all time is spent inside external functions and these functions are called exactly the number of times needed. The problem of the performance degradation seems then directly linked to the approach itself.

To test the performance of the new approach, we ran the same 20 test cases using the new version 2.2 of the Qt VS Tools, which uses the Qt/MSBuild targets; the results are shown in the graph below. As before, the blue bar on the left represents the same 1 minute scale.

Comparing the results of both tests, in version 2.2 the time spent was, on average, 95% less than that of version 2.1. The average cost of adding header files to a project, per file and configuration (i.e. total time divided by F×C), decreased from 300 milliseconds to 40 milliseconds.

On Valentines day TechEmpower released the results of fifth round of it’s benchmarks tests on web frameworks, it took almost a year since round 14 and I really hope round 16 comes out sooner.

Since this round took a long time and was scheduled to be release many times last year I decided not to update Cutelyst to avoid not having the chance to fix any issues and have broken results. Cutelyst 1.9.0 and Qt 5.9 were used, both had some performance improvements compared to round 14, and thus you can see better results on this round compared to 14, most notably the JSON tests went from 480K request/second to 611K req/s, also due this old Cutelyst release jemalloc was again not used due a bug we had in CMake files that didn’t link against it.

In this round some other frameworks also done their optimizations and a few managed to do better than Cutelyst, even though we were faster in all tests compared to the last round. It might be even related to some OS tuning as most results seemed to went up a bit, however if you put the filter on “FullStack” frameworks Cutelyst is leading in most tests.

TreeFrog framework had results in TechEmpower long before I wrote the tests for Cutelyst, but due errors on TreeFrog tests on last rounds this was the first round where you can compare the results of two Qt Web Frameworks.

For the next round I expect the results to be even better now that we will properly use jemalloc, and our epoll dispatcher got a better implementation, I also plan to use Cutelyst 2 and try increasing some buffers as the servers have plenty of RAM that I didn’t care on using.

February 15, 2018

Over the past few weeks, we’ve done a lot of Usability & Productivity work for Spectacle, KDE’s screenshot tool. I’d like to share the progress! But first, a screenshot. Here’s how spectacle looks now:

We’ve been hard at work making Spectacle easier to use and more featureful, and you can see some of those changes in the above screenshot. Here’s the full list of user-facing changes and bugfixes:

The Save button now remembers the last Save mode that you used by default (KDE Phabricator revision D10198)

Removed the confusing and destructive Discard/Quit button (you can still quit the app with Ctrl+Q or the Escape key, or by clicking on the window’s close button (KDE Phabricator revision D10283)

Added a visible “Configure…” button so that you can more easily find Spectacle’s settings (KDE Phabricator revision D10289)

Added a new “Tools” menu button that can hold extra features, and moved “Print” to it. Now the “Save” button finally has only actual Save actions! (KDE Phabricator revision D10371)

Spectacle’s new Tools menu now provides an easy link to your screen recording app if you have one installed, and if you don’t, it suggests a few (KDE Phabricator revision D10295)

Made the main window size itself optimally based on the shape of the screenshot (KDE Phabricator revision D10377):

Spectacle can now be configured to quit after copying the screenshot to the clipboard (KDE bug 389773) – note that you will need to tell Klipper (the clipboard manager) to accept images for this to work. For more information, see the bug report.

Spectacle’s new Tools menu provides an easy way to see where the last screenshot was saved (KDE bug 389695)

Spectacle no longer displays the dreaded “Ambiguous shortcut warning” dialog if you use the same keyboard shortcut twice (KDE bug 389691)

All of these improvements will be available in KDE Applications 18.04.

And we’re not done yet. We’re scoping out work to add an inline image editor/annotator and improve the user experience where you want to use spectacle to quickly take a screenshot and copy it to the clipboard without showing the main window (often for the purposes of pasting it into a chat window). An option to omit window shadows or reduce their size is also in the works.

Spectacle is used by hundreds of thousands or even millions of people, so this work has an impact! It’s a great time to be part of something big. Hop on board, and we’ll work together to continue making everything even better.

Optionally Removing Parentheses in a Macro

This trick is used in the W_PROPERTY and the W_OBJECT_IMPL macro.
The first argument of W_PROPERTY is
a type. Typically: W_PROPERTY(QString, myProperty MEMBER m_myProperty).
But what happens when the type
contains one or several commas, as in: W_PROPERTY(QMap<QString, int>, myProperty MEMBER m_myProperty)?
That's not valid, macro expansion does not consider template and therefore the first argument would be up to
the first comma. The solution is to put the type name in parentheses. The new problem is then how can we ignore parentheses
in the implementation
of the macro.

Let's rephrase the problem with simplified macros. Imagine we want to do a macro similar to this:

// Naive implementation of a macro that declares a getter function#define DECLARE_GETTER(TYPE, NAME) TYPE get_##NAME()// Can be used like thisDECLARE_GETTER(QString, property1); // line A// OK: expands to "QString get_property1()"// But this does not work:DECLARE_GETTER(QMap<QString, int>, property2);
// ERROR: 3 arguments passed to the macro, but only 2 expected// And thisDECLARE_GETTER((QMap<QString, int>), property3); // line B// ERROR: expands to "(QMap<QString, int>) get_property3()"// Can we get rid of the parenthesis?

The question is: How can we implement DECLARE_GETTER so both line A and line B produce the expected result?
Can we get the macro to remove the parentheses.

Let's make a first attempt:

// REMOVE_PAREN will be our macro that removes the parenthesis#define DECLARE_GETTER(TYPE, NAME) REMOVE_PAREN(TYPE) get_##NAME()// Forward to REMOVE_PAREN_HELPER#define REMOVE_PAREN(A) REMOVE_PAREN_HELPER A#define REMOVE_PAREN_HELPER(...) __VA_ARGS__DECLARE_GETTER((QMap<QString, int>), property1);
// OK: expands to "QMap<QString, int> get_property1()"// This worked because "REMOVE_PAREN_HELPER (QMap<QString, int>)" was expanded to "QMap<QString, int>"DECLARE_GETTER(QString, property2);
// ERROR: expands to "REMOVE_PAREN_HELPER QString get_property2()"// There was no parenteses after REMOVE_PAREN_HELPER so it was not taken as a macro"

We managed to remove the parentheses, but we broke the case where there are no parentheses.
Which lead to a sub-question: How to remove a specific token if present? In this case, how to
remove "REMOVE_PARENT_HELPER" from the expansion

// Same as before#define DECLARE_GETTER(TYPE, NAME) REMOVE_PAREN(TYPE) get_##NAME()// Macro that removes the first argument#define TAIL(A, ...) __VA_ARGS__// This time, we add a "_ ," in front of the arguments#define REMOVE_PAREN_HELPER(...) _ , __VA_ARGS__#define REMOVE_PAREN(A) REMOVE_PAREN2(REMOVE_PAREN_HELPER A)#define REMOVE_PAREN2() TAIL(REMOVE_PAREN_HELPER_##__VA_ARGS__)// ##__VA_ARGS__ will "glue" the first token of its argument with "REMOVE_PAREN_HELPER_"// The first token is:// - "_" if REMOVE_PAREN_HELPER was expanded, in which case we have "REMOVE_PAREN_HELPER__"// which will be removed by the TAIL macro; or// - "REMOVE_PAREN_HELPER if it was not expanded, in chich case we now have// "REMOVE_PAREN_HELPER_REMOVE_PAREN_HELPER"// So we define a macro so that it will be removed by the TAIL macro#define REMOVE_PAREN_HELPER_REMOVE_PAREN_HELPER _,

The above code should give you an idea on how things should work. But it is not yet working.
We need to add a few layers of indirection so all macros arguments gets expanded

But what's the state? How do we represent it?
The idea is to have a static function (let's call it w_state) whose return value contains the state.
Each W_INVOKABLE macro would then expand to a new definition of that function. Of course, it needs
to take a different argument, so this just declares a new overload. We do it by having a
w_number<N> class template, which inherits from w_number<N-1>.
(This idea is basically inspired from CopperSpice's cs_counter, whose authors
described in a talk at CppCon 2015)

This is working pretty well. At the end of this simplified example,
our state is a std::tuple containing
&Foo::xx and &Foo::yy, from which we could build the meta object.
(In the real implementation, the state is a bit more complicated and contains more
data)

This works because the call to w_state(w_number<255>())) that
we use to get the size of the tuple, is referring to the previous declaration of w_state. Since our current
function is not yet defined yet, the most appropriate function is the remaining one with the
highest number.
Notice that we have to repeat the same code in the decltype and after the return and we cannot
use return type deduction because we need to use that function before the class is fully defined.

So far so good. However, I've hit what I think is a compiler bug when doing that with class template
(eg, Foo would be template<typename> Foo).
For this reason, instead of using static functions,
I have used friend functions in verdigris. The principle is exactly the same. It is not well-known,
but friend functions can be declared inline in the class, despite still being global functions.
(I've also used that fact in the implementation of Q_ENUM)
One just needs to add a type which relates to the current class as an argument.
I use a pointer to a pointer to the class instead of just a pointer because I don't want potential
pointer conversion when calling it with a derived class.

Last week the Ceph Day Germany took place at Deutsche Telekom in Darmstadt. Around 160 people took part in the event and attended the talks of the 13 speakers over the day.

It was a great day with a lot of discussions, feedback and networking for the Germany/European Ceph community. The event ended in a networking reception with drinks and fingerfood, planed for an hour but actually ended after nearly two.

A big thank you to the sponsors (SUSE, SAP, Deutsche Telekom AG, Tallence, Intel, 42on.com, Red Hat and Starline) which made the event possible. The same applies to the speakers and attendees, without you it would have been a meaningless event. A special thank you to Danielle Womboldt from Red Hat for all the organisational help and Leo as the Ceph community manager.

We didn't manage to record all sessions due to technical problems, but the most of them. You can find the videos and slides from the speakers in the agenda of the Ceph day or directly in the following Google Drive folder. We will upload the recordings also to the Ceph YouTube channel later. There is also a subfolder with some impressions of the day.

I'm proud that we hosted the event. If you could not attend or would like to learn more about the community I recommend to attend to the next Ceph Day in London in April 2018. See you next time and at the Cephalocon APAC next month in Beijing.

Today is "I Love Free Software Day"!
We're celebrating by shining a spotlight on our contributors and on our collaboration with other FOSS communities and organizations. Free Software is an integral part of our lives, and it's important to show appreciation, support, and gratitude to everyone who works on making it better every day.
One of those people is Franklin Weng, a KDE contributor who started his Free Software journey by translating Kalzium. Franklin's contributions led him to amazing opportunities and projects. Read on to find out why he loves KDE so much.

Kalzium – The Start of An Amazing Journey

by Franklin Weng

When I was a high school student, chemistry was not my cup of tea. My grades in chemistry were not bad either, but I hated memorizing those organic compounds. Then, I decided to major in computer science at university, and from that moment, destiny tightly bonded me and Free and Open Source Software.

Around 2001 or 2002, I started to use and later contribute to KDE. However, Kalzium is the start of another amazing story for me. It happened in 2007...

A throwback to the old look of Kalzium - in Chinese!

I started translating KDE software around 2005. At the time, the Traditional Chinese language packages had almost been abandoned by KDE because of the very slow translation rate. Some senior FOSS community members called to others to "save" Traditional Chinese, and finally we did. From that moment on, I kept translating KDE because I simply asked myself: "Since I'm using this desktop environment, why not do it?"

So I translated everything in KDE. Everything. I started with KMail because I wanted a mail client that would reside in my system tray. Then I translated more KDE PIM applications, KDE Multimedia, KDE Graphics, KDE Games,... even KOffice. And of course, KDE Edu applications - from the simple, lovely ones, like KTuberling, KTouch, and KHangman, to huge ones like KStars and KGeography (that last one is enormous). Kalzium was just another one for me; I even translated KMyMoney - without any accounting background.

Then in 2007, I got an email.

Franklin's credits as the translator of the app.

"I saw you translated the Kalzium software. Could we meet and talk about that?"

That email was from my now friend, Eric Sun, who was (and still is) the Executive Secretary of the Open Source Software Application Consulting Center (OSSACC), a project launched by the Ministry of Education in Taiwan. The project promotes free software for use in primary and high schools. At first I had no idea why this guy would like to meet me. Would he discuss chemistry with me? I wasn't a chemistry-aholic at all!

We met at a Burger King in Taipei. He introduced himself and told me about his idea, which made me appreciate him a lot! He, as the Executive Secretary and also an FOSS enthusiast like me, wanted to introduce educational Free Software applications to teachers and students to help them acquire knowledge from many different fields, without any financial cost.

To promote those Free Software applications, the first step is, of course, to localize them. Teachers and students, especially in primary schools, would never accept software with English interfaces. He noticed that there had been some software with Traditional Chinese translations, and he was curious about who did it. Bingo! It was me.

After that, we have also done a lot of work together, mostly introducing public domain educational resources, including FOSS to schools. I became one of KDE e.V. members and the president of the BoD of Software Liberty Association Taiwan, an NPO which promotes FOSS in Taiwan. In recent years, we have helped Taiwan governments to migrate to LibreOffice and ODF.

Thinking about the past 10 amazing years on the road of promoting FOSS, the start point was that I translated Kalzium. Of course, I wasn't aware that contributing translations to KDE would give me such an amazing tour in my life. Nevertheless, I always use this as an example to tell my young friends in Taiwan: "See? Chemistry is not my thing, but translating Kalzium (and many other KDE applications) made my life wonderful!"

Big thanks to Franklin for contributing to KDE for so many years, and for spreading the word about our software and its educational potential!
Do you have a story about how you fell in love with KDE? Let us know in the comments!

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

February 13, 2018

I’ll try to write about the things I do in the open source communities I’m involved in (openSUSE, SUSE, KDE, etc.). I also plan to write about other personal projects I work on and about development languages, technology, Linux and Free Software in general.

I hope I can keep it interesting

February 12, 2018

With the new Plasma LTS came an update to KDE neon LTS Edition and lots of people asking which edition to use and what the difference is. This caused us to review the purpose of LTS and as a result we’ve just hidden LTS from the download page. The only difference with the LTS edition is that it stays on Plasma’s LTS release but apps and libraries still get updates. This doesn’t fit well with the main use cases of an LTS which is that it only gets bug fixes and no new features. Further we test Neon LTS edition less than any other edition so it’s more likely we’ll miss some problem, which is the opposite of what most people would expect. There are distros whose release model fits better with the needs of Plasma LTS but the constant updates of Neon don’t fit too well. We’ll keep the edition around and don’t expect to make any changes to the repositories or builds, they’re useful for devs testing Plasma LTS, but we’re not advertising it for download since it gives a different expectation of what to expect than fits into the release method of Neon.

The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies. It implements a C++/Qt-based wrapper around a local webpage with a JavaScript library (“marked”) which creates HTML from the plain text in Markdown format passed in.
The software contains

a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format.

a Markdown file KIO thumbnail generator plugin, which allows KIO-powered file managers & dialogs to show thumbnails and previews of files in Markdown format in the target format (currently only available when building against QtWebKit)

February 11, 2018

This week involved a lot of visual polish, and we squashed quite a few bugs causing apps to appear pixellated when they should be crisp and sharp. There was more performance tuning, too, and of course general bugfixing and polish. Take a look!

Fixed a visual bug causing thumbnails in Folder View (i.e. desktop icons) to be pixellated and glitchy; they are now sharp and pretty (KDE bug 376848, fixed in Plasma 5.12.1):

Fixed a visual glitch causing high-resolution or vector distro logos and the plasma logo in KInfoCenter to appear pixellated and glitchy in HiDPI mode; they are also now sharp and pretty (KDE bug 388633, fixed in KDE Plasma 5.12.1):

Fixed a bug causing Chromium and Chrome to always append “.bin” to the end of downloaded files for users of distros with old versions of Qt and/or the shared-mime-info package (KDE bug 382437, fixed in KDE Frameworks 5.44)

Network mounts from /etc/fstab, autoFS, or FUSE now show up under the “Network” category in the Places panel (KDE Phabricator Revision D10319, available in KDE Frameworks 5.43)

You can now use the F11 keyboard shortcut to toggle the aside preview pane in KDE open/save dialogs (KDE bug 389880, available in KDE Frameworks 5.43):

Alt+Enter keyboard shortcut now opens the Properties dialog for Folder View (i.e. Desktop icons) just like it does in Dolphin (KDE bug 389862, available in KDE Plasma 5.13)

Mouse wheel now scrolls the correct number of lines in Konsole when using the libinput driver (KDE bug 386762, fixes in KDE Applications 18.04)

The escape key now cancels out of the ctrl+tab tab switcher menu in Kate and KDevelop (KDE bug 389484, fixed in KDE Applications 18.04)

Spreadsheet files located on Google Drive accessed using Dolphin now open in the correct app (KDE bug 388598, fixed in kio-gdrive 1.2.2)

February 10, 2018

Elisa is a music player developed by the KDE community that strives to be simple and nice to use. We also recognize that we need a flexible product to account for the different workflows and use-cases of our users.

We focus on a very good integration with the Plasma desktop of the KDE community without compromising the support for other platforms (other Linux desktop environments, Windows and Android).

We are creating a reliable product that is a joy to use and respects our users privacy. As such, we will prefer to support online services where users are in control of their data.

We have released the version 0.1 alpha 2 last week.

Elisa with Breeze Dark color theme

Now is really a good time to join the Elisa team. Alexander did quite a lot of changes to lower the barrier to entry. He is actively maintaining the community Elisa wiki page. We have plenty of small tasks open in Elisa workboard.

We also welcome other kind of contributions like design, graphics, promo, etc.

Small tweak to the qmlpackage for the elisa configuration module by Matthieu Gallien ;

Avoid crashing when invoked from dbus without a valid list of files to open by Matthieu Gallien ;

Unbreak the ability to configure shortcuts by Matthieu Gallien ;

Fix restore of playlist position on start by Matthieu Gallien ;

Elisa has moved to kdereview. The feedback from the different releases has motivated this move in order to be able to (if Elisa is accepted by the KDE community) make regular releases to allow user to give feedback.

After a long time of constant distraction by my daily work, I finally found again a bit time to take care of KTextEditor/Kate/… issues.

One thing that really started to be an itch I wanted to scratch is some rendering fault that occur with ‘special’ font sizes.

Given I wanted to do again a bit work on the macOS port, I was really annoyed that on my screen the only application with text rendering issues was “my” one :/

I assume a lot of people have sometimes seen stuff like that in KTextEditor based applications like Kate or KDevelop:

These small white lines really stick out like a sore thumb It looked like some off-by-one rounding issue, surely one should be able to find it…

I tried to track down where in our rendering in KTextEditor we do create these artifacts, but I never found any place that looks like a possible cause.

After a bit more tinkering it became obvious that actually it would be more or less impossible for the KTextEditor code to mess up the painting in such a way, as we normally draw one line more or less as one thing using QTextLayout that handles the painting of the selection background, too.

Using QtCreator as an non-KTextEditor based application that uses the Qt layouting & rendering it was possible to get similar effects on macOS (or X11):

:=) Good thing that Qt is open source. A quick look into the qtextlayout.cpp and a qt5 compile later, I was able to trace the issue down to some qFloor calls for painting the selections.

I hope my patch is correct and will be accepted (QTBUG-66036 / Gerrit 219804) or at least helps others to do the correct fix.

At least for the syntaxhighlighter example shipped with Qt I was able to reproduce the issue before my patch but not afterwards.

Would Qt not be open-source, I would have been at the end of the line after seeing no “error” in our codebase in KTextEditor.

With Qt as some open-source project, it is a completely different story.

Besides, the Qt documentation for “how to build it” and “how to contribute” on the Qt Wiki are well enough to understand that I was able to nicely compile the stuff from scratch on macOS and provide the Gerrit review request in no time.

February 09, 2018

As I mentioned in my previous article about adding sounds to Pixel Wheels, I started yet-another side project: SFXR Qt. This is a QtQuick port of SFXR, a retro sound-effect generator by DrPetter.

SFXR is a fun way to quickly generate old-school sound effects for your game, even if you are not a sound engineer. The generator buttons in the top-left area give you good starting points to create various sounds, and you can fiddle with the various sliders to adjust the sound to your liking.

There are many forks/ports of SFXR, why another one?

I started the port for a few reasons:

First, the current UI is hard to use: something is wrong with the sliders, they do not follow the mouse. The UI is also super small on a HD screen.

Second, the other ports are all Flash-based, which I am not comfortable relying on.

But more important: I wanted to dive into sound generation a bit, and it was a fun way to get into this!

Was it worth the pain?

I think so! I am happy with the way it sounds and it was fun to dive in an area I am not very experienced with. Furthermore I was able to make a few improvements to the user experience, such as automatically previewing sounds as you move the sliders, editing multiple sounds or adding a loop option.

You can ear some of the sound effects produced in this video of Pixel Wheels. All sounds have been generated with SFXR Qt, except for the engine and skidding sounds.

Discover (and all other Kirigami apps that have High-DPI and vector imagery) now look crisp and sharp when run in HiDPI mode (KDE bug 390076, fixed in KDE Frameworks 5.44)

If you like what you see, consider becoming a KDE contributor and join the team! The speed of improvements is pretty directly proportional to the amount of help we have, so the more hands on deck, the better KDE software becomes!

We have released version 2.9.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime. GammaRay 2.9 introduces a number of new features interesting to Qt Quick, QWidgets, Qt 3D and non-graphical Qt users alike.

Qt Quick

One focus area of this release is the paint analyzer. It got significantly improved argument inspection, stack traces for all operations, and, in addition to QWidgets, QGraphicsView and QQuickPaintedItem, it's now also available for the Qt Quick software renderer (with Qt 5.9.3 or newer) and Qt 3D painted textures. The paint analyzer now also measures the time each operation takes. With all that combined you have a powerful tool when being faced with rendering performance issues in applications using the Qt Quick software renderer.

For the Qt Quick OpenGL renderer we have some interesting new feature too of course, such as the texture inspection tab. This enables you to see the textures used on the GPU backing Image elements or Text elements using distance field rendering. This is useful to spot sub-optimal texture atlas usage, or textures containing unnecessary content, both of which can hurt GPU memory consumption. The texture inspection view supports analyzing this with diagnostic overlays, highlighting transparent borders or repeated areas that can for example be optimized by the use of BorderImage elements.

Core Features

There's also new features for the non-UI aspects of Qt. The new QML binding inspector (requires Qt 5.10 or newer) allows you to analyze the dependencies of a QML property binding. It provides source code navigation to the corresponding binding dependency and thus is quite useful for debugging non-trivial binding loops.

GammaRay QML binding inspector showing a binding loop.

The new QObject creation stack trace view expands on the QObject creation source navigation we introduced in the previous release and also shows you the full stack trace leading up to the creation of a specific object (not available on all platforms). Very useful when you spot objects in GammaRay that shouldn't be there (anymore).

GammaRay object creation stack trace view.

Widgets

For QWidget users, the GammaRay widget inspector is now able to visualize the tab focus chain. This makes testing the tab order a lot more convenient than tabbing manually through a big dialog.

Qt 3D

Qt 3D isn't forgotten either. The geometry inspector got a couple of extensions, such as vertex picking support and a number of new diagnostic shading modes that allow you to easily spot issues in e.g. normal, tangent or texture coordinate attributes.

And that's just scratching the surface, there's many more features and improvements in this release. You can find a full list of changes here.

If you like GammaRay, there's an easy way to support its development. Just enable telemetry data submission via 'Help > Contribute' in the GammaRay client. This allows us to see which platforms, Qt versions and tools are most relevant for you, so we can focus on those. Thank you!

GammaRay is available as part of Qt Automotive Suite including Qt Creator integration and professional support, or GPL-licensed on Github.

“Of course it runs FreeBSD, too” is something I said a lot in the past week (regarding the Pine64, mostly, but also about my Slimbook). I also said “Of course it runs on FreeBSD, too” a lot. Naturally area51, the unofficial KDE-FreeBSD ports tree, contains the latest in released KDE software. Plasma 5.12 and KDE Frameworks 5.42, with Qt 5.9.4. We just bumped Qt to pick up a patch from KDE’s Eike Hein to fix some weird hover behavior. So we’re all up-to-date on the KDE front, and I’ve been running it as my main desktop since the build finished in poudriere.

On the official ports front, Qt 5.9.4 and KDE Frameworks 5.42 are what we’ve got. There’s a big move coming up of KDE4 ports, which is to make room (in a sense) for KDE Applications and the Plasma Desktop ports. If you’re using KDE4 from ports, then expect package bumps and renames over the weekend (no functional change, just a lot of ports will get a -kde4 name to distinguish them from the currently-maintained, up-to-date un-suffixed ports which will land afterwards.

There is a dearth of good Unicode fonts for Malayalam script. Most publishing houses and desktop publishing agencies still rely on outdated ASCII era fonts. This not only causes issues with typesetting using present technologies, it makes the ‘document’ or ‘data’ created using these fonts and tools absolutely useless — because the ‘document/data’ is still Latin, not Malayalam.

Rachana Institute of Typography (rachana.org.in) has designed and published a new traditional orthography ornamental Unicode font for Malayalam script, for use in headings, captions and titles. It is named after Sundar, who was a relentless advocate of open fonts, open standards and open publishing. He dreamed of making available several good quality Malayalam fonts, particularly created by Narayana Bhattathiri with his unique calligraphic and typographic signature, freely and openly to the users. The font is licensed under OFL.

The font follows traditional orthography for Malayalam, rather than the unpleasing reformed orthography which was solely introduced due to the technical limitations of typewriters in the ’70s. Such restrictions do not apply to computers and present technology, so it is possible to render the classic beauty of Malayalam script using Unicode and Opentype technologies.

‘Sundar’ is designed by K.H. Hussain — known for his work on Rachana and Meera fonts which comes pre-installed with most Linux distributions; and Narayana Bhattathiri — known for his beautiful calligraphy and lettering in Malayalam script. Graphic engineers of STM Docs (stmdocs.in) did the vectoring and glyph creation. Yours truly took care of the Opentype feature programming. The font can be freely downloaded from rachana.org.in.

February 08, 2018

SoK is finally coming to an end tomorrow for the 40 days projects and it's been a great experience for me being a part of this wonderful season of code I learned many things during this period and most important of all, experience. I got the chance to interact more with my awesome …

Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.

Add your Blog

If you are a KDE contributor you can have your blog on Planet KDE. Blog content should be mostly KDE themed, English language and not liable to offend. If you have a general blog you may want to set up a tag and subscribe the feed for that tag only to Planet KDE.

We also include feeds in different categories, currently Dot News, Project News feeds, User Blogs, french Language, Spanish Language, Polish Language and Portuguese Language KDE blogs. If you have a feed which falls into these categories (or another non-English language) please file a bug as below.

Planet KDE is kept in KDE's
Git. If you have an account you can add or edit your own feed:

git clone kde:websites/planet-kde-org

Put your hackergotchi in website/hackergotchi/. A hackergotchi should be a photo of your face smaller than 80x80 pixels with a transparent background. git add the file.

At the end of the planetkde/config file add your details (the name in brackets is your IRC nick):

If you want to add a Twitter microblog to the Microblogging sidebar add define_microblog true and follow your name with [twitter]. Currently only Twitter is known to work, please contact Jonathan Riddell before adding non-Twitter microblogs to check it works.

If you do not have a Git account, file
a bug in Bugzilla listing your name, Git account (if you have one), IRC nick (if you have one), RSS or Atom feed and what you do in KDE. Attach a photo of your face for hackergotchi.

Blog Classes

The default class for blogs is English language personal blogs. Other classes are:

Spanish language:

define_feedclass spanish

Portugese language:

define_feedclass portuguese

Chinese lanugage:

define_feedclass chinese

Polish lanugae:

define_feedclass polish

Italian lanugae:

define_feedclass italian

French lanugae:

define_feedclass french

KDE User blogs:

define_feedclass user

KDE News feeds:

define_feedclass news

KDE Dot News:

define_feedclass dot

Planet KDE Guidelines

Planet KDE is one of the public faces of the KDE project and is read by millions of users and potential contributors. The content aggregated at Planet KDE is the opinions of its authors, but the sum of that content gives an impression of the project. Please keep in mind the following guidelines for your blog content and read the
KDE Code of Conduct. The KDE project reserves the right to remove an inappropriate blog from the Planet. If that happens multiple times, the Community Working Group can be asked to consider what needs to happen to get your blog aggregated again.

If you are unsure or have queries about what is appropriate contact the KDE Community Working Group.

Blogs should be KDE themed

The majority of content in your blog should be about KDE and your work on KDE. Blog posts about personal subjects are also encouraged since Planet KDE is a chance to learn more about the developers behind KDE. However blog feeds should not be entirely personal, if in doubt set up a tag for Planet KDE and subscribe the feed from that tag so you can control what gets posted.

Posts should be constructive

Posts can be positive and promote KDE, they can be constructive and lay out issues which need to be addressed, but blog feeds should not contain useless, destructive and negative material. Constructive criticism is welcome and the occasional rant is understandable, but a feed where every post is critical and negative is unsuitable. This helps to keep KDE overall a happy project.

You must be a KDE contributor

Only have your blog on Planet KDE if you actively contribute to KDE, for example through code, user support, documentation etc.

It must be a personal blog, or in a blog class

Planet KDE is a collection of blogs from KDE contributors.

Do not inflame

KDE covers a wide variety of people and cultures. Profanities, prejudice, lewd comments and content likely to offend are to be avoided. Do not make personal attacks or attacks against other projects on your blog.