Jedes Jahr winkt die Steuererklärung und das Ausfüllen von Papierbögen ist lästig, anstregend und letztlich auch nicht umweltfreundlich. Dafür hat sich die Finanzverwaltung ELSTER einfallen lassen, die elektronische Steuereklärung. Für Windows stehen dazu diverse Tools zur Verfügung, leider ist nicht mal das amtliche ElsterFormular Software für Linux zur Verfügung (obwohl es ein Qt-Programm ist), aber günstigerweise funktioniert sie unter WINE relativ problemslos.


  • Wine installieren: Fedora: sudo yum install wine, Ubuntu: sudo apt-get install wine, oder mit jeweiligem GUI-Programm
  • msttcorefonts (Microsoft TrueType fonts) installieren: Dafür gibt es verschiedene Möglichkeiten, unter Fedora hat mir dieses Skript geholfen, für Ubuntu gibt es diverse HowTos. Unbedingt notwendig ist der Schritt nicht, aber er verbessert die Lesbarkeit des Programms. Eventuell ist danach in Neustart (dex X-Window-Systems) notwendig.

PDF-Viewer installieren:

  • ElsterFormular erzeugt pdfs und zeigt diese sofort an, scheitert allerdings, wenn kein pdf-Viewer für Windows installiert ist, d.h. kein Programm mit dem Öffnen von pdf-Dateien verknüpft ist.
  • Letztlich kann man mit jedem pdf-Viewer Abhilfe schaffen, ich habe FoxIt-Reader benutzt. Einfach von der offiziellen Seite herunterladen und die Installation mit wine FoxitReader<verion>_enu_Setup.exe starten.

ELSTER installieren:

Soweit hat danach bei mir die Erstellung der Steuererklärung und die Übermittlung an das Finanzamt funktioniert. Nach der Übermittlung stürzt das Programm leider beim Drucken der Erklärung ab – eine Druckvorschau ist beim nächsten Start über Drucken -> Druckvorschau der komprimierten Steuererklärung möglich.

In case you (still) own a Samsung NC10 netbook and suspend stopped working with Fedora 15 there is a pretty simple workaround:

Enable “EDB (Execute Disable Bit)” in the Advanced BIOS options which will enabled DEP and as a side-effect magically make your NC10 wakeup currently after suspend.

I personally also updated to the latest BIOS version but it is not sure if that is necessary. See the bug report for details.


The browser myth

11. October 2010

(In reply to Henri’s post)

Most people will probably answer that the web browser is the application they use most often. That might be true, but is it the application they spent their time with when they are working? I certainly hope not!

So, let’s dive a bit more into the topic and think about what people are doing during their work hours:

  • Acquiring information: web browser, PDF, Image viewer
  • Communication: Mail client, Phone, IM (no, people are not using GMail for their work mail, believe me, they use Outlook or Lotus Notes usually)
  • Creating content/working: Office applications, specialised software (CAD, Software development, publishing, etc.)

I haven’t made any statistics of course but I feel this boils down to about 20% acquiring information, 30% communication and 50% creating content or at least this is probably what your employer wants you to do. Basically that would mean you only spent maximum of 20% of your time with web browsing while of course the web browser might be open in the background all the time.

Windows doesn’t have a 90% market share because it integrates the web but because it has an ecosystem that provides all this other stuff people need to do.

That doesn’t mean we shouldn’t be working on better integration on web applications or the web in general but we must know that our target audience is most likely not the professional desktop. There are reasons why many people have a MacBook but work with Windows in their company. There are reasons why people use their iPhone for web stuff only but still have a Windows PC at home. It is because besides all the cloud discussion taking place nearly nobody is creating content with web applications that isn’t made for the purpose of web publication.

If you have statistics, prove me wrong, please! Maybe the company I am working at is totally unrepresentative…

Update: Many peopple comment that they use GMail and Google Office Apps for their work. I doubt that this is general true. Most people reading my blog (or more likely Planet GNOME) are probably geeks or working in a very computer oriented environment.

