GUADEC is getting near so here’s a heads up on how to get to the venue.

Folkets hus is a pretty large building, located near the ‘Järntorget’ tram station.

If you stand from that station, It is very likely you will notice the ‘Folkets Hus’ sign on top of a large building.

To the left of that, there is a big red peculiar thing, which is the entrance.

That’s where you get in to the GUADEC venue. The doors open approximately around 9.45 and the first talk starts at 10.

PS: there will be a pre-registration party tomorrow at 18.30 at a The Bishops Arms right across the venue. Everyone are welcome and those who have prepaid and registered can come and collect their badges.

During GUADEC’s BoF’s, a meetup at Gothenburg’s local FOSS group will be taking place. They’re called FOSSGBG and the meetup will take place on Tuesday the 11th August from 17:00 to 20:00. Also, the theme of the meetup will be GNOME!

Everyone attending GUADEC are invited and encouraged to attend. The event will include talks by Christian Hergert on Builder and by Michael Catanzaro on HTTPS. I also plan to talk a bit about my experience getting involved in GNOME.

Once the BoFs are over the plan is to meet and walk from the BoF venue over to FOSSGBG’s venue (Ekelundsgatan 4) and be there around 18.30. There will be sandwiches to grab and eat while the event is taking place.

The FOSSGBG event is free, but if you wish to come to the event (and get sandwiches!) you need to register using the link below:

https://www.eventbrite.com/e/hackafton-med-foss-gbg-tickets-17827897722

There is limited space available (~30 attendees top) so I urge you to sign up right away. I also recommend to check out the other social events happening during GUADEC while you’re at it. (:

I’m on a boat at the moment.

The sails has been set towards Sweden. With me is this large banner.

Looking forward to see you all!

Register for GUADEC below:
https://registration.guadec.org/

Since last blog post I have been designing and implementing a room menu for Polari.

Screenshot of current implementation of the room menu in Polari.
The goal of this menu is to provide actions for the current room you are viewing. The menu will help solve some problems:

• Makes it possible to read the room topic in full and change it if you have the permissions to do so.
• Creates a more obvious way to leave a room which is also touch friendly.

These points have been implemented and are available in the branch wip/bastianilso/room-options. I am still considering what other actions are necessary to have in the room menu. My plan is also to expose whether the room is on a private/public network and relevant channel permissions as well as your own status. For private conversations, the room menu could also be an ideal place to expose extra information about the recipent you are talking to if available.

Feel free to share any other use cases you think is the room menu could cover.

Aside from larger items on my list like the previously covered Initial Setup experience, I am also working on a lot of smaller items in Polari. After finishing the GNOME 3.16 release video, I have been submitting small patches to Polari with great assistance from Florian.

First, I recently submitted a patch to Bug 724592, which adds support for the /msg command. A lot of IRC guides mention using the command “/msg NickServ identify username password” but at the moment writing this in Polari will just result in a “command unknown” response. Any results matching your search term is now also highlighted accordingly in the user list (bug 745743). Furthermore, when opening the user list, the search entry always receives focus so you can just type ahead (bug 750689). Users who are offline are now indicated in the chat history by color (bug 710792). Finally, the “join room” dialog now validates the user’s input against the server’s room list and provides auto completion (bug 709846).

Some of the patches still lie around in bugzilla. Others you can enjoy from Polari’s master branch already. I look forward to work through more small details like these. Being able to shape a user experience like that is simply great.

The flags have been raised, summer has kicked in and GSoC is happening. I’m here to share with you what I have on the harddisk at the moment. I am working here and there on Polari, an IRC chat application.

Some days ago I picked up the task of revamping Polari’s first-time-usage state. In Polari 3.16 a new user is presented with an empty window first time he opens Polari such as the figure below. The reason is that no rooms have been joined and no connections have been setup.

Polari’s current way of saying “please add a connection and join a room to chat”.

It might not immediately be obvious how to get started chatting with this thing, however. I took some inspiration from Calendar’s recent initial setup designs by Allan Day and whipped it up with an old prototype by Carlos Soriano. Here’s a video of the work so far.

Screenshots of the implementation in my initialSetup branch.

First time you open Polari, you will now be presented with a welcome dialog which will help you connect to one or more IRC servers. Furthermore, the empty main Window has been made more welcoming to newcomers. The Polari logo and title is there to communicate that this weird looking window in fact is the Polari app. Below a small hint presents the almighty ‘+’ menu, so the user can start adding some rooms.

Existing Polari users won’t see any of this of course. Once you have joined your first rooms, Polari will automatically join them next time you open it.

I recently adapted Builder’s wikipage layout for Polari. I think it adds some fresh air to the app and gives it a home to build upon. Nautilus and Calendar has adopted the layout as well. So I thought I might post how to adopt it.

Before we continue however, I have a warning: at the moment this template contains ugly markup based on tables. Use at your own risk only if presentation means anything for you beyond the ordinary. And feel free to help improve on it!

A GNOME Apps landing page wiki template

There’s two links you need be concerned about:
* Template as wiki markup.
* Template as Inkscape SVG file

To give your wiki page a makeover, copy the wiki markup from link 1. The wiki markup consists of four pictures and some text. To change the text, I would suggest you use find and replace, so you avoid messing up the markup. For images, I suggest you take screenshots and use something like GIMP to crop and export the images as PNG. The four images in the markup code are named “appname-splash.png”, “highlight1-figure.png”, “highlight2-figure.png”, “highlight3-figure.png”. I suggest you rename them (remember to do that in the markup too) to something appropriate for your App.

The Inkscape SVG file which I have provided above can be used to produce the splash image in the top of the template. While you are on the blank layer, copy and paste a high resolution icon of your app into the template. Then select the outer black rectangle, hide the layer called “place-holder-content” and e
To export a splash screen, turn off the visibility for the “place-holder-content” layer and the “bg” layer. Then while, you still have this selection, press Ctrl+Shift+E and export a PNG of your selection at around 750x275px. For this to work properly, “Hide all except selected” should NOT be checked.

If you are not too familiar with Inkscape, I would suggest you download the splash image from Polari (right-click -> Save image as..) and use this png as reference to create your own in fx GIMP.

Let me say this a second time: At the moment the layout is made up of ugly tables (in 2015!). It’s not mobile-friendly, possibly not screen-reader friendly and I think it might require someone to look at theme and workings of our GNOME Wiki itself. With these things fixed though, I think the layout would be cool for all app wiki pages to adopt in some far-away future. The efforts I did on this is only to try to push this a bit forward. I will gladly assist anyone making that future happen.

This summer, I’m about to start a great learning experience. I’ll be busy as a bee working on GNOME’s IRC client, Polari. My aim is to improve the chatting experience of this app, for the benefit of GNOME contributors and users alike. There’s currently 87 bugs filed against Polari. I’ll focus on the following four areas and possibly more:

• Keyword notifications
• Error-handling
• Paste service support
• Initial setup experience

My intention is also to file bugs against developer documentation along the way.

Currently, I’m working on bugs here and there to get some insight into Polari’s infrastructure and some experience working with Telepathy, Gjs and GTK+. I think finding a good workflow for approaching new problems (bugs) is the most important. Many coffees to Florian for being my mentor and a great help so far. (:

EDIT: More information here.

I’m not too fond of terminals. This guide is for new GNOME contributors like me whose brain capacity for terminal commands is only so-so big. I will introduce you to 8 git commands worth remembering. I assume only vague familiarity with git: pulling, pushing and committing.

In GNOME you need to

• keep your commits clean.
• let your commits go through GNOME’s bugzilla as a patch.
• make modifications to your commits based on feedback.

To do this, first, start doing your work in local branches. A branch is like doing a Save-As of your current git project including history and everything. The branch is independent and you can freely jump back and forth between “master” and your own branch.

Create a branch:
git branch yourname/yourbranch

Open a branch:
git checkout yourname/yourbranch

Delete a branch:
git branch -D yourname/yourbranch

Okay. Now, you have done your work and you need to file a bug on bugzilla. Commit your work with a max 80 character commit message and then make a *.patch you can upload.

git format-patch HEAD^
(creates a patch from your latest commit.)

Soon you receive an e-mail saying someone reviewed your patch, and they tell you to make some changes. So you make the changes and now you want to put them into your existing commit. You do this by first doing git add , and then do:

git commit --amend
(modifies your commit to include your changes.)

You can then create a patch from your commit again and upload your new work to bugzilla. Remember to mark the old patch as obsolete in there.

Let’s say you need to test someone else’s patch then. To do this you can do a:

git am mypatch.patch
(applies a patch to the top of your branch.)

This will apply a patch named mypatch.patch to your git folder. If you want to revert back to how it was before, then you can do:

git reset --hard HEAD^
(reverts the top commit of your branch.)

This will revert the latest commit so be careful. Work on a copy branch so you safely can mess around. There’s no easy ctrl+z here. You can run this reset command several times to go several commits back in time. You can keep track of where you are with:

git log
(shows the 5 latest commits on your branch.)

..and that’s it. I think this is everything you need to know to start contributing small patches to your favorite FOSS project. You can revert, copy, create and modify patches. Never be afraid of filing bugs, especially when you attach a patch to them. :)

Me and my computer have been attending the Docs/DevX hackfest happening in Cambridge, England between Sunday the 25th january and Thursday the 29th january.

As you might see in the picture above, we are all seated in a cozy conference room at the Collabora office. I’m sitting with a whole bunch of people from the #docs team being a busy bee.

Tuesday whereabouts

• Shobha (curiousDTU) has been doing some review of the documentation for GNOME’s games.
• Ekaterina (kittykat) and Shaun (shaunm) have been discussing how new contributors could be attracted to the documentation team. Furthermore they have also discussed Mallard and how the future could look for it.
• Ekaterina has also been fixing application documentation bugs here and there in the vast collection of GNOME’s.
• Peter (pmkovar) successfully converted the translated release video subtitles from *.po and back to *.srt. This means that the GNOME 3.14 release video is now available in 14 different languages! A big thanks goes to the translation team for translating them.
• Jana (jsvarova) got a public GNOME blog and carried on fixing bugs from the cue that were in scope for this hackfest.

I myself have been focusing on rewriting the Getting started with GTK+ tutorial and learning how to make applications with GTK 3 along the way. My patch is currently undergoing review. Furthermore the GNOME Platform demos has gotten an overhaul – which also is something that currently is going under review. Once the patches land, new developers should hopefully have a better experience which is more up-to-date with how we currently recommend making applications with GTK 3.

Hackfest overall

I am writing this blogpost while I’m on my way back to Denmark. The hackfest has been a great experience in many ways. First, it is great to meet with fellow GNOME contributors face-to-face. This hackfest has also been a big learning experience for me in terms of Git, Mallard, GTK3 and C. I have gained knowledge much more rapidly because I have had great people right next to me, ready to answer any questions of mine (+whisky) and review my (initially poorly written) patches. Thanks everyone!

Once I get home I will probably have a few more patches to submit. Afterwards, it is time to work on planning the GNOME 3.16 release video again. I would definitely love to work further with the developer experience again in the future. And I would definitely attend another GNOME hackfest.