New Icons, Iconoclast Pipeline

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.

Preview of the new folders. Subject to change and refinement.

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.

FizzBuzz Overanalyzed

Fizzbuzz is a common coding competency challenge that tests your ability to work with basic math and logic. The challenge is to write a block of code that accomplishes these goals:

  • Iterate over an incrementing integer. 0, 1, 2, 3… We’ll call this $i. We’ll call the current iteration $n.
  • Write “fizz” when the $n is a multiple of 3.
  • Write “buzz” when the $n is a multiple of 5.
  • Write “fizzbuzz” when both the previous conditions are met.
  • Write the value of $n if none of the above conditions are met.

Commonly the challenge might stipulate that your code should be written as a function. In this case a “fizzbuzz” function will accept one integer $n and return or print the result.

For the FizzBuzz challenge this is what I would consider a fairly typical response (as written in PHP) which we’ll call “Solution 1”:

function fizzBuzz ($n)
{
	if($n % 3 == 0 && $n % 5 == 0) {
		return 'fizzbuzz';
	} 
	else if($n % 5 == 0) {
		return 'buzz';
	} 
	else if($n % 3 == 0) {
		return 'fizz';
	} 
	else {
		return $n;
	}
}

for ($i = 1; $i < 50; $i ++) {
	echo fizzBuzz($i)."\n";
}

The output of this FizzBuzz will look something like this:

1
2
fizz
4
buzz
fizz
7
8
fizz
buzz
11
fizz
13
14
fizzbuzz
16
17
fizz
...

The Gotchas

There’s two main ‘gotchas’ that solution 1 misses. This first is an outright error; the very first check in FizzBuzz should be for the number 0. While the sample codes on this page don’t make use of 0, it’s good to anticipate it depending on who you’re presenting a FizzBuzz to.

if($n == 0) {
	return 0;
} 

The reason for this is because the modulus operator used in FizzBuzz responses returns remainders. If a modulus operation returns 0, it’s a clean division, making it a multiple. Except for 0. 0 will always return a remainder of 0 but isn’t actually considered a multiple of integral numbers. It always surprises me know many FizzBuzz solutions neglect 0.

The second common ‘gotcha’ is known as the “15” condition. Often we see something like this:

if($n % 3 == 0 && $n % 5 == 0) {
	return 'fizzbuzz';
} 

There’s nothing wrong with this response, but it can alternatively be written as…

if($n % 15 == 0) {
	return 'fizzbuzz';
} 

The basic premise is that instead of using two checks (for 3 and 5) in the “fizzbuzz” condition, you can instead use one check for 15. Between any multiple of 3 and 5 the lowest common denominator is 15, and using that to avoid a check potentially saves hundreds of calculations if running the fizzbuzz check thousands of times.

Ultimately, there’s no wrong response to the 15 check, but I would ask any author why they used one method over the other. If they used the two-check method my preferred answer would lean towards readability or “self documentation”. Yes, it’s less efficient, but glancing at the code you more readily have an idea of what the author might be trying to do. If they used the one-check method I’d be fishing for either an answer in outright efficiency or general mathematics. If someone performed the 15 check and didn’t have an answer I’d be a bit more concerned that it’s not their logic and they just read about using 15 somewhere.

Given all this, a more thoughtful FizzBuzz response might look something like this, which we’ll call “Solution 2”;

function fizzBuzz ($n)
{
	if($n == 0) {
		return 0;
	}
	else if($n % 15 == 0) {
		return 'fizzbuzz';
	} 
	else if($n % 5 == 0) {
		return 'buzz';
	} 
	else if($n % 3 == 0) {
		return 'fizz';
	} 
	else {
		return $n;
	}
}

for ($i = 1; $i < 50; $i ++) {
	echo fizzBuzz($i)."\n";
}

Going Ternary

There is, also, further evolution of a good answer which compresses the code down by several lines, and also gives additional performance perks which we’ll call “Solution 3”;

