The solution is to set the network manager to send a command to XBMC to scan the video sources when the network comes up.

You need to place the following script in /etc/network/if-up.d/. Each script in this folder is called on network up. This script sends a JSON request to XBMC to scan all video sources for new content. You may need to change the user, password or the port if you changed them in the XBMC settings. This are the default settings.

#!/bin/bash
 
# Don't run if the loopback device comes up
[ "$IFACE" != "lo" ] || exit 0
 
# Send JSON command to XBMC to scan video sources
/usr/bin/wget --header="Content-Type: application/json" --post-data="{\"jsonrpc\": \"2.0\", \"method\": \"VideoLibrary.Scan\"}" http://xbmc:xbmc@127.0.0.1:9090/jsonrpc --spider

To install this script you need to ssh into the Pi and place it in /etc/network/if-up.d/xbmcupdate. Now you can enjoy your latest downloads linux distributions without any hazzle.

Alles begann als ich Anfang des Jahres bei heise online mal wieder über Google Summer of Code las. Ich wollte schon immer meinen Teil zum Projekt Gnome beitragen und so etwas an die Gemeinschaft zurückzugeben. Ich benutze den Desktop nun schon seit mehr als vier Jahre. Also fing ich an im Wiki von Gnome ein wenig herumzustöbern und stieß auf eine Seite mit Ideen zum diesjährigen Google Summer of Code. Nach längerer Überlegung dachte ich mir, ich versuch es einfach einmal bei Anjuta.

Anjuta ist eine IDE, die das Leben eines Programmierers erleichtern soll. Eine IDE beherbergt in der Regel viele nützliche Werkzeuge, sodass man beim Programmieren nicht durch Trivialitäten abgelenkt oder gar aufgehalten wird. Ein Beispiel wäre das markieren von Syntaxfehlern. Auch Programmierer sind nur Menschen und machen somit auch Leichtsinnsfehler indem sie sich vertippen oder einfach ein Zeichen vergessen. Die IDE markiert diese Fehler und macht damit den Programmierer darauf aufmerksam. Dadurch werden sehr viele Fehler im Vorhinein verhindert.

Projekt gefunden – was nun? Als Mentor für das Projekt Anjuta wurde Johannes Schmid angegeben. Zudem fand ich die Entwickler-Mailingliste von Anjuta heraus und trug mich auch gleich dort ein. Mein Englisch ist nicht gerade das beste und nun soll ich eine E-Mail in Englisch verfassen? Natürlich war das für mich eine der größten Hürden bei der Teilnahme an Google Summer of Code. Dennoch wagte ich mich dran und so folgte eine kurze E-Mail, mit der ich mein Interesse kundgetan hatte. Johannes antwortete mir innerhalb von zwei Stunden und erklärte mir, dass ich als erstes etwas zum Projekt beitragen sollte. Das einfachste wäre einen kleinen Bug zu beheben. Damit soll sichergestellt werden, dass ich es ernst meine.

Ich behebte also einen kleinen Bug und konnte somit auch gleich den Quelltext von Anjuta ein wenig kennen lernen. Ich hatte zuvor schon von der Uni aus mit ein paar Kommilitonen ein größeres Programm geschrieben, jedoch war Anjuta das bisher größte Projekte und hatte dementsprechend auch mehr Zeilen Code, mehr Klassen und demzufolge auch mehr “Infrastruktur”.

Anschließend suchte ich mir ein Thema aus, das ich über die nächsten drei Monate ausarbeiten werde. Ehrlich gesagt, ist mir nichts dazu eingefallen, allerdings gab es bereits einen Vorschlag von Johannes auf der Gnome-Wikiseite, auf der alle Google-Summer-of-Code-Projekte von Gnome aufgelistet wurden. Dort stand etwas von “Clang“.

Clang ist ein Frontend vom LLVM Compiler. Wie auch der GNU Compiler (kurz: GCC) übersetzt der LLVM Code von den Programmiersprachen C, C++ Objective-C und Objective-C++ in Maschinencode. Das ist längst nicht alles. LLVM bringt auch viele Werkzeuge mit, die es ermöglichen, den Quelltext nach Fehlern zu durchsuchen und den Programmierer beim compilieren darauf aufmerksam zu machen. Das macht LLVM sehr effizient und in manchen Bereichen sogar besser als der GCC. Mit Clang können nun Programmierer auf diese Funktionalität vom LLVM zurückgreifen und sie mit ihren Programmen kombinieren.

