Jannis Pohlmann Personal website

Jannis

I am an open source enthusiast, student and musician from Lübeck, Germany. In my free time I enjoy hacking on Xfce and Lunar Linux. I've been a member of both teams since about 2005. Besides developing software, I love to listen to and play music (Guitar, Bass and Drums) and hang out with friends.

Contact me via jannis@xfce.org. My public PGP key is 0x354AFBA6. You can download it from here.

My CV is also available for download.

Tag - personal

Entries feed - Comments feed

Sunday, November 4 2012

How to start contributing to Xfce or any other open source project

It’s been a while since I’ve updated this website and even longer since I’ve written anything useful. But since I’ve received a couple of mails from people looking to contribute to Xfce recently, I thought I’d share some “wisdom” acquired over the past few years while working on Xfce and doing a lot of community work. My thoughts are not limited to Xfce and will apply to a lot of other projects out there as well.

Here’s the bitter truth for those looking for some quick pointers to start contributing to Xfce: you’ll have to find out yourself.

The reason is not that we are lazy or wouldn’t welcome your contributions. In fact, the reason, I believe, is very simple: you will be more excited, motivated and, ultimate, be more successful if you work on something that interests you. We can help you in making the decision what to invest your time in easier, e.g. by listing projects, features or issues that we or our users consider worth working on. Some projects do this very visibly (e.g. through bounties). In Xfce, this information is hidden in the depths of the wiki. Here are a few links that you may find interesting:

Clearly, the above information could be more visible. There could be a prominent link on the Xfce website to a well-maintained and up-to-date list. Would that help people? Maybe.

Perhaps it is a good thing that the information isn’t just one click away. Open source projects have always been about scratching your own itch. This is how I got involved in everything I’ve done over the years. this approach is reflected by what people do and sometimes even by how companies make money. Thinking about it now, it is a concept deeply rooted in the evolution of mankind (think: the invention and improvement of tools, industrialisation and all that shit).

So: scratch your own itch.

If you want to start contributing to a project, try this exercise:

  • Look at the project, think about what you don’t like or what you feel could be improved
  • Try to collect information on what pieces are involved in e.g. the feature you’re missing or the bug you’ve spotted
  • Try to find the place where you could try adding your feature or fixing your bug
  • Ask whether developers are interested in the feature or look at whether there already is an item for your issue in the bug tracker
  • The rest is communication and coding

It’s not a fast path because you might not be able to contribute something of great value in the beginning. But if you’re dedicated, have enough spare time to make a difference and are keen on improving things step by step, you might eventually reach a point where you take over responsibility for more and more exciting or important tasks.

Good luck!

Thursday, February 9 2012

FOSDEM 2012

This year’s FOSDEM is over and I hope that most of us have by now recovered from an exhausting weekend that was first and foremost exciting and a lot of fun! With about 12 people, the Xfce group was—I think—larger than ever before. Add to that a fairly large number of my colleagues from Codethink, into which I bumped at the beer event and FOSDEM itself from time to time. Despite mostly staying with Xfce, I enjoyed knowing and meeting people all over the place.

Unfortunately, some of us—myself included—missed half of the beer event because our trains and planes arrived late. Snow in Brussels, a cold weekend ahead. When we arrived at the Delirium Café at around midnight, I was glad to see that all the others had already made friends again. Olivier, Stephan, Peter, Nick, Simon, Christoph, everyone was there, some of them sufficiently drunk, I imagine. Although to be be fair, you wouldn’t really notice. Most of us left not to long after that in order to be in a good condition in the morning. Having only caught up half on drinking, Christian, Mike and I ended up staying at the Delirium with a few Codethink colleagues including Sam, Luc and Javier—until they finally kicked us out at around four in the morning.

Food, taxi, 2 1/2 hours of sleep later and we were sitting in the hotel, enjoying a fantastic buffet breakfast. Admittedly, I couldn’t eat that morning, ending the night in the Delirium had lead to quite a strong hangover. After the majority of us had gathered in the hotel lobby, we squeezed ourselves into the 71 bus in two groups and finally arrived at FOSDEM. I do not remember the details of the day, but it was a great mix of talks (including my own one about Tumbler, which I felt was not very special, picture below), chatting and minor hacking (at least on my side; Nick made good progress with the settings editor in the meantime). During the day, Jean-Francois, Jens and Mark joined us and we (or most of us at least) ended the day having food in a Vietnamese restaurant close to the hotel and a beer in the hotel lobby.