However, I didn’t look at what apps I am using most but what the people I work with in an engeering department use most. They usually have about 5-20 windows open at a time where the browser is one of them while the work in Microsoft Word or Excel most of the time.

Maybe there are also big differences between Europe and other parts of the world because people and companys here are caring about privacy and data security a lot and therefore don’t move their important data and mail into the cloud and therefore aren’t using Google Apps.

I also really wonder if you all use the web browser for programming. I have never seen someone using a browser based Eclipse, Emacs or Vim even on very geeky conferences. And if programming is your job I certainly hope this is where you spent most of your time.

Sorry, this is going to be a rant…

Some distributions like Ubuntu tend to have their own bugtracker for all packages and people will report bugs there (in this example This is not a bad thing in general as it might be possible to generate better debugging info if you know the exact binary package.

This requires bugs to be added upstream though because no developer will ever have a look in downstream bug trackers. For core packages of a distribution that has the manpower to do this that should be OK and as those packages might be patched in some way it might be useful to report bugs downstream and decide manually if and how to report them upstream.

However for packages where there is nobody to review the downstream bugs I would really prefer if the downstream bug-tracker will just forward the bug to the upstream bug-tracker (probably doing some internal duplicate filtering in between).  I am more happily getting some incomplete bug reports than missing  the interesting ones because they never reach the upstream tracker.

So, launchpad developers: Do you think that’s doable. There are so many great options in launchpad that I think adding this one shouldn’t be too difficult. By accident I stumbled across some very interesting reports in launchpad and I would have loved to have these reports upstream.


As Murray already mentioned we updated the Clutter Tutorial over the last weeks for the upcomming Clutter 0.9/1.0 release. Clutter 0.9 makes some hacks obsolete that were necessary to archieve some functionality in the past so we could concentrate more on straight-forward ways this time.

The tutorial features some new sections:

  • The new GtkClutterViewport widget allows scrolling of GtkClutterEmbed widgets and is decribed in the new Stage Widget Scrolling section.
  • Some notes were added for using Timeline markers.
  • ClutterAnimation has replaced the obsolete ClutterEffects API and thus ended up in the new Animations section. This section also explains how to use ClutterAlpha properly.
  • The biggest new API is probably the new ClutterText widgets that allows use-cases from a simple label over a single-line entry to a full-featured multi-line text input box.

Unfortunately some links to the API documentation are not working yet because the clutter-gtk API documentation for 0.9 is not yet available online. The tutorial is also available as pdf.

Development of the tutorial happens in the clutter-tutorial module on GNOME git.

So, from the little hacker in me I am a bit annoyed about forking strategies some projects have. I have been (co-)maintaing gdl for about 4 years know, brought it into GNOME, fixed lots of deprecated stuff and got rid of all the non-docking stuff in the library and lots of other people helped there.

Now what happend:

  • inkscape* has a fork of gdl that is probably quite old.  They made some additions that are probably useful
  • Niepce forked the inkscape fork
  • MonoDevelop made yet another fork of gdl, ported in to C# and dropped it again later

Nobody ever popup up in bugzilla, the mailing list or on IRC to ask if they could put some patch upstream that they needed. I am quite sure the upstream version fixes lots of problems still present in other versions and I am also sure the other versions contain some useful additions to gdl and that it would be no big deal to merge them. But as long as nobody from the projects steps up and says “Hey, here is our patch, can you have a look at it” it’s unlikely that upstream will ever be able to fill their needs. On the other hands they will never profit from upstream bug-fixes in any way.

* I think an inkscape dev once asked for a non-gnome version of gdl which was added later (and is now obsolete as there are only gtk+/glib dependencies left). But there was no further conversation.

So, please STOP this!

Act like Joel Holdsworth from the Lumiera Project. He poped up on the mailing list and said he would need gdl but would need some small additions. Afterwards he put in lots of patches, documentation updates and bug-fixes to make life easier for everybody.

That being said, both inkscape and Niepce are in C++ so it would make lots of sense for them to share a common gdlmm binding. Inkscape uses some non-standard binding method for gdl with lots of hand-written code.

Some people might say that gdl should be merge into gtk+. This may be done someday but gdl is not in a stage where it makes sense to consider it. It does a good job but it is far from perfect and it is even the question from a UI perspective if the averange application really needs to have such a heavy docking library in a general-purpose toolkit.

Some instructions here because the porting guide in the Gtk+ docs is quite short at the moment:

Convert the files

gtk_builder_convert <old_glade_file> <new_gtkbuilder_file>

Code changes

  • Remove #include <glade/glade.h>
  • GladeXML* => GtkBuilder*
  • glade_xml_new (FILE, “first_widget”, NULL) becomes

    GError* error = NULL;
    GtkBuilder* builder = gtk_builder_new();
    if (!gtk_builder_add_from_file (builder, FILE, &error)
    g_warning ("Couldn't load builder file: %s", error->message);
  • glade_xml_get_widget (gxml, “widget_name”) becomes GTK_WIDGET (gtk_builder_get_object (builder, “widget_name”))
  • glade_get_widget_name (widget) can be replaced by gtk_widget_get_name(widget)
  • glade_xml_get_widget_prefix (gxml, “prefix”) can be emulated by gtk_builder_get_objects(builder) together with manual filtering. It returns a GSList* instead of a GList* though.

That’s it basically. Don’t forget to adjust your to install the correct files and update!

After reading the 3.0 plan of the release-team I was curious what the end-users would say. It is rather difficult to find out because there is no average end-user. Anyway, I tried to summarize opinions from two popular german computer magazines:

  • Heise-online: The biggest computer magazine in Germany (online and offline). They feature a rather big and detailed article on GNOME 3.0.
  • Pro-Linux News: This is a non-profit Linux News site. Their article is smaller and the Nerd-factor of the readers is certainly a bit higher here.

Apart from some more off-topic posts (GNOME vs. KDE, MacOS is the only real thing, etc.) on the Pro-Linux board the reactions were quite similar with those main points:

  1. Don’t make it a KDE 4.0! People rely on a stable desktop…
  2. This looks interesting and cool! GNOME really needed some revamp…
  3. Hmm, I cannot see why this is better than now – do we need it?

The rest of the comments are mostly based on misunderstandings (heise writes that “Zeitgeinst” will replace Nautilus which is simply untrue). Funny enough though, quite a lot of people comment that they liked our little steps in 2.x a lot which most sums up with point 1. These was much less critism than I expected actually and instead people applaud us for the work in the past years.

Of course this is no representative review about user comments, it is just a small limited summary (only German, people who are really interested in computing). In the end I think we seem to do well, but should mind the three points raised: Make it stable, make it cool, make it useful!

Yesterday, I started to implement Murray‘s/Mathias‘ idea to add the ability in GTK+ to add a widget beside the tabs of a notebook. This makes of course only sense in application where only a few notebook pages are used usually and there is a lot of space left in the tab area. But of course it will also allow to add little combo boxes in this area like Mozilla Firefox, to give the user some additional features for the notebook navigation.


The basic code is now in place and it is less complicated then I expected. Anyway, there is still some stuff to do:

  • Position of the widget (like GTK_PACK_START/END)
  • whether the widget should take the whole space available (GTK_EXPAND)

The API is pretty simple up to now and only consists of gtk_notebook_set_tab_widget (). Patch coming soon to your nearby bugzilla.

Anjuta 2.26.0 released

20. March 2009

file-treeSo, yeah, we relaesed another version some days ago. You may want to read the previous posts about the new features here. Most notibly in the final version was the addition of  version control information to the file viewer. You can now see the status of your files using an emblem system like the famous TurtoiseSVN for Windows. It is actually meant to also work for git and we hope to get this done very soon in the next stable versions. There are some bugs preventing it at the moment. Otherwise everybody has done a great job and we significantly reduced the amount of bugs (from about 120 to 70, exluding enhancements)

As usual you can get the lastest version here:

Another interesting thing for some people is probably a new alpha version of the vala plugin. It’s still a bit buggy and incomplete but I would invite some of the vala developers out there to try and improve it.  It’s completely written in Vala so you can have some fun in this area!

Happy coding!