Erlang GTK binding
Erlang C Python Makefile Shell
Switch branches/tags
Latest commit 6949309 Dec 28, 2015 @massemanet doc
Failed to load latest commit information.
bin sh is old, use bash instead Nov 2, 2015
doc dumping autotools, wip Oct 8, 2015
priv indent Dec 25, 2015
src v1.0.4 Dec 24, 2015
.gitignore Updated ignores. Dec 21, 2015
AUTHORS v1.0.4 Dec 24, 2015
COPYING initial upload to google Aug 29, 2006
ChangeLog v1.0.4 Dec 24, 2015
INSTALL fix readlink on mac Dec 1, 2015
Makefile doc Dec 28, 2015 doc Dec 28, 2015
rebar reintroduce rebar Oct 13, 2015
rebar.config harmonize rebar/makefile Oct 13, 2015


Yet Another GUI framework for Erlang


  • GUI separated from application by message passing
  • distributed (application and GUI can run on different machines)
  • centered around a GUI builder
  • small volume of (hand-written) code
  • pre-documented


A c-node (a daemon that implements the Erlang distribution protocol) that instantiates the GUI from a configuration file. The c-node sends messages to the Erlang node when the user interacts with the GUI; the Erlang application changes the state of the GUI by sending messages to widgets in the c-node. The widgets should look like Erlang processes with registered names. The protocol should look something like this:

CnodePid ! {aWidget,dosomething,Args}       % erlang->cNode
ApplicationPid ! {reply, Val}               % cNode->erlang
ApplicationPid ! {signal,aWidget,eventType} % cNode->erlang

In this example aWidget is the name given to a widget in the configration file. It can also be thought of as the registered name of the process implementing the widget in the c-node.

The c-node is responsible for garbage-collecting all temporary data.



The c-node is started thus;

gtknode node host regname cookie cnode-name otp-version

When started, gtknode will connect to it's application by sending a handshake message to {node@host, regname}.

The messsage looks like this;

{{GtkPid,handshake}, []}

The Erlang application sends messages to the gtknode using GtkPid. messages look like this:

list({'Gtk_function', [Args]})

E.g., if we have a GtkButton widget, named b1, and we want to use these functions:

const gchar* gtk_button_get_label (GtkButton *button);
void         gtk_button_set_label (GtkButton *button, const gchar *label);

we could send this:

GtkPid ! [{'Gtk_button_set_label',[b1,"foo"]},{'Gtk_button_get_label',[b1]}].

and we would receive this:

{{GtkPid,reply}, [{ok,void},{ok,"foo"}]}

Signals are sent from gtknode if the signal handler for a specified signal-widget combination is set to gn_sighandler. The signals look like this:

{{GtkPid, signal}, {atom(WidgetName),atom(SignalName)}}

E.g., if we delete the GtkWindow named window1 we'll get this signal:

{{GtkPid, signal},{window1,'GDK_DELETE'}}

Given that we've requested it, of course.


The file src/gtknode.erl implements a controller/middleman for the gtknode, it's quite instructive. It is recommended to use this instead of working directly against the c-node.

The priv/examples directory contains a few examples.



Stable since 2008