Sunday was similar, except that I could finally enjoy the breakfast. Lovely. Unfortunately, we didn’t manage to get everyone together anymore, so our initially large group was now split up into smaller ones for the rest of Sunday. We still managed to have a few technical chats about Xfce that day and made a few decisions (see below). Regards talks, I mostly remember the Wayland Q&A session and a talk about social engineering in free software communities, Most of us left in the afternoon or evening. I met up with Luc, Sam, Javier and a bunch of other people to have food in a very nice restaurant. Got up at six in the morning, walked to the central station, took a plane home from the airport and went back to work in the afternoon. Unlike a few others I seem to have escaped the typical illnesses (cold, broken sleep cycles, general exhaustion) that events like FOSDEM always bring along.

Xfce-Related News — Fresh from FOSDEM

Wayland was big this year. I will spare you the details of how it works. Throughout the weekend, we had various discussions that involved Wayland. While it may take some load of Olivier by eventually making window managers obsolete, there is still a major problem with it: it does not support the XEmbed protocol, and therefor will break pluggable settings dialogs and panel plugins. We have sent mails to the wayland-devel list to find out how they feel about this. For now, I suppose this is all we can do.

Reorganization of the settings dialogs

One thing we decided on Sunday was to reorganize the settings dialogs so that the location of particular types of settings becomes more predictable. This applies to appearance and window manager themeing, and the application keyboard shortcuts and window manager keyboard shortcuts in particular. We will rearrange some of these tabs and merge them so that all related settings are in one place. We will also merge the window manager and window manager tweaks dialogs into one.

Release Schedule for Xfce 4.10

Despite a lack of completed features in Thunar (which are unlikely to get finished before 4.10), there are only a few things that really keep us from releasing Xfce 4.10. We have not decided on a release date, but if things go well, we should be able to roll the first pre-release one month from now, in early March. This would mean that a final release in May or June would be feasible.

Possibility of a hackfest

Meeting up with the team is always great fun. Unfortunately, FOSDEM is a busy event and only lasts two days. Like last year, we discussed the possibility of an Xfce hackfest in the future. I would love to see this idea becoming reality. If half a dozen of the relevant people can make it for at least a couple of days, this could greatly benefit the development of Xfce. Ideally, such a hackfest would span over at least 4-5 days, ideally including a weekend to make it easier to attend for people with jobs. Given a relatively small group, it might even be possible to hold an event like this at someone’s flat. This is definitely something that we will look into soon.

Like every year, FOSDEM 2012 was a great event. And like every year, a few more nicknames have turned into real faces that, unsurprisingly, belong to incredibly friendly human beings! I only wish that we had more time to discuss things face to face and do some serious work on Xfce together. In any case, this calls for another iteration next year. And with that, I shall end this wrap-up.

Monday, October 17 2011

An introduction to drawing graphs with TikZ/PGF, Part 3

This post is the last in a series of articles about PGF/TikZ and its new graph drawing features on which I am working as part of my graduate thesis.

In the previous two posts I gave an introduction to graph drawing, the graph syntax of TikZ and its Lua-based graph drawing engine that can be used to implement automatic graph drawing algorithms and use them to compute layouts for graphs that are to be rendered with TikZ.

For this post, my intention was to demonstrate the algorithms that I implemented as part of my thesis. These algorithms work well with many graphs, including grids, symmetric graphs, flow charts, flow networks and state machines or automata.

However, I decided to just point to the final version of my thesis here. It documents the algorithms extensively and gives many examples of how to use and tweak them. I think the thesis holds information much more useful to users and graph drawing researchers than what I’d be able to put in a regular blog post.

So, here is the official link: 

http://www.tcs.uni-luebeck.de/downloads/papers/2011/2011-configurable-graph-drawing-algorithms-jannis-pohlmann.pdf

If you find mistakes, please keep them to yourself. It still has to be marked by the two reviewers, so I don’t want to know what I did wrong yet. ;)

Monday, August 29 2011