In meiner offizielle Bewerbung schrieb ich kurz etwas zu meiner Person und erklärte anschließend, wie Clang Anjuta bereichern kann. Dabei werden mehr Fehler von der IDE erkannt und der Programmierer kann diese gleich bei der Entstehung korrigieren. Dies hat zur Folge, dass in den Programmen weniger Fehler vorliegen und somit wird die Qualität der einzelnen Programmen gesteigert. Außerdem verbringt der Programmierer weniger Zeit mit Fehlerbehebung vom Code, was mehr als die Hälfte beim Programmieren aus macht. Diese Zeit kann also in neue Funktionen gesteckt werden, was wiederum den Endbenutzer glücklich macht. Mit diesem Vorhaben schlage ich also mehrere Fliegen auf einmal.

Es verstrich ein wenig Zeit bis ich die Zusage an Google Summer of Code bekommen hatte. Das Programm war in mehreren Phasen eingeteilt. Die erste Phase war die Community-Phase, in der man die Menschen hinter den Nicknames kennen lernen soll. Dazu gehört natürlich auch, dass man sich selber vorstellt und über den ganzen Zeitraum des Projektes hinweg Berichte schreibt, in denen man den aktuellen Stand der Dinge, sowie Probleme und eventuell auch deren Lösungen beschreibt. Meine Berichte hatte ich auf meinem Blog verfasst, die wiederum über Planet Gnome publiziert wurden. Daneben richtete ich eine Seite im Gnome-Wiki ein, die über das Projekt hinweg immer aktuell gehalten wurde.

Wie bei jedem neuen Projekt ist auch bei Anjuta aller Anfang schwer. Man muss sich in den Quellcode einlesen. Dazu gehört auch das Lesen von Dokumentationen, die Handhabe von Bibliotheken wie beispielsweise GLib und Allgemein das objektorientierte Programmieren mit einer Programmiersprache C, die ursprünglich dafür gar nicht ausgelegt wurde. In dieser Phase lernte ich unglaublich viel über allerlei Dinge und genau das ist auch der große Pluspunkt bei Google Summer of Code.