function fizzBuzz ($n)
{
	if($n == 0) {
		return 0;
	}
	else if ($n % 3 == 0) {
		return $n % 5 ? 'fizzbuzz' : 'fizz';
	}
	else {
		return $n % 5 == 0 ? 'buzz' : $n;
	}
}

for ($i = 1; $i < 50; $i ++) {
	echo fizzBuzz($i)."\n";
}

In this more compact variant we not only look at the reduced line count, but also use more efficient codepaths. In this solution we use ternary expressions inside our return statements. Ternary expressions are essentially a more condensed if condition. The above code could be written as nested if statements, but many developers avoid nesting more than a few levels deep as it makes code progressively more difficult to navigate.

On the efficiency front this solution better accounts for modulus (%) not being an efficient operator to use, as far as operators go. Leaving aside the 0 condition the two solutions have what are called “best case” and “worst case” costs to run the function. Below shows these cases, along with the average number of % checks performed after 1000 iterations.

Best “%” CaseWorst “%” CaseAverage “%” CaseAverage Execution Time
Solution 1243.734973837.016
Solution 2132.734688097.077
Solution 32223843310.965
Number of “%” Calls per solution. Average Execution Time is against 10000 iterations with 1000 samples, compared using hrTime.

At first blush the best case scenario is better with solution 2, but solution 2’s best case only applied to one of every 15 iterations. You could shuffle the conditions so the second most efficient path applies to one third of the checks… but in general you’re just pushing a flat logic tree if you do that, when a couple of branches in logic paths will serve you better.

I don’t think anybody in their right mind would expect people to know the performance metrics of FizzBuzz. It’s not exactly real-world code, but if a developer is writing a solution to the FizzBuzz challenge beyond a competency level, I’d be very interested in seeing them push a little bit beyond the basics.

While we don’t want to try micro-optimizing this fairly trivial piece of code, it is always worth seeing when someone tends to write in more efficient manners, or at least, can. If nothing else, it’s always good to see someone push their code just a little bit harder beyond what’s strictly necessary.

Or maybe I’m just overanalyzing it.

Bash Updater

If you’re like me, you probably see the value in keeping your code in GIT repositories. If you’re like me and you also have websites running you probably pull your staged code right from git. It might not be an enterprise-grade solution, but it’s easy, we know where things are, and it’s a fairly natural workflow.

There is an issue though created by my desire for absolute laziness; it can be annoying to cd all the way into a folder, run the pull requests, and possibly do it again if I’ve exited from my ssh session but I had one more push to pull.

Of course, the natural solution is to alias a command that does everything. But it doesn’t feel particularly flexible, and I don’t like having an archive of commands which may or may not be functional. Another solution is to have something like GitHub run webhooks and such to trigger updates as you make them. While this sounds pretty hand and super simple, for me personally, I like to know exactly when my code will go live.

My solution is the below script in tandem with a dead-simple config file, which lets me get the granularity I like without the need for endless aliased commands.

#!/bin/bash

# Updates various git repositories registered in ~/git-update-locations.ini.
# Format is as follows:
# [MyProject]
# firstRepo=/path/to/first/repo
# secondRepo=/path/to/second/repo
# allRepos=/path/to/repos/*
#
# git-update.sh MyProject firstRepo
# git-update.sh MyProject allRepos
#
# If the value of a path ends with "*" it will look at all directories in that
# location, if they have a git repo, it will run the pull.
#
# For example:
# 
# [mywordpresssite.com]
# theme=/var/www/mywordpresssite.com/public_html/wp-content/themes/my-git-theme
# plugins=/var/www/mywordpresssite.com/public_html/wp-content/plugins/*
#
# git-update.sh mywordpresssite.com theme
# -> will update the theme from git.
#
# git-update.sh mywordpresssite.com plugins
# -> will update all plugins found connected to git.

if [ ! -f "$HOME/git-update-locations.ini" ]; then
	"$HOME/git-update-locations.ini not found"
	exit
fi

if [[ -z $1 ]] ; then
	echo "You must specify a registered site"
	exit
fi

if [[ -z $2 ]] ; then
	echo "You must specify a section to update"
	exit
fi