Looking for a full time job in Open Source

Two years ago I was really close to canceling my studies and looking for a job instead. In the end I continued studying, passed the final exams of my Diplom (the German old-school equivalent to a Master’s degree) with excellent results and started working on my graduate thesis. Today, I am 1 1/2 months away from the submission deadline and it is clear that I will make it.

So, this time I’m serious: I’m looking for a full time employment in Open Source software development, engineering or management starting November this year. Hiring me will get you an experienced and talented hacker with a natural intuition for software architecture and aesthetics as well as a scientific and painstaking approach to software planning and implementation.

Through my work at the university and within the Xfce and Lunar Linux projects, I have gained experience in/with

  • many programming languages (including C, C++, Ruby, Python, Vala, Lua, XSLT, TeX, Java, Bash and a couple of others),
  • many frameworks (the whole GTK+/GLib stack including D-Bus, a bit of Clutter, XLib and Qt/QML, SWT/JFace, the FOX toolkit as well as web frameworks like Sinatra and Rails; some knowledge about the Linux kernel, its facilities and kernel-userspace communication mechanisms included),
  • many developer tools (GNU compilers, Autotools, VIM, NetBeans, Eclipse and others),
  • many software versioning systems (Git, Subversion, CVS and Mercurial), and
  • various areas of computer science and software engineering (complexity theory, signal processing, graph drawing, micro-controller programming and sensor-based networking, software planning, testing etc.).

I feel equally at home developing for the desktop or for the web. Granted, my main area of expertise is user interface and middleware development on Linux, which my fellow Xfce hackers and I have successfully participated in, but I’ve always found web development with Ruby to be a refreshing change.

There are many other things related to open source that I love doing. Over the past years I’ve enjoyed being able to improve the transparency of the development and release management of Xfce. Streamlining the release process and providing tools for making release management fun was an initiative I am particularly proud of. The same goes for community efforts like the Xfce Foundation, which we’ve launched in early 2011 and which I am currently heading as president.

This post is not just about the past though, it’s also about what lies ahead. Things I am particularly interested in with regards to the future include

  • mobile platforms and applications (iOS and Android are not good enough, I think we need open alternatives),
  • multi-touch interfaces on Linux (yep, this is on the way, but there still is a lot of potential work to be done, I guess),
  • cloud-based applications (I know I can store files and data on the web, but where are the mind-blowing features that go beyond availability of personal data everywhere?), and
  • environmental and power saving applications (living responsibly will become important soon enough; how can we generate awareness and support environmental causes with the help of software?).

I am excited and curious what my role will be in all this. Anway, I guess this is enough information about me for now. After all, this is no biography but a job-search post. ;)

If you read this and you happen to be Microsoft or Apple, do not even bother to send a headhunter. I prefer to work in the open and I believe in Open Source for many reasons. This ecosystem that we’ve created over the past two decades provides a great way for people from all around the world to collaborate on projects they care about, in an honest and tolerant way. I think that’s an inspirational model from which our entire society can and hopefully will benefit. Why would we want to have it any other way?

If you are a member or leader of a company dedicated to Open Source software and are interested in hiring me, please let me know. Linked below are my resumé, software projects and email address. I’m looking forward to talking to you!

Download my resumé/CV — A list of references is included. Feel free to contact them; they are aware of being listed and I’m sure they will be happy to answer any of your questions.

My software projects — A list of open source software projects I am or have been working on.

Email address: jannis@xfce.org

Thursday, July 21 2011

An introduction to drawing graphs with TikZ/PGF, Part 2

This post is part of a series of articles about PGF/TikZ and its new graph drawing features on which I am working as part of my graduate thesis.

In the previous post I wrote about motivations for using computer tools to draw graphs. I described the problems with older and current versions of PGF/TikZ. The essence of that post was to show that the current PGF/TikZ syntax for graphs is too verbose and that manual node positioning is impractical. I concluded by explaining that a solution for this is in development. 

In this post I will present some of the graph-related features of the upcoming version of PGF/TikZ. As mentioned in part 1, these are:

  • A new, drastically simplified graph syntax that is as powerful as the verbose old syntax.
  • A couple of basic node positioning (or: placement) strategies such as circular placement or grid placement.
  • The new graph drawing subsystem for automatic graph drawing algorithms based on the Lua scripting language.

