Category: Uncategorized

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!

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

Wallpaper Livestream

It’s getting to be that time of the release cycle where I’ll be making a new wallpaper for the next Plasma release. For the 5.11 cycle I’ll be doing things a bit differently owing to a request on Reddit several weeks back; this wallpaper is going to be done over a livestream!

The wallpaper livestream will be on Saturday the 20th, and start ~10:00am Eastern Daylight time, or 2:00pm GMT. I’m going to estimate the stream to last ~8-10 hours, with a couple short breaks somewhere in the middle.

The aim will be to get the majority of the wallpaper done during the stream (they take that long!), with anything done beyond the stream falling into tweaks and correction territory. There’s also the chance you may see a few attempts until I settle, as I have a few designs in mind and there may be some experimentation there along with some spectacular failures along the road.

I’ll keep a chat open, and I’ll field any questions I get, but beyond that I figure it will be the kind of stream people might like as background noise. I also suspect it might be the kind of thing people will want to minimize now and again – I think it will be a passive viewing experience. When the livestream is over I’ll go back and create a sped-up version which I’ll post on YouTube.

Which brings me to an important question I have for everyone who does or is into livestreams; I’ve never streamed before! I know about Twitch and YouTube, even Hangouts, and have heard about OBS; are there any recommendations for which streaming service/software I should broadcast with? Comment here (or on Reddit, I’ll be posting there) with input as to the best way to stream a fairly long art session. Also, I’m considering using a webcam as well – please let me know if that’s of interest, and if there’s software for a total rookie to do it. I’ll post the info on where I’ll be streaming once I figure out where it will be.

Lastly, if the stream is fairly successful at least on a technical level, I’ll look into shorter episodes featuring Aether icon development which would probably see rounds of 3-4 icons being completed in the space of a shorter session.

A ‘ittl bit on th’ kde.org work

Earlier this week the decision was made to switch from Drupal to WordPress as the CMS used for the KDE.org main website. While Drupal is certainly a fine system, the decision to switch was borne when my quick work to update a WordPress asset turned into a serious venture much more successful than my work with Drupal. Prior to my contributing to KDE I used to develop on WP, and I was surprised to find out my experience largely held in this new version. In hindsight, WordPress was the obvious option considering this.

A round of discussion about formally switching ensued, and many other great reasons to use WordPress were present, including the much larger number of KDE websites on the platform. I won’t get into it too much as I’d instead like to go over the work done over the past week and some of the features coming to KDE.org Aether template which are already complete; today I’ll focus on the header, which had the most love.

The header will feature an up to 3-level menu, and in the future it may be made to not restrict the number of levels. But, for now, 3. It nicely scales back to two or one levels as appropriate. Currently the theme will pull featured images from root navigation elements and display them in the dropdown, but in the future this will likely become a navigation-specific setting for more control. As expected, the navigation is completely customizable. It is also responsive, and when it can no longer accommodate the number of menu items for the width of the given screen it will switch into ‘hamburger mode’ which works very well on mobile.

earlywork.png

My personal favorite feature so far is the live search. This probably had the most work this week, and I really wanted to nail it down well. It’s a search-as-you-type system, but has several built-in features to avoid overloading servers, such as an adaptive delay until it performs a request and temporary localstorage caching.

livesearch.png

Lastly, the theme is being built to be completely customizable for suitability on not only KDE.org itself, but even as far down as personal blogs which may not demand the full range of features being built into the design.

options.png

The design itself is forked from KdeTheme theme, which in turn was forked from Activello. It features thoughtful localization, and work is being done to make the individual components more modular so maintenance will be a cinch over the long game. There are still many features, options, and utilities being poured into the design, and I’ll be posting updates semi-regularly as the progress continues.

Ultimately, the KDE.org theme itself will be generic enough for use on any KDE-related site. As it matures enough to be in use on regular websites, the design will also be loaded onto the WordPress theme directory, allowing sites which may not enjoy the full KDE infrastructure (such as personal developer blogs) to easily install and keep the theme updated.

If you maintain a KDE-related website and are using Drupal, depending on the breadth of your content, we still have options for you. If you have a smaller website, I’ll be offering to port to WordPress if you desire. If you have features required which can be folded into the larger theme I will do so as appropriate, otherwise we can evaluate if a small site-specific plugin could serve that use-case. If you have a Drupal site too large to move – or you simply wish to stick on Drupal – after the KDE.org wordpress work is considered complete, the existing Drupal 7 theme will be updated to service existing websites. For anyone else maintaining a website looking to use this design I’m also taking feature requests for the theme and design elements at this point. Please send inquiries and requests to the kde-www mailing list.

Beyond the design itself, we have some exciting plans for managing content and applications which I’ll be posting about later.

KDE.org and Drupal

KDE.org quite possibly has one of the largest open-source websites compared to any other desktop-oriented project, extending beyond into applications, wikis, guides, and much more. The amount of content is dizzying and indeed a huge chunk of that content is about as old as the mascot Kandalf – figuratively and literally.

Kandalf

I personally believe he’s ripped under that cloak.

The KDE.org user-facing design “Aether” is live and various kinks have been worked out, but one fact is glaringly obvious; we’ve made the layers of age and look better by adding another layer. Ultimately the real fix is migrating the site to Drupal, so I figured this post would cover some of the thoughts and progress behind the ongoing work.