Der Rest ist Geschichte. Mein ursprüngliches Ziel Clang nach Anjuta zu bringen, konnte ich leider nicht erreichen, jedoch habe ich eine gute Grundlage dafür gelegt und habe auch die Absicht, das Plugin in naher Zukunft fertig zu schreiben. Nichtsdestotrotz habe ich unter der Haube von Anjuta vieles vereinfacht und zusammengelegt, was die meiste Zeit meines Projektes in Anspruch genommen hat. Es ist nun leichter ein Plugin für eine Programmiersprache zu schreiben als zuvor. Zudem sind nun Eigenschaften wie zum Beispiel das automatische hinzufügen von einer schließenden Klammer ‘)’ nach der Eingabe einer offenen Klammer ‘(‘ für alle unterstützten Programmiersprachen von Anjuta vorhanden. Auch das Verhalten ist jetzt überall gleich.

Ich für meinen Teil Bereue es nicht, dass ich an diesem Programm teilgenommen habe. Ich konnte dadurch sehr viel neues Lernen, zumal ich mich mittlerweile im Quelltext von Anjuta größtenteils auskenne und ich auch Vorhabe dem Projekt weiterhin Code beizusteuern, sofern ich genügend Zeit finde.

I have many new ideas for Sudowars, but I don’t know when I will find the time for it. Meanwhile, you can play the multiplayer.

Thus after finish merging same code of the language support plugins I hadn’t find many time to write the Clang plugin. As you can see my code this plugin isn’t complete, but it’s a good base to complete it.

Unfortunately I won’t have time for Anjuta in the near future, because I have to write some exams and add some new feature to my other project Sudowars, which is open source since a couple of weeks. But I’m going to complete the Clang plugin and fix some bugs in Anjuta.

My thanks goes to the Anjuta team and specially on my mentor Johannes. They helped me a lot and I learned many things during Google Summer of Code. I would do it again at any time.

The new architecture of the language support plugins

Now all same behaviour of the language plugins like when you start typing and got proposals are merged to one code base. The language support plugins implement their language-specific code through the new subinterface IAnjutaLanguageProvider.

The support class AnjutaLanguageProvider uses this implemented interface and executes the mechanism, which is all the same in each language support plugin. Additionally the language support plugins implement the IAnjutaLanguageProvider with the methods of AnjutaLanguageProvider. It’s a little bit complicated, but look at the examples below.

I have one bad news: The vala plugin doesn’t use the new architecture yet, because there are some problems with generating the GIR files, which I couldn’t solve in the last week.

Implementation of preference keys

The following keys have to be implemented as boolean in a GSetting file:

• calltip-enable
• completion-enable
• completion-space-after-func
• completion-brace-after-func
• completion-closebrace-after-func

Implementation of IAnjutaProvider

assist->lang_prov is an AnjutaLanguageProvider object.

static void
iprovider_activate (IAnjutaProvider* self,
                    IAnjutaIterable* iter,
                    gpointer data,
                    GError** e)
{
	LanguageAssist* assist = LANGUAGE_ASSIST (self);
	anjuta_language_provider_activate (assist->lang_prov, self, iter, data);
}
 
static void
iprovider_populate (IAnjutaProvider* self,
                    IAnjutaIterable* cursor,
                    GError** e)
{
	LanguageAssist* assist = LANGUAGE_ASSIST (self);
	anjuta_language_provider_populate (assist->lang_prov, self, cursor);
}
 
static const gchar*
iprovider_get_name (IAnjutaProvider* self,
                    GError** e)
{
	return _("Language name");
}
 
static IAnjutaIterable*
iprovider_get_start_iter (IAnjutaProvider* self,
                          GError** e)
{
	LanguageAssist* assist = LANGUAGE_ASSIST (self);
	return anjuta_language_provider_get_start_iter (assist->lang_prov);
}
 
static void
iprovider_iface_init (IAnjutaProviderIface* iface)
{
	iface->activate            = iprovider_activate;
	iface->populate            = iprovider_populate;
	iface->get_name            = iprovider_get_name;
	iface->get_start_iter      = iprovider_get_start_iter;
}

Implementation of IAnjutaLanguageProvider

static GList*
ilanguage_provider_get_calltip_cache (IAnjutaLanguageProvider* self,
                                      gchar* call_context,
                                      GError** e)
{
	/* language-specific code */
}
 
static gchar*
ilanguage_provider_get_calltip_context (IAnjutaLanguageProvider *self,
                                        IAnjutaIterable *iter,
                                        GError** e)
{
	/* language-specific code */
}
 
static void
ilanguage_provider_new_calltip (IAnjutaLanguageProvider* self,
                                gchar* call_context,
                                IAnjutaIterable* cursor,
                                GError** e)
{
	/* language-specific code */
}
 
static IAnjutaIterable*
ilanguage_provider_populate_language (IAnjutaLanguageProvider* self,
                                      IAnjutaIterable* cursor,
                                      GError** e)
{
	/* language-specific code */
}
 
static void
ilanguage_provider_iface_init (IAnjutaLanguageProviderIface* iface)
{
	iface->get_calltip_cache   = ilanguage_provider_get_calltip_cache;
	iface->get_calltip_context = ilanguage_provider_get_calltip_context;
	iface->new_calltip         = ilanguage_provider_new_calltip;
	iface->populate_language   = ilanguage_provider_populate_language;
}

When you call ianjuta_editor_assist_proposals () you have to set the elements of the proposal list in the right way:

GList* list = NULL;
IAnjutaEditorAssistProposal* proposal = g_new0 (IAnjutaEditorAssistProposal, 1);
AnjutaLanguageProviderProposalData* data = g_new0 (AnjutaLanguageProviderProposalData, 1);
 
/* set data->name, data->is_func and data->has_para */
 
proposal->data = data;
list = g_list_append (list, proposal);

The basis is this:

git whatchanged --since="1 week ago" --format=oneline | grep "^:" | \
sed 's:.*[DAM][ \\''t]*\([^ \\''t]*\):\1:g'

I want to see, if a file was modified, attached or deleted, therefore I left the letters M, A and D and, in addition to that, I replaced the tab after the letter with a space:

git whatchanged --since="1 week ago" --format=oneline | grep "^:" | \
sed ''/.*A\\t/s::A\ :g'' | \
sed ''/.*M\\t/s::M\ :g'' | \
sed ''/.*D\\t/s::D\ :g''

But we live in the year 2012, so we need color:

git whatchanged --since="1 week ago" --format=oneline | grep "^:" | \
sed ''/.*A\\t/s//`printf "\033[33mA\033[0m"`\ /'' | \
sed ''/.*M\\t/s//`printf "\033[32mM\033[0m"`\ /'' | \
sed ''/.*D\\t/s//`printf "\033[31mD\033[0m"`\ /''

I don’t want to see duplicate entries. The next is to delete the duplicate entries:

git whatchanged --since="1 week ago" --format=oneline | grep "^:" | \
sed ''/.*A\\t/s//`printf "\033[33mA\033[0m"`\ /'' | \
sed ''/.*M\\t/s//`printf "\033[32mM\033[0m"`\ /'' | \
sed ''/.*D\\t/s//`printf "\033[31mD\033[0m"`\ /'' | \
awk '!x[$0]++'

This method has one problem: The list could have two or even three entries of one file. One for modifiy, attach and delete. If you prefer to see only the latest action on this file, you can use awk '!x[$2]++' instead of the last awk command.

Now we only have to sort the list without being considerate to the action on the file:

git whatchanged --since="1 week ago" --format=oneline | grep "^:" | \
sed ''/.*A\\t/s//`printf "\033[33mA\033[0m"`\ /'' | \
sed ''/.*M\\t/s//`printf "\033[32mM\033[0m"`\ /'' | \
sed ''/.*D\\t/s//`printf "\033[31mD\033[0m"`\ /'' | \
awk '!x[$0]++' | sort --key=2

The command executed on my parser branch:

The grouping of multiple instances/windows of a single application makes perfect sense and removes clutter from the user’s workspace.

So what’s wrong with it?

Its implementation! Basically tabs are nothing but window management + radio buttons. Somehow toolkit developers started to implement their own tabbed view and handled the window management. Everybody who’s familiar with the X protocol (widely used under Linux/Unix) might have figured out already, what I’ll be complaining about.
X windows have properties. One of them is the window class. This window class property could allow a composite manager to provide a tab view. The tabview could provide a consistent look and feel accross toolkits and even expose tabs in a new (maybe even better) way. Seriously, all a window manager should be doing is handling windows/window groups. It’s not the job of a toolkit! Toolkits may proxy tabbing for platforms like Windows, but they shouldn’t implement their own!

Why are things the way they are right now?

I guess nobody can tell for sure. But I’d put my bet on a situation where developers said: “Let’s implement our own tabview, so we’re more awesome than the others.”. And maybe they thought: “Our usecase for tabs is waaaay different than those of other applications.”. Really? If I had to guess I’d say you’d need a text preview (maybe even a livethumb) connected to a ‘show window’ like mechanism.

Are only application/toolkit developers to blame?

No, I think it’s mostly the fault of desktop environment/shell developers (I’m looking at you GNOME/KDE/Enlightenment/Cinnamon) who didn’t show off how nicely tabview/application could be done in a generic fashion yet a bit customizable for using apps.
I hope that will change and developers start to use infrastructure that is already there (e.g. PID+window class) instead of propagating inconsistency while making the world a ‘better’ place.

Maybe I’ll even get around to implement some prototype ‘generic tabbing’ for Enlightenment and it’ll gain traction and inspire developers of other desktop environments.

As an outlook of how I – personally – could imagine consistent tab experience, I’d like to refer to Clayton Miller’s concept, he presents at 10gui. It already takes the transition of modern input technologies from hard buttons to more touch-based into account.

From time to time it’s a little bit troublesome. For example yesterday the editor didn’t show the proposals for the word, which I started to type. I searched about six hours to find a solution for the problem. Finally I read the source code of given methods, which I used in my code and couldn’t find any documentation. I found out what each method does exactly and could solve the problem.

I hope that I finish my work on merging the language plugins very soon and devote my time to the real work: the clang plugin.

It doesn’t work! I try to open the menu and fail so literally everytime because it’s not there when the tool windows have the focus. However you will notice that when you already moved the mouse all the way up, because the f**king thing is hidden as long as the mouse is not over it.

I seriously hate this thing! This is the work of morons who do not use the computer for actual work. I have no other explanation for that.

For everybody like me, who believes window menus should be in the window they belong to:

sudo apt-get autoremove appmenu-gtk appmenu-gtk3 appmenu-qt


From now on this is the first thing I have to do on every Ubuntu machine I use.

This message was brought to you by the minstry of rants.

The Python preferences before and after

Additionally the vala plugin has its own preferences widget now. Before it used the preferences of the cpp-java plugin. As a consequence the Vala plugin no longer depends on the cpp-java plugin. While doing this work I learned, how I can integrate C interfaces in a plugin, which is written in Vala.

But the Vala plugin is not the only one which got an update. The Python plugin has the “Add ‘)’ after function call autocompletion” option now. With this new option the Python plugin has the same functionality as the other language plugins and so I made the preference widget looking like the preferences widget of the other plugins.

Moreover I added the new behaviour of C/C++ in Python and cleaned up the Python plugin a little bit for example of deleting unused variables.