As part of my graduate thesis I implemented a set of algorithms for force-directed and layered drawings of graphs. These work remarkably well with a lot of graphs that I collected from lecture notes, books and research papers. I will present these algorithms in a separate post, the third and last of this series.

The new, simplified graph syntax supported by TikZ

TikZ is the graphics language that comes bundled with PGF. In the upcoming version it includes a new syntax for specifying and drawing graphs. First, let us remember the old syntax though (copied from the previous post):

\usemodule[tikz]
\starttext
\starttikzpicture[every path/.style={>=latex},every node/.style={draw,circle}]
  \node            (a) at (0,0)  { A };
  \node            (b) at (2,0)  { B };
  \node            (c) at (2,-2) { C };
  \node[rectangle] (d) at (0,-2) { D };
  \draw[->] (a) edge (b);
  \draw[->] (a) edge (c);
  \draw[->] (b) edge (c);
  \draw[<-] (c) edge (d);
\stoptikzpicture
\stoptext

Remember the problems: manual node positioning, verbose declaration of nodes and edges. Here’s the result once again:

Now, let’s take a look at the new syntax using the same example:

\usemodule[tikz]
\usetikzlibrary[graphs]
\starttext
\startTEXpage
\starttikzpicture
  \graph [no placement,nodes={draw,circle},edges={>=latex}] {
    A [at={(0,0)}] -> {
      B [at={(2,0)}] -> C [at={(2,-2)}],
      C -> D [at={(0,-2)},rectangle]
    }
  };
\stoptikzpicture
\stopTEXpage
\stoptext

The main differences compared to the old notation are:

  • The graph is declared with the \graph macro which executes all TikZ options in the /graphs scope, making the definition of options possible that are not visible to other elements in the TikZ environment (such as nodes={} instead of every node/.style={}).
  • Nodes no longer need to be declared with the \node macro. Instead, simply typing their value is often sufficient. Name names may contain spaces as well as special characters, so things like x_i -> x_j are possible too (in combination with the math nodes graph option these nodes would be typeset just like in a math environment). A third notation is name_text, where name is the internal name to be used when defining edges and text is a string that is displayd inside the node. Again, this text may include special characters and spaces e.g. for formulas.
  • The manual positioning with the at option is a bit more verbose but there are ways around this as you will learn soon.
  • Note that TikZ options can be passed to nodes as well as edges by using the [] syntax.
  • Nodes can be combined in chains (e.g. A -> B -> C) and groups (e.g. { A, B }). Groups are particularly interesting as edges entering or leaving a group are (often, not always) duplicated and re-routed to/from the individual nodes in the group. Also, groups can be assigned TikZ options as well, allowing all nodes or edges in the group to be altered at once (e.g. by changing the color of the nodes A and B to red with { [red] A, B }).

This new syntax has plenty of other features, some of which are still in development (e.g. yesterday we discussed a new syntax for edge labels). All of these features are explained along with helpful examples in about 50 extra pages in the updated manual that we will ship with the next release.

Basic node positioning strategies

In the above example, I chose to set no placement to avoid automatic node positioning. In the upcoming version, TikZ supports various placement strategies including:

  • Cartesian placement (from left to right, with nodes in the same group being placed at the same level),
  • circular placement (nodes are placed on a circle),
  • grid placement (nodes are placed in a N * M grid where the number of columns or rows can be configured by the user), and
  • no placement (for manual positioning)

Here is an example using circular placement and grid placement:

\usemodule[tikz]
\usetikzlibrary[graphs]
\starttext
\startTEXpage
\starttikzpicture
  \startscope
    \graph [circular placement,nodes={draw,circle}] {
      a, b, c, d, e, f,
    };
  \stopscope
  \startscope[xshift=2cm,yshift=1cm]
    \graph [grid placement,n=6,nodes={draw}] {
      a, b, c, d, e, f,
    };
  \stopscope
\stoptikzpicture
\stopTEXpage
\stoptext

There are various options for these placement strategies. Together with a set of standard graphs (complete graphs, complete bipartite graphs, circles, grids etc.) that can be created using keywords such as subgraph K_n or subgraph Grid_n, these already cover a number of use cases.