Right now work is on porting the Aether theme to Drupal 8, ideally it’ll be “better than perfect port” with Drupal optimizations, making better use of Bootstrap 4, and refinements. Additionally, I’m preparing a “Neverland-style” template for those planning to use Aether on their KDE-related project sites, but it’s more of a side-project until the Drupal theme lands. Recently the theme was changed to use Bootsraps’ Barrio base theme, which has been a very pleasant decision as we get much more “out of the box”. It does require a Bootstrap library module which will allow local or CDN-based Bootstrap installations, and while at first I was asking “why can’t a theme just be self-contained?”, now I’m understanding the logic – Bootstrap is popular, multiple themes use it, this will keep it all up-to-date and can be updated itself. I do think maybe one thing Drupal should do is have some rudimentary package management that says “hey, we also need to download this”, but it’s easy enough to install separately.

If you have a project website looking to port to Aether, I would first advise you simply waiting until you can consider moving your page to the main Drupal installation when it eventually goes live; in my perfect world I imagine Drupal unifying a great amount of disparate content, thus getting free updates. Additionally, consider hitting up the KDE-www mailing list and ask to help out on content, or place feature requests for front-end UI elements. While I’m currently lurking the mailing list, I’ll try to provide whatever info I can. On an aside, I had some Telegram confusion with some people looking to contribute and concerns from administrators, so please simply defer to the mailing list.

In terms of the Aether theme, I will be posting the basic theme on our git repo; when it goes up if you have Bootstrap and Twig experience (any at all is more than I had when I started), please consider contributing, especially if you maintain a page and would migrate to Drupal if it had the appropriate featureset. I will post a tiny follow-up when the repo is up.

 

 

 

 

A Link to the Tileset & Sprite Trivia

In my off time I’ve been closely examining the Legend of Zelda Link to the Past tilesets and sprites, and I’ve been learning a huge amount about how that game is assembled visually. it’s amazing how much they managed to do with the limited resources of the SNES.

For a game I’ve played religiously as a child, it’s interesting to see the imperfections which I completely glossed over even after several complete playthoroughs. There’s also some neat workarounds Nintendo did while preparing their graphics.

So here’s some “trivia” I found while closely examining the various maps and shots of the game;

  • Bricks lining the floors of diagonal walls are always rounded. This is not decorative, but a limit of their sprite-sheets 8×8 tile resolution. There are 5 unique 8×8 tiles used to create a diagonal wall, it would have required 6 tiles to add the 3 pixels needed to straighten the edge, and another 16×16 composite tile. Same, apparently, with the bottom of diagonal cliff edges. If they fixed this, several tight diagonal corridors would have been impossible.
  • In the overworld you will never find a flower that is NOT above a sprig of grass. You will always find flowers tiled with grass, or above and to the left of two sprigs. If you see three flowers, it’s just a combination of the other two patterns.
  • Live grass and dead grass never touch. I’m guessing because dead grass is a palette swap, so they would have had to include a tile-set for those edges. Instead, there’s always a dirt buffer or a cliff.
  • Bobbing flowers in the overworld have more frames of animation than any single enemy walk cycle. As a matter of fact, some enemies only appear to have one frame in their walk cycles – it’s just flipped to create the illusion of movement.
  • The animation used for guards falling off an edge contains more frames of animation than several enemies have for all their animations, total.
  • There is one tree in the game with a root placed on dirt/cliff edge. The tiles that make up that root are recoloured grass; because of that, one of the colours is slightly mismatched.
  • Cliffs are by far the most complex tiles in the game, but also tend to show the most seams between tiles. To say it must have been painstaking I think would be an understatement.
  • Most dungeons and houses share the same brick walls, only palette swapped with different tops. Instead, dungeons distinguish themselves with unique entrances, pillars, and decorations. There’s also a unique entrance for the monastery which was unused, possibly to avoid it being confused with dungeons.
  • Walls in houses and dungeons also don’t obey perspective, various tricks are used to maintain the illusion. The southmost walls are sometimes outright covered, and very seldomly will you see half-walls or “tall” objects touching the south walls.
  • Braziers, tall lampposts, half-walls, and various other doodads to not contain transparency keys. While not surprising on its own, it’s shocking to realise how many things don’t actually have “shapes” or “blend in” to their environments when closely examined, simply having grey backgrounds which most people must never notice. Those moving spike traps? Those are square, you just thought they were pointy.

Anyway, those were some fun facts.

Zelda: A Link to the Past is simply an amazing piece of work, and the tilesets are remarkably compressed for what they were able to create; PNG images containing the complete light world are larger than the entire game itself, not including the alternate dark world, insides of houses, or dungeons.

Tomorrow is a New Day – Joining Blue Systems

I’m very excited to let everyone know that as of tomorrow I’ll officially be joining Blue Systems, working full time on KDE and related projects! The chance to really immerse oneself completely into something you love and also work alongside people you absolutely respect is mind-blowing.

I would like to deeply thank Blue Systems for this opportunity, I hope my contributions will match the awesome generosity that everyone in the community has given allowing me do this. Thank you!