This Saturday (Feb 19th) from 12:00pm to ~4:00pm EST I’ll be livestreaming preliminary work on the Plasma 5.25 wallpaper, as well as a brainstorming session for possible directions the Plasma 6 wallpapers could go. Iconography might also be a thing.

The Plasma 5.25 wallpaper work is mainly going to be sketching in Krita, and there may be 2 or 3 sketches that come out from that process. After that will be exploring ideas I’ll be proposing for Plasma 6, including KDE-prompted neurally generated images being used to find new and interesting design concepts.

After two tremendously fun livestreams the Plasma 5.24 wallpaper is all wrapped up. With this particular image we had a lot of fun using new techniques to create this wallpaper, and the entire process was a fun adventure. To download the wallpaper it’s available on OpenDesktop and GetHowNewStuff if you’re a Plasma user.

The wallpaper was first sketched in the Krita painting application. Up until this point wallpapers I authored used a fairly inflexible technique of creating a polygon grid and manipulating it, but this new shape would require new techniques.

In Inkscape a wireframe was drawn using the line tool. This was done by drawing curved lines roughly matched over the sketch, applying successive wireframes one over another until we could rely on the snapping tools in Inkscape to place polygons.

This ultimately resulted in 2,221 hand-drawn polygons, layered in a way similar to reptile scales so gaps would not show through once fills were applied. People often question if these are done in Blender, but Inkscape is actually the software of the day with this being done entirely in 2D.

Fills were applied as linear gradients to the grouped polygons. At this point edges were also drawn in and I was getting ready to use the “Jitter Gradients” plugin I developed some years ago for the purpose of differentiating the individual polygons, but alas it wasn’t compatible with modern Inkscape! AAAAGH!

While I was busy having a panic attack live on-air Niccolò Veggero swept in and graciously updated the script to be compatible while I worked in other areas. What a lifesaver! With the Jitter Gradients plugin fixed up work began hopping between Krita and Inkscape, colours starting roughly landing, and we quickly approached the end of the wallpaper work.

Layers layers layers ahoy! This was the state of the wallpaper at the end of the second livestream. While almost everything was in place, in practise it’s never a bad idea to walk away for a few hours to come back later with clear eyes.

After coming back to the image several adjustments were made. A lot of the work I had done in Krita during the livestream was replaced, mostly because I realized I didn’t do the work in 8K, which we offer now. There was also a few steps in GIMP such as noise and some minor light-curve editing.

And so ended the work on the Plasma 5.24 wallpaper! After taking it up with the chat on the livestream it was quickly decided to be named “Wavy McWallpaperface”. The last steps are pretty standard; we run it through our cropping and sizing script which produces the highest quality versions for a variety of resolutions. If you noticed that the base image is slightly taller than “standard” it’s because it was, to accommodate cropping so it’s not just removing content for taller aspect ratios. The cropping script was also adjusted slightly for this wallpaper so it wouldn’t crop the top, which is the more interesting bit.

If you’re a crazy person and you wish to watch the wallpaper being created you can watch the process as it was streamed on Youtube:
Part 1: Wireframe & Polygon Creation
Part 2: Everything Else

To download the wallpaper once again it’s available on OpenDesktop at various resolutions, including the mobile version!

Update: The Livestream is moved to Monday January 10th, sorry for the inconvenience it may cause.

After a very successful livestream at the beginning of the week (with a heartfelt thank-you to everyone who popped in) it’s time to hunker down for one more afternoon to finish what we started! This Sunday (January 9th) I’ll once again be hosting a stream, where we’ll finish the wallpaper together. All the tedious manual work is well behind us, so this round should be mostly finery and polish in addition to the background, which is all fun and creative stuff. Click here for the Youtube link to the upcoming stream if you want to set a reminder for yourself. The livestream will run at least 2 hours, but if we’re all having fun I’ll run it for an additional 2 after a brief intermission.

For everyone who didn’t have a chance to attend, in the last livestream we started with the above sketch done in Krita and experimented with a new method on-the-fly where we leaned into Inkscapes snapping features to create a 3D mesh by hand, with the plan to use the built-in “Restacking” tool to enable hand-drawn polygons with “perfect” edges. While the mesh method was a rousing success and testing the restack feature gave ideal results, near the end of the stream it was realized that watching me draw triangles for several hours was not a hip idea, so I decided to take the remainder of the more tedious work offline.

Which was a good thing, because I had to throw away hours worth of hand-drawn polygons. I was not a happy camper. There was a damper in the pamper. It was a stylistic cramper. Simply put I literally zigged when I should have zagged and half the polygons were misaligned because of it.

Not to worry though, because I had the chance to experiment a bit more with less certain ideas and while I’m still playing a bit, I’m even happier with the redone results. Almost like I had roughly 5 hours of practice…

In terms of livestreaming itself it went off without a hitch on a technical level, but the overall quality was pretty awful. I’m sorry for that, I didn’t realize how bad it was. I’ve been making improvements so the quality of future streams will be far better. Earnestly I wasn’t sure if I’d be doing it again so I didn’t put an overwhelming amount of effort into the initial setup. I fully expected to have large swaths of time without anyone watching, but while the quality of the feed was borderline unwatchable I saw far more activity than I anticipated, and the chat was more than excellent in making me want to continue doing streams. You all rock!

There’s still testing and adjustments to be made but it’ll definitely have much higher video quality this upcoming stream, hopefully have better audio quality, and there’s a 50/50 chance I’ll broadcast in (up to) 4K (if the latency is acceptable). I didn’t have hardware encoding set up, I think it’ll be waaaaay nicer for me not to be encoding 4K to 1080p video on my CPU while using a CPU-intensive drawing application. It’s almost like my video card is meant for video. Additionally, and while I make no guarantees, I’ll also be attempting to hook up screen mirroring with my Android drawing tablet so I can use both it and my desktop computer to complete the wallpaper using all the tools at my disposal on-air. While the mixing of vector and traditional art was debated in an older wallpaper, I’ll have you – yes, you! – to give live feedback.

Once again I want to thank everyone who made it (or wanted to make it) to the previous stream. It was a delightful experience and I hope to see you this Sunday!

Hullo! On Monday January 3rd 5:00pm GMT (12:00pm EST) I’m going to try livestreaming work on a potential Plasma wallpaper, possibly some icon work, and other potential tangential work. I’ll also be answering questions, giving advice and tips for software like Krita and Inkscape, and if there’s time I may also show some terrible unreleased design work from the bowels of my storage drive. The stream will be of indeterminate length; at least a couple hours but it might run long.

The stream will be on Youtube for sure, please comment requesting another video service (click here) if Youtube/Google skeeves interested people out (assuming I can get them to work); here’s the Youtube link for those who may want to set a reminder.

Some new CSS classes are coming to icons courtesy Janet Blackquill, and I’m excited to cover what exactly this will let icon artists do in 2022! This post is part tutorial and part news. For those looking for a quick TLDR; icons are going to get even better. I’m also going to clear up some inaccuracies in existing documentation (which I plan on updating at some point later)

CSS?

For those unfamiliar, vector icons in KDE can have a stylesheet which embeds several useful colours which update along with the system palette. If you want to make icons that adapt in some way you use the colours in these sheets. If you open an SVG icon from Breeze in a standard text editor you might come across something vaguely like this:

<style id="current-color-scheme" type="text/css">
    .ColorScheme-Text { color:#4d4d4d; }
    .ColorScheme-Background { color:#eff0f1; }
    .ColorScheme-Highlight { color:#3daee9; }
    .ColorScheme-ViewText { color:#31363b; }
    .ColorScheme-ViewBackground { color:#fcfcfc; }
    .ColorScheme-ViewHover { color:#93cee9; }
    .ColorScheme-ViewFocus{ color:#3daee9; }
    .ColorScheme-ButtonText { color:#31363b; }
    .ColorScheme-ButtonBackground { color:#eff0f1; }
    .ColorScheme-ButtonHover { color:#93cee9; }
    .ColorScheme-ButtonFocus{ color:#3daee9; }
</style>

Note that the <style> tag has an id of “current-color-scheme”. This is how we identify which <style> tag contains our adaptive colours.

When using Inkscape you can use the “Selectors and CSS” dialog available under the Object menu to see these special styles:

When you have a something selected you can set the fill or stroke to “currentColor” and use the “+” button to add a CSS class. Things that apply to the selected element are on the left, and a list of all classes found in the image are on the right. Here’s the important part: the classes in this list are a lie! First and foremost, some icons have extra CSS classes listed that don’t actually work when used as an icon, and of course, some new ones are missing. You can’t “preview” how an icon will look with Inkscape alone, so to see what actually works there’s applications like Cuttlefish or Ikona which can provide an accurate view of your work. In terms of quickly making sure you have the correct palette in an icon, I recommend using a text editor and replacing the style with the “id” of “current-color-scheme” with the style below:

<style id="current-color-scheme" type="text/css">
    .ColorScheme-Text         { color: #232629; }
    .ColorScheme-Background   { color: #eff0f1; }
    .ColorScheme-Highlight    { color: #7ec9f0; }
    .ColorScheme-PositiveText { color: #27ae60; }
    .ColorScheme-NeutralText  { color: #f67400; }
    .ColorScheme-NegativeText { color: #da4453; }
    .ColorScheme-ActiveText   { color: #3daee9; }
    .ColorScheme-Complement   { color: #ffffff; }
    .ColorScheme-Contrast     { color: #000000; }
</style>

You may notice several colours are very different. Let’s start with what’s missing; ColorScheme-ViewText, ColorScheme-ViewBackground, ColorScheme-ViewHover, ColorScheme-ViewFocus, ColorScheme-ButtonText, ColorScheme-ButtonBackground, and ColorScheme-ButtonHover are gone. I don’t know much about why these are used as often as they are, if they ever worked, or what, but they’re no longer active and when I was double checking to ensure I don’t feed anyone misinformation I found some bugs where they were meant to be used but… don’t work. So, for now, we’ll ignore what doesn’t actually exist.

In terms of what does exist, here’s a list of the available colours from the above style code and what you can expect behaviourally, along with my own observations:

• ColorScheme-Text; it’s the same colour as text on a standard window. This usually means it’s near-white or near-black, but expect some colour schemes to add some saturation, such as a red theme making text pink. The opposing colour to Text is Background. For modern use it’s a good contrast colour, and works really well for monochrome icons paired with text.
• ColorScheme-Background; Same as the background colour of a standard window. Background has fewer use-cases, and generally it’s recommended you use transparency instead of this.
• ColorScheme-Highlight; This was the first method of using the increasingly popular accent colour in icons, but colour schemes generally mix the accent colour with the background colour dulling the result to a degree. If you want the exact accent colour read on to ActiveText. Highlight is still great when you want to use the accent colour but you don’t want it to be overly strong.
• ColorScheme-PositiveText/ColorScheme-NeutralText/ColorScheme-NegativeText; Generally these are green, orange, and red respectively. Some schemes do change these a bit so if you want “guaranteed” colours such as green, these are not appropriate. Instead use them as their labels imply, as positive to negatively associated colours. These are used often in monochrome icons. If working on full-colour icons and you’re representing a common system component or generic things these can be used as well for light flavour, such as debris in a trash can, but it’s recommended use be kept to a minimum.
• ColorScheme-ActiveText; this is one of the 3 newly added colours to icons, and is the new recommended way of using accent colours in icons if you want the exact colour. Unlike Highlight, ActiveText is an unmodified accent colour directly set by the user. It can be just about anything from sky blue to hot pink to grey.
• ColorScheme-Complement and ColorScheme-Contrast; These are the other two new colours, and are a little bit special. Unlike every other colour set by the scheme, Complement and Contrast are guaranteed to be pure black or pure white. If the colour scheme is dark Compliment will be black and Contrast will be white, and if the scheme is light Compliment will be white and Contrast will be black. There are several use-cases for these, mainly for allowing icons to re-shade themselves for light/dark environments, or for providing outlines. Often icon artists relied on Text and Background for “shading”, but with schemes like Quartz or Afterglow you’d see situations where icons would be “stained” in unwanted ways. Now we have a much more reliable pair of values which won’t create muddy results.

How We’ll Use These New Classes

The new colours added a few possibilities. ColorScheme-ActiveText is pretty straightforward, giving us the user-defined accent. If you have an icon theme and are using accent colours via Highlight, ActiveText will get you the more vibrant and untarnished accent colour. Beyond that Compliment and Contrast are pulling a few duties in the upcoming icon refresh, so I’ll cover them in more detail.

First we’re using ColorScheme-Contrast for bottom shadows/highlights. In dark mode it gives icons a soft under-light, and light mode it’s a standard shadow. Previously we used Text for this, and it worked, but Contrast is just better for this now. Where it’s really nice is helping define the silhouette of the icon.

For folders we’re mixing in a very small amount of Contrast over top the accent colour for just a very tiny amount of “pop” without being obnoxious about it. This also helps guarantee a minimal amount of contrast between the accent colour and the background.

We’re using ColorScheme-Compliment for decals and overlays. We get nice dark-on-dark or light-on-light designs, but we don’t suffer from decals looking “muddy” anymore as we used the Background colour where we now use Compliment.

For comparison here’s the same folder using the new CSS under previously unfavourable circumstances with a red-on-red-on-red scheme, the folder on the left using previously available colours and the folder on the right using the three new colours. Before the new colours I was ready to chalk it up to “don’t use terrible themes” but now everyone can safely use the very worst colour schemes on the planet and still have usable and attractive icons.

Beyond the new colours, work is continuing on the refreshed icons. There’s been a great deal of feedback and many icons are being fine-tuned. The pipeline tools are evolving as well, having had a significant refactor which greatly improved the tool all-around.

Over the month of November work has been started to refresh the full-colour icons in Breeze as an extension of the “Blue Ocean” initiative. With literally hundreds of hand-created vector icons in our roster we’ve had to develop new processes and are working on a more robust pipeline so this refresh can be done in a somewhat timely manner.

As was the method for Blue Ocean on the desktop widgets and design, the icons will be a gradual rollout over a few releases. We do have a strategy in place to ensure that this won’t be too jarring or inconsistent during the transition. The current plan is to update both all mimetypes and all places in time for the 5.24 release.

Like our current icons the new icons have adaptive capabilities. Beyond that some additional select icons such as the new desktop icon are also adaptive, and there are plans for other icons to also take advantage of this feature where it would not be obnoxious. Compared to existing icons the refreshed content will be softer, more detailed, and less flat. These icons are also prepared with future capabilities in mind, and as enhancements are made to KDE Frameworks these icons may expose new and interesting features.

Finally, we’re expanding the number of sizes the icons come in, so they look ideal at more zoom levels in your file browser. Currently colour places icons are offered in 32, 48, 64, and 96 pixel sizes, and mimetypes are offered in 32 and 64 pixel sizes. Refreshed icons in both places and mimetypes will be offered in 32, 48, 64, 96, 128, and 256 pixel sizes with no missing graphics. We already have all folders in all of the above sizes, and in under a month while also writing our software we have over doubled the number of folder icons in Breeze. We’re estimating we will more than triple in the number of mimetype icons.

To get this work done we’ve built new tools for the express purpose of making mass iconography far easier for even individual artists, so I’m very pleased to state that a new icon and SVG pipeline is underway and despite being unfinished is producing results. This Python-written pipeline is capable of adding guides, rulers, and setting up grids for existing icons, standardizing existing icon colours, assembling entirely new icons from templates and components, and aggressively optimizing icons. With this authors will be able to have a “golden copy” of their icon sets where they can focus purely on design, letting the software take care of cleaning up the documents and assembling the individual pieces. The folders in the above image were assembled by the pipeline, with no hand-tuning.

In terms of optimization some extreme cases have seen unoptimized Oxygen icons drop 75% or their filesize. In less ideal situations a few simple hand-optimized test icons I produced run through the pipeline saw 10-20% reductions in filesize. The new optimizer is not built on any existing tools, and is an entirely new thing. At similar settings the new optimizer is on par or slightly ahead of Inkscape in most tests, but at the same time it’s also more specialized and the output cannot be edited when certain stages are enabled. It’s also targeted towards TinySVG and should not be expected to work on full-fat images (though, accommodations have been made). There is still work to be done too, and in the future more optimization steps are on the table to further reduce output size.

Not only is this pipeline beneficial to KDE artists, but history has proven even the roughest artistic tools we produce are regularly used outside of Plasma development. With this in mind we plan to release our new tooling separate from Breeze as its own package/download after polishing it to a mirror shine. Currently nicknamed “Iconoclast”, we are specifically setting out for this tooling to be useful and ready for the wider community beyond KDE.

Iconoclast will include our new pipeline, a manual, tips and advice, and another entirely new icon set named “Bones”, which is already in progress. The pipeline itself is strongly configurable with ini files, so KDE-isms can be removed and it can be adapted to work for icons sets that may have different flows through configuration. The Bones icon set will be a minimal base which can either be built on top of, or used as a reference, and these icons will released in the public domain. Different projects with different licenses can just take it and use it, and it’s uses generic technologies not tied to KDE. The pipeline itself will be GPL, and I don’t have a specific timeline for when the kit will be released but once it’s solidified I’ll make an announcement; though it’s likely to be after the new year.

After posting the Plasma 5.14 “Cluster” wallpaper and asking for feedback there was a huge response, and after a few days of big changes and finer adjustments I hope this will serve as a satisfactory wallpaper. I’d like to thank everyone who offered constructive feedback, pitched in ideas, and even offered examples, you’re amazing!

Cluster and the source SVG file are now available on OpenDesktop and the KDE Store. For those seeking the Krita source file, please contact me directly and I will ensure it’s available somewhere.

The time for a new Plasma wallpaper is here, so for 5.14 I’m excited to offer up “Cluster”.

But first, please allow me to gush for a moment. In tandem with Inkscape, this is the first wallpaper for KDE produced using the ever excellent Krita. For graphic design my computer has a bit of beef to it, but when I work with Inkscape or GIMP things always chug just a bit more than I feel they should. Whenever I’ve had the distinct pleasure of opening Krita, even on my lesser powered laptop, it’s always been productive, rewarding, and performant. I’m looking forward to using Krita more in future wallpapers. *claps for Krita*

Now, with pixmaps there’s always a valid concern that higher-resolution monitors will suffer blurring because of low native resolutions. The master file for this slightly larger than 8k, so hopefully this will not be an issue. The only potential problem this causes is the large size of the master files. The Inkscape source will be published when the final wallpaper is released as per usual (just under 50MB), but the Krita-based assets are only going to be available on request. This is because the .kra is 135MB, and I have a feeling a few people might be angry if I load that onto the shared server. Unless they read this and tell me it’s fine. Who knows!

The wallpaper still has a polish pass, so rough edges or things that might feel awkward will be ironed out before it’s committed. If you have feedback you can comment here or over on the Reddit thread: https://www.reddit.com/r/kde/comments/90syno/plasma_514_wallpaper_cluster/

Here it is;

Click here for 8K image

Earlier this week I got my dirty hands on an RX Vega 64 card to run on my daily workstation. With the aim to eventually run open drivers in the future my main goal for now was to get AMDGPU-PRO running for day-to-day activities, possibly also moving to Wayland from X11. I’m very interested in Wayland as Kwin has several Wayland-only enhancements, and even if I wouldn’t use it now I wanted to be ready for testing.  The Vega card would be replacing an Nvidia GTX 1080 card.

In terms of usage I look to beefy video cards for when I do the odd video-related task, for applications like Krita, and other reasons up to and including general enthusiasm.

Since it’s been a pretty rough experience I figured I’d blog about the state of Vega with Plasma, my opinions, and my hopes for the future.

Hardware

Because of the stock shortages which have been pretty persistent I ordered the standard edition sapphire card when I stumbled across one that somehow hadn’t sold out.

I like the understated design of it, and despite its more simple looking build it does look and feel premium – moreso than it does in review videos. When active the Radeon text on the side glows red, and there is also a “GPU Tachometer” which shows the load on the card. There are also hardware switches which let you recolor or disable the LEDs.

Driver, Kernel, and Installation

This is my first gripe. The AMDGPU-PRO driver installer from the AMD website hardcodes specific distribution names into the installer .sh file. In order to install the AMD driver onto KDE Neon I had to edit the file and change “ubuntu” to “neon”, as otherwise the installer will halt and state that you cannot run the install. It felt a bit wrong and I’m wondering if AMD should add in a warning and continuation option should the string check fail, such as “this us unsupported and could pooch your installation, continue anyway? (y/n)”

With the string change the installer worked without complaint, but I ran into another problem after restarting: the black screen of doom when graphics have failed to start. After researching I found it was caused because my installation of KDE Neon didn’t use the hardware enablement stack or “HWE” as offered by Ubuntu LTS. After I enabled the HWE I was able to get into an X11 session.

Once I was in an X11 session screen tearing was fairly extreme. On researching I found out I could add the “TearFree” option in “10-amdgpu-pro.conf” to solve this issue. At this point I figured I solved all the major adoption problems to get back to my previous baseline from my time on the Nvidia card, so a reboot was in order to try out a clean session.

Usage

Have you picked up that I’m not providing exact instructions on how to run AMDGPU-PRO drivers on Neon with Vega? It’s because as of the time of this writing, the experience is isn’t day-to-day usable and I won’t instruct you into a sub-par session. The drivers are still very new, and after I write this I’ll be re-installing my Nvidia drivers until I can try a Mesa session on stock kernel drivers.

Applications which make use of hardware acceleration will cause the system to stutter and hang, sometimes for a few seconds. My only conclusion given the hardware on my machine is that the PRO drivers have issues. I also find that sometimes opening applications at all will cause a momentary hang, with Kate causing a several second freeze which only fixed itself as I began reaching for the power button. These are also complete system locks at the kernel level, as I’m unable to switch to the TTY interfaces and manually restart the session or kill applications.

Game performance – as much as I “game” – is lackluster and glitchy under AMD. Remembering those reports of “Nvidia only” games on Linux I can suddenly and clearly understand why this is the case. I ran several of my neglected games from Steam and even a game like Factorio had glitches, while others like Rocket League were unplayable. Many were good, but all suffered performance issues. I think there’s an issue with loading and unloading data to the GPU, because the worst hangs seem to be during these steps. Rocket League took nearly 10 seconds to close and locked my entire system at this time. I simply gave up at this point with further game testing, being happy with none of the samples I tried.

I was unable to get Wayland working at this point. I’m sure I could have if I really wanted to, but my initial impressions with an X11 session were so lackluster that I decided anything Wayland would fix are still far outweighed by the general driver itself. For even simple desktop work there have been minor visual glitches, and I’ve caught moments of tearing several times despite being in TearFree mode.

In theory I could have used my Intel graphics to drive my displays, and there are instructions for doing this with Mesa drivers in headless mode on the AMD card. This would have let someone solve these problems, but sadly I didn’t have the outputs on my motherboard to support 2 Displayport displays and an HDMI tablet to try this.

Final Thoughts

I don’t know how much I want to ream on AMDGPU-PRO drivers or Vega at this point. While KDE Neon uses Ubuntu LTS as a base system, technically, the PRO drivers did state they weren’t compatible with my system. At the same time I know in theory they shouldn’t be having problems.

To a large degree I also expected the relatively overpowered card when used in my actual day-to-day activities to make up for any driver performance issues – I was banking on that. I don’t actually play my games so I don’t need Bioshock Infinite to run at 120fps – I need my desktop to run at 60. I either underestimated how badly the driver performs, or simply hit the wrong bugs, because for every minute of smooth operation I had with the driver there’s a hard stutter, hang, or jitter.

If you run Neon I can’t recommend a Vega card at this point, so I recommend you save your time and money until there’s an announcement stating that the generic Linux kernel can output to displays on Vega. At that point maybe even check back on my blog because I’ll be re-visiting Vega on Neon with Mesa, which from what I understand should be the experience I was expecting. Until then I’ll be putting the Nvidia card back into my machine for a stable desktop, as AMDGPU-PRO+Vega+Neon results in an unusable system at this point in time.

[youtube https://www.youtube.com/watch?v=ocK54NsqN2Q]

Today I streamed the first half of the Plasma 5.11 wallpaper production, and it was an interesting experience. The video above is the abridged version sped up ~20x, heavily edited to the actual creation, and should be a fun watch for the interested.

It looks like there’s another full work-day that needs to go into the wallpaper still, and while I think I’ll also record the second half I don’t think I’ll livestream it; while I’m very appreciative of the viewers I had, it was quite a bit of extra work and quite difficult to carry on a one-man conversation for 8 hours, while working, for at most a few people. Like I said, I will still record the second half of the wallpaper for posterity, I simply don’t think I’ll be streaming it. I do think I’ll keep streaming the odd icon batch, as those are about as long as I want, so they can be kept to a digestible hour.

The wallpaper as it is is based on an image of a reef along with a recent trip to the beach during the Blue Systems sprint. There’s still a long way to go, and I can easily see another 8 hours going into this before it’s completed; there’s water effects, tides, doing the rocks, and taking a second pass at the foam – among other things – especially before I hit the level of KDE polish I’d like meet.

Looking at it, I may also make a reversed image with only the shoreline components for dual-screen aficionados.

Within the next week or so I’ll post the next timelapse after I complete the wallpaper. 😀