Preparing for Xubuntu 18.04

Xubuntu 17.10 was just released, but planning for Xubuntu 18.04 – the next long-term support (LTS) release – began quite some time ago. For our users, LTS releases mostly mean a system that is going to be more stable and supported for longer. For us contributors, this means a bunch of things.

As a repercussion of the longer support cycle and the sought out stable nature of the LTS releases, we do not want to introduce (too many) new components, libraries or other technical changes, as each change has regression potential. This is also a delicate balancing act between getting bugs fixed but keeping enough things as they are.

The LTS releases are also kind of an flagship for Xubuntu – they are the recommended releases for most users and while we can land stable release updates (SRU) to fix bugs and other major flaws, the scope of changes is limited. Since the next LTS release will be released two years later, we want to get things right.

For contributors – particularly us non-developer kinds – this is an ideal situation to revisit and improve artwork and documentation amongst other things. Here are some things I am going to be working on for the next months to get the new LTS look and feel more polished than the previous one.

Branding – or, updated logo

In an earlier article I wrote about the refreshed Xubuntu logo – the why and the what. Here’s the other what.

Practically this change means we will have to touch every package with Xubuntu branding and make sure they use the updated logo. For the most part this is trivial, but landing the changes requires time and some co-operation from the team.

We will also need to make sure the new logo lands on the official website, all related sites and social media before the release – ideally before the first milestone release. Last but not least, we need to communicate this change to our official vendors and provide them the new logo as soon as possible so they can start updating their products.


As with any release, the LTS release also needs a wallpaper. This needs to be drafted, proposed and polished. The process usually takes from a few days to a few weeks. We’ll also want to land the wallpaper relatively early to be able to fix potential issues with it before release.

The Xubuntu team has organized a community wallpaper contest for the last two LTS releases and it’s very likely we will be organizing one for 18.04 as well. I was not completely satisfied in how we ran the contest last time, and I’ve started a discussion to review our policies already, as getting comments from the team can sometimes be quite slow. While the community wallpaper package does not serve any defaults, we will need to end the contest well before the related freezes to double check license issues (like attribution) and leave enough time for uploading them.


Even if there is no need to rewrite sections – or the whole documentation – this time around, there are several tasks for the documentation team as well.

First of all, it’s time to refresh both the installer slideshow and the website feature tour. Nothing has been planned yet, but both of these are at least two years old and in need of a facelift – both visually and in terms of content.

We haven’t had to touch the documentation much in a long time because the main software selection and features have stayed the same. On the other hand this means that the documentation might be somewhat stale. This might be hard to identify – and possibly even harder to get stale sections refreshed – but we definitely should have a look at our offering before the release. To do this, we need to consider the following questions:

  • Does the documentation provide a good overview of the system for new users?
  • Does the documentation help users get started?
  • Does the documentation answer the most common questions?
  • Does the documentation help get the most common (non-hardware specific) issues solved?
  • Does the documentation help more advanced users – including those that are familiar with other Linux operating systems but not Xubuntu?
  • Is all information in the documentation up-to-date?
  • Does the documentation need extending in any area?
  • Can we extend the documentation in a useful way without making it too verbose?

But wait! There’s more!

My work item list for Xubuntu 18.04 doesn’t end here. You can find all of the registered work items on our status tracker.

It’s worth noting that not all of the work items in the status tracker have an assignee. This means we are still looking for people who can help us make Xubuntu 18.04 a greater release than its predecessors. Maybe you can volunteer and pick up a work item or two?

In addition to the work items, there are a few other activities that we need help with:

  • Test. By testing the daily and milestone ISOs you can help us make sure there aren’t (so many) annoying bugs in the final release.
  • Take part in the community wallpaper contest. This is not open yet, but once it is, submit your work. You can win and get some swag as well as your work included in an official Xubuntu release!
  • Submit us ideas for improving and extending our documentation. I mentioned some of the questions we have to ask ourselves with the documentation. Can you help us answer these and even work with us on the writing and proofreading?

Even these tasks just scratch the surface of what needs to be done – and what can be done.

Get your hands dirty now and read more about getting involved with Xubuntu, subscribe to the Xubuntu development discussion mailing list and join our development IRC channel #xubuntu-devel which is active on most days.

This article is part of the article series .

Pan controls with Google Maps Javascript API v3.24+

As announced in the Google Geo Developers Blog, pan controls are removed from the Google Javascript API since v3.24, which was released in February 2016.

The new panning controls are good and work especially well with mobile devices, but if you for any reason need the old panning control back, you can do it by creating your own custom control. This is relatively easy, but since it might not be trivial enough for everybody, here’s how I solved the issue.


In the script after initializing your map, add the following to create a new control wrapper:

var panControl = document.createElement( 'div' );
panControl.className = 'panControls';

Next, we’ll want to create the actual buttons for panning and add them to the control wrapper. Note: The code below refers to pan_arrow.png, which you need to provide – either download the one created by me or create your own instead. Alternatively, you can embed it in the script itself with base64; see the gist for an example.

var directions = ['North', 'West', 'East', 'South'];
var pan = [];
directions.forEach( function( item ) {
    pan[item] = document.createElement( 'div' );
    pan[item].className = 'panControl ' + item;
    pan[item].innerHTML = '<img src="pan_arrow.png" />';
    panControl.appendChild( pan[item] );
} );

After that, we’ll add listeners for the buttons to activate panning on clicking. Change the panAmount variable (in pixels) to pan more or less per click.

var panAmount = 50;
pan['North'].addEventListener( 'click', function( ) {
    map.panBy( 0, -panAmount );
} );
pan['West'].addEventListener( 'click', function( ) {
    map.panBy( -panAmount, 0 );
} );
pan['East'].addEventListener( 'click', function( ) {
    map.panBy( panAmount, 0 );
} );
pan['South'].addEventListener( 'click', function( ) {
    map.panBy( 0, panAmount );
} );

Finally, we’ll push the pan control wrapper to the left bottom of the map. Change LEFT_BOTTOM to something else if you want to change the location of the panning control.

map.controls[google.maps.ControlPosition.LEFT_BOTTOM].push( panControl );


The JavaScript itself renders a not so good looking and mostly useless block of arrows all facing in the same direction even, so we’ll need to add some CSS to go with it. Add the following CSS to your page with your map.

.panControls {
    position: relative;
    margin: 10px 20px;
    text-align: center;
    width: 40px;
    height: 40px;

    background-color: #fff;
    box-shadow: 0px 1px 4px -1px rgba( 0, 0, 0, 0.3 );
    border-radius: 2px;

    transform: rotate(-45deg);
    .panControls .panControl {
        width: 20px;
        height: 20px;
        -moz-user-select: none;
        cursor: pointer;
        .panControl {
            position: absolute;
            .panControl img {
                opacity: 0.6;
                .panControl:active img {
                    opacity: 1;
            .panControl.North {
                top: 0;
                left: 20px;
            .panControl.West {
                top: 0;
                left: 0;
                .panControl.West img {
                    transform: rotate( -90deg );
            .panControl.East {
                top: 20px;
                left: 20px;
                .panControl.East img {
                    transform: rotate( 90deg );
            .panControl.South {
                top: 20px;
                left: 0;
                .panControl.South img {
                    transform: rotate( -180deg );

Now you have a nicer looking control that matches the style of the default controls!


The panning controls you can create with the code above are very simple but serve my purpose very well. The above code can be found in a gist.

There is at least one particular feature missing from these controls: constant panning when the buttons are held down for a longer time. The controls also do not include hover tooltips, let alone talking about localized ones.

Ultimately, you might want something completely different than I do, but I hope this can help you build the panning controls you need for your situation. Enjoy!