SECTION=${1//[_- ]/.}
TARGET=${2//[._ -]/"-"}
CONFIG="$HOME/git-update-locations.ini"
FOLDER=$(sed -nr "/^\[$SECTION\]/ { :l /^$TARGET[ ]*=/ { s/.*=[ ]*//; p; q;}; n; b l;}" "$CONFIG")

if [ "$FOLDER" = "" ]; then
	echo "Target $SECTION $TARGET not found."
	exit
fi

if [[ "$FOLDER" =~ '*'$ ]] ; then 
	echo "Scanning for git repositories"
	for REPO in "${FOLDER::-1}"*; do
		[ -d "$REPO" ] || continue
		cd "$REPO"
		status="$(git rev-parse --is-inside-work-tree 2>/dev/null)"
		[ "$status" = "true" ] || continue
		echo "Updating $REPO"
		git status -s
		git pull --verbose
	done
else
	echo "Updating $FOLDER"
	cd "$FOLDER"
	git status -s
	git pull --verbose
fi

Of course, I’ve aliased this script to git-update.

alias git-update="/path/to/git-updater/git-update.sh"

Below is a portion of my own ini file, with the values used for updating this site and even the updater itself;

[kver.ca]
plugins=/var/www/kver.ca/public_html/wp-content/plugins/*
themes=/var/www/kver.ca/public_html/wp-content/themes/*
kv-design=/var/www/kver.ca/public_html/wp-content/themes/kv-design/

[utils]
updater=/opt/git-updater/

These days when updating my personal websites I just push to git, ssh into the server and have fairly quick access running my updates like so;

# Update my theme
git-update kver.ca theme

#Update all plugins connected to git
git-update kver.ca plugins

#Update the updater
git-update utils updater

Getting Glyphy With It

The newest addition is the Glyph library used on this site. It features hundreds of original icons in a convenient font-based format.

Work on the glyphs is ongoing, and I expect there to be some upheaval in the near future as the generator is upgraded. If you don’t mind that though or just want to peruse, check em’ out!

Cluster Wallpaper – Community Feedback Update

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!

plasma-5-14-final-4k

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.

Plasma 5.14 Wallpaper “Cluster”

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;

plasma-5-14-cluster-8k

Click here for 8K image

RX Vega + AMDGPU-PRO + KDE Neon

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.

Modest Wallpaper Tweaks

compare.png

After posting the image of the 5.11 wallpaper feedback started coming in and one thing fairly consistently mentioned is how dark/muted it is. Of course, there were mixed opinions on whether it was good to be dark or if it was a little too far, but it was a clear observation, especially compared to the previous wallpapers.

So I took a few minutes to adjust the wallpaper. There were lots of people who liked having something more subtle, so I didn’t stray too far. I adjusted the blues to be more saturated, the browns are lighter towards the bottom to reduce banding, the orange is a bit brighter, and reds on the right were tweaked. I also reduced an “atmosphere” gradient. Lastly, I removed a noise filter used to combat banding.

Overall it’s not that much lighter, but it should be less muddy and washed out. If you didn’t have them side-by-side ideally you may not notice the changes, but hopefully it just feels a bit better.

Here’s the adjusted wallpaper:

2560x1600.png

Both versions are available on the KDE Store.

Plasma 5.11 Wallpaper

Well, it’s that time of the year again where I talk about wallpapers!

For those who watched the livestream of the beach wallpaper, you’ll notice this isn’t what I had been working on. Truth be told after the stream I hit a few artistic blocks which brought progress to a grinding halt. I plan to finish that wallpaper, but for this release I created something entirely different while I decide what to do with it. I enjoyed this “wireframe” effect, and will probably experiment with it again.

This wallpaper is named “Opal”, specifically after wood opal resulting from when water carrying mineral deposits will petrify wood it runs across. Wood opal is pretty special stuff, and often it can often look straight out of a fairy tale.

2560x1600.png

The Plasma 5.11 wallpaper “Opal” is available on the KDE Store.

Plasma 5.11 Wallpaper Production – Part 1

[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.

plasma-5-11-inprogress.png

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. 😀