The original problem, however, remains: how to find a good layout for arbitrary trees, state machines, automata, flow charts and graphs compiled from large sets of data? This is where the new graph drawing subsystem of PGF/TikZ comes into play.

The Lua-based graph drawing subsystem of PGF

Lua is a powerful, light-weight scripting language often used to extend complex software systems such as computer games. It combines elements of procedural, functional and object-oriented programming and is similar to other modern languages like Ruby or Python in that regard. The major differences are that it ships a rudimentary standard library only and that only a few basic data types are provided by default. All other complex data types need to be built on top of the table data type which is a mixture of an array and a hash table.

LuaTeX is an enhanced distribution of the TeX typesetting system that embeds Lua as a scripting and extension language. One of its features is that there is a TeX macro to execute Lua code directly from TeX: \directlua. This can be used to process TeX data with Lua scripts and pass data between these two layers (TeX and Lua). 

Combining the power of LuaTeX with algorithms available for automatic graph positioning (or: graph drawing) might be a good idea. At least that’s what Till —- author/maintainer of PGF/TikZ and supervisor of my undergraduate and graduate theses —- and a group of students thought before they went on to implement a graph drawing interface between TikZ, PGF and Lua. Later when I started my graduate thesis I picked this up and continued to improve and complete it.

Today, this graph drawing subsystem is closed to being stable. It offers TikZ options to select and configure the graph drawing algorithms available in the PGF repository as well as data structures and algorithms to help with implementing new drawing algorithms.

Implementing a new algorithm is as simple as creating a .lua file in the PGF tree and implementing a single function (although I am about to change this so that a class needs to be implemented rather than a function). After that, users can select your algorithm and if you create another file in the PGF tree, you can even specify graph, node and edge parameters for them to configure.

Creating a new algorithm

Again, in order to create a new graph drawing algorithm, all you need to do is create a .lua file in the PGF tree. The graph drawing subsystem resides in the generic/pgf/graphdrawing directory which is divided into two subdirectories called algorithms and core. The core directory contains all the internals and data structures while the algorithms directory holds all the graph drawing algorithms. The algorithms tree is further subdivided into directories for the different classes of algorithms, namely force (for force-based algorithms), layered (for layered drawing algorithms), trees (for graph drawing algorithms related to trees) and misc (for stuff we didn’t know how to classify it).

To demonstrate the procedure of creating a new algorithm, we are going to create a new misc algorithm by creating a file

generic/pgf/graphdrawing/algorithms/misc/pgfgd-algorithm-simple-demo.lua

with the following content:

pgf.module("pgf.graphdrawing")
 
--- A trivial node placing algorithm for demonstration purposes.
--
-- All nodes are positioned on a circle with a user-defined radius.
--
function drawGraphAlgorithm_simple_demo(graph)
  local radius = tonumber(graph:getOption("/graph drawing/simple demo/radius"))
  local nodeCount = table.count_pairs(graph.nodes)
  local alpha = (2 * math.pi) / nodeCount
  local i = 0
  for node in table.value_iter(graph.nodes) do
    -- the interesting part...
    local node_radius = tonumber(node:getOption('/graph drawing/simple demo/node radius') or radius)
    node.pos:set{x = node_radius * math.cos(i * alpha)}
    node.pos:set{y = node_radius * math.sin(i * alpha)}
    i = i + 1
  end
end

Let us quickly walk through the code to get an understanding of the concepts involved:

  • The first line tells PGF to import the graph drawing Lua module. This makes all data structures and functions of the graph drawing available in the script.
  • The function drawGraphAlgorithm_simple_demo() is the entry point to our algorithm. In PGF/TikZ the algorithm will be known by a more readable name: simple demo. The Lua file and the function have to be named consistently to make this work.
  • The function takes a single argument called graph. This is an instance of the Graph class shipped with PGF/TikZ. It holds nodes and edges and provides a number of useful methods to manipulate them, iterate over them etc.
  • Our algorithm places nodes in a circle with a user-defined radius. Thus, in the first line of the algorithm, the /graph drawing/simple demo/radius option is retrieved from the graph object. This option is defined in a different file but we’ll get to that later.
  • Once we have the radius, we can count the nodes, iterate over all of them and place them on the circle where they belong. Note that all values are assumed to be in points, so if the desired radius is 1cm, the value of radius would be something like 28.35.

Basically, everything a graph drawing algorithm is supposed to do is take a graph and set the positions of all nodes to something that makes sense. (This is not entirely correct. Some algorithms may also want to bend edges so that they don’t cross nodes etc. but this is not covered here.)

Defining algorithm parameters for graphs, nodes and edges

I promised to talk about how to define and pass parameters which will lead us to the final syntax for using the algorithm in TikZ. Each class of algorithms (force, layered, misc etc.) forms a so-called TikZ library (graphdrawing.force, graphdrawing.layered, graphdrawing.misc etc.). This way people are not forced to load everything. Instead, they can choose what to include and what not to include in their TeX document. For misc algorithms, this library is defined in the following file:

generic/pgf/graphdrawing/algorithms/misc/pgflibrarygraphdrawing.misc.code.tex

This is where graph, node and edge parameters are defined. For our simple algorithm this would look as follows:

\pgfgddeclarealgorithmkey{simple demo}{simple demo}{algorithm=simple demo}
 
\pgfgdset{
  simple demo/.cd,
  radius/.graph parameter=evaluate math expression,
  radius/.parameter initial=4cm,
  node radius/.node parameter=evaluate math expression
}

The above lines define:

  • A graph drawing algorithm called simple demo. The first argument for \pgfgddeclarealgorithmkey is the name of the algorithm in PGF/TikZ. The second argument is the algorithm family. Sometimes different algorithms take the same parameters and this way the parameters can be defined once and be re-used in all of these algorithms. We do not need this in our simple case and so the family key is set to the algorithm name. The third and last parameter can be used to execute any kind of code allowed in PGF keys. We want to set the graph drawing algorithm to simple demo, which will make PGF/TikZ load our Lua file. We could also set default values for parameters here.
  • Inside the \pgfgdset call we first switch into the algorithm family. Then, we define two parameters: one to be passed to the \graph macro and the other to be passed to nodes using the [] option syntax. Both parameters may be complex mathematical expressions (with optional units). By using evaluate math expression, we leave it to PGF/TikZ to resolve the expression and convert it into points. The general rule to follow here is to leave all parsing to PGF/TikZ and pass values down to the algorithm that are ready to be used in Lua. The radius parameter has a default value set to 4cm which is automatically passed to the algorithm unless the user defines a custom value in the description of the graph.

This is it. There are other ways to define algorithms, families of algorithms and algorithm parameters and those will be covered in detail in the updated PGF manual. In order to understand the basic idea of the graph drawing subsystem, the above information should be sufficient.

Using the new algorithm

Having written a simple graph drawing algorithm the next, obvious question is: how to use it? An brief explanation follows, again using a basic example:

\usemodule[tikz]
\usetikzlibrary[graphs,graphdrawing,graphdrawing.misc]
\starttext
\startTEXpage
\starttikzpicture
  \graph [simple demo={radius=1cm},nodes={draw,circle}] {
    a -> b -> c -> d [simple demo={node radius=2cm}] -> e -> a
  };
\stoptikzpicture
\stopTEXpage
\stoptext

Again, we have to load the graphs library for the graph syntax. We also need to load the graphdrawing library which will pull in graph drawing subsystem. Finally, we need to load graphdrawing.misc to have access to the simple demo algorithm and its parameters.

We select the algorithm by typing \graphs [simple demo]. The part where the radius is set to 1cm can be omitted if the default value proves to be fine. The node d is altered to have a different radius by setting the corresponding node parameter to 2cm. Here is the result:

And that’s it.

Conclusion

With this graph drawing framwork in place we have plenty of opportunities to implement various kinds of graph drawing algorithms and experiment with new ideas. Creating an algorithm and making it available in TikZ is easy once you get used to it, making PGF/TikZ one of the most flexible and developer-friendly graph drawing systems out there.

In the next post

In my next article I will demonstrate the algorithms that were implemented as part of my graduate thesis. These algorithms are comparable with those shipped with Graphviz and Mathematica and are useful for many graphs and work well with grids, symmetric graphs, flow charts, flow networks and state machines/automata. Stay tuned!

- page 1 of 2