docs/pws2004/gtk2.pod

=encoding utf8

=head1 Gtk+2 - ein erweiterbares GUI-Toolkit

=head2 Abstract

Gtk+2 (das {{G}}IMP {{T}}ool{{K}}it, Version 2) unterlief bei der
Entwicklung zu Version 2 tiefgreifende Änderungen. Das Typsystem wurde
stark abstrahiert, so daß sich Schnittstellen zu anderen Sprachen im
wesentlichen auf das Bereitstellen des Objektsystems beschränken.

In diesem Dokument wird das Toolkit gtk+2 kurz vorgestellt, wobei
Erfahrung mit GUI-Programmierung vorausgesetzt wird. Im Wesentlichen geht
es darum, einige besondere Techniken vorzustellen sowie das Toolkit von
Perl und C aus selbst zu erweitern.

=head1 Gtk2 und Glib, eine Übersicht

=head2 Übersicht über die G-Module

Es gibt eine Menge Bibliotheken, deren Namen mit G anfängt und im
Dunstkreis von Gtk+ stehen. Vielleicht wäre es sinnvoll gewesen, eine neue
G-Hierarchie in Perl zu begründen, so muß man sich mit einer teilweise
nicht sehr logischen Namensgebung zurechtzufinden.

=over 4

=item Glib

Glib ist die Schnittstelle zur C<libglib> (sowie zu C<libgobject>,
C<libgmodule> und C<libgthread>). Es bildet die Grundlage für das Objekt-
und Typ- und Signalsystem, bietet Hilfsfunktionen zum Umwandeln von
Dateinamen, Logging usf.

=item Gtk2

Dieses Modul ist eine Sammelstelle für diverse Bilbiotheken: neben
C<libgtk+> auch C<libgdk>, C<libgdk_pixbuf> und C<libpango>.

Sie reicht für fast alle Anwendungen aus.

=item Gtk2::GLExt, Gtk2::GladeXML, Gtk2::TrayIcon und Gtk2::Spell

Bieten Integration von OpenGL, GladeXML, EggTryIcon und Spell-checking für
Text-Widgets.

=item Gnome2

Schnittstelle zur C<libgnome> und vielem mehr. Muss man nicht
benutzen, kann mir aber vorstellen, das sie für die Erstellung von
Gnome-Applikationen ganz nützlich sind :)

=item Gnome2::Canvas, Gnome2::GConf, Gnome2::PanelApplet, Gnome2::Print,
Gnome2::Rsvg, Gnome2::VFS, Gnome2::Vte, Gnome2::Wnck.

Jede Menge Gnome-Zeugs.

=back

=head2 Die Widgets von Gtk2 sind GObjects

Wie jedes andere Toolkit auch, bietet Gtk2 eine Menge vorgefertigter
I<Widgets>: I<Buttons>, I<Labels>, I<Frames> und andere "einfache"
Widgets, aber auch komplexe, wie das I<Text>- (komplett in Unicode,
einbettbare Objekte) oder das I<TreeView>- (Listen und Bäume im
MVC-Modell) Widget.

=begin latex

\begin{figure}[h]\includegraphics{gtk2-textwidget.png}\label{Das Text-Widget}\end{figure}

=end latex

Alle diese Widgets sind sogenannte I<GObjects> (davon abgeleitet sind
in Gtk2 dann sogenannte I<Widgets>, GUI-Objekte), und haben folgende
Features:

=over 4

=item Eine Klasse

Jedes GObject ist eine Instanz einer Klasse (C<GObjectClass>), eine
Datenstruktur, die Informationen über Methoden u.ä. speichert.

Eine C<GObjectClass> ist allerdings nur ein Spezialfall eines
C<GType>s: Die Glib bildet ein komplettes Typsystem mit Klassen,
Aufzählungen, Flags, einfachen Datentypen wie Integer oder
Fließkommazahlen oder auch C-structs an. All dies ist zur Laufzeit in
einer Form verfügbar, in der sich auch neue - zur Compielzeit nicht
bekannte - Datentypen verwenden lassen.

Schnittstellen für andere Sprachen werden dadurch einfach, da man
"lediglich" die Konzepte "Datentyp", "Konverter", "Klasse", "Methode",
"Bitset" usw. umsetzen muß. Konkrete Instanzen dieser Typen funktionieren
zur Laufzeit automatisch.

Bei einer gut geschriebenen C-Bibliothek, die auf Glib bzw. GObject
aufsetzt, muß man eigetnlich nur die Initialisierungsfunktion aufrufen,
die die Datentypen registriert, und kann dann sofort von Perl darauf
zugreifen - ohne eine einzige XS-Funktion geschrieben zu haben.

=item Methoden

Jedes GObjekt hat mindestens Methoden zum Erzeugen (C<constructor>)
und Zerstören (C<finalize>), Setzen und Lesen von Properties und eine
Spezialität von GObject - C<dispose>. Letzteres ist eine Art Anfrage an
ein Objekt, sich freiwillig aufzulösen.

Gtk2 fügt noch einige weitere hinzu, wie die C<destroy>-Methode, die aktiv
versucht, ein Objekt zu zerstören: In GUI-Programmen ist es manchmal
schwer, alle Referenzen im richtigen Moment aufzulösen, da sie häufig
zirkulär sind. Manche Objekte "leben" auch ganz eigenständig, z.B. wird
ein Toplevel-Fenster im allgemeinen vom Benutzer "referenziert", was sich
aber nicht notwendigerweise im Referenz-Zähler niederschlägt.

Um solche Objekte loszuwerden, kann man sie bitten, sich zu
I<destroyen>. Dabei gibt es alle Referenzen auf andere Objekte frei und
bittet diese, sich ebenfalls zu destroyen. Dadurch werden zirkuläre
Referenzen effektiv aufgebrochen.

Methoden kann man in Perl nicht direkt implementieren, dafür aber eigene
Signale, die beliebige Parameter oder Rückgabewerte besitzen können und
mehr oder weniger direkt von C oder anderen Sprachen aus aufgerufen werden
können.

=item Signale

Signale ähneln Methoden, Callbacks oder sogenannten "Delegates". Wie
Methoden sind sie fest an eine Klasse gebunden und rufen (in C) eine
Methode der Klasse auf, sobald sie ausgelöst werden.

Ein Signal kann von jedem ausgelöst werden, insbesondere lösen aber
Ereignisse (Events) in Gtk2 Signale aus. Der Signal-Handler eines Objektes
verarbeitet das Ereignis (und beendet die Signalauslieferung) oder tut
nichts, woraufhin Gtk2 ein anderes Objekt als Empfänger sucht.

Zusätzlich kann man vor oder nach dem eigentlichen Signal-Handler
des Objektes weitere Callbacks einklinken. Z.B. löst das Text-Widget
beim Mausklick rechts ein C<populate-menu>-Signal aus, das
normalerweise ein Popup-Menü generiert. Das kann man verändern oder
ganz überschreiben. Und wenn man Mausklicks abfangen möchte, kann man
das C<button-press-event>-Signal überschreiben und so Mausklicks vom
Text-Widget fernhalten.

=item Properties (Eigenschaften)

Properties sind von der jeweiligen Klasse definierte Eigenschaften, die
das Objektverhalten beeinflussen.

#TODO#

=item Schlüssel-Wert-Paare

#TODO#

=back

=head2 Leben und sterben lassen: Wie man seine Objekte wieder loskriegt

#TODO

=head2 Informationen über Typen und Klassen zur Laufzeit abfragen

Die Typinformationen, wie Werte von Aufzählungen, Namen von Datentypen,
Objekt-Signale, -Properties uvm., sind alle zur Laufzeit abfragbar.

Dadurch wird das Schreiben von Klassenbrowsern oder RAD-Tools serh
einfach. Aber auch beim Entwickeln von Programmen ist das nützlich, da man nicht immer
die Dokumentation zu Rate ziehen muss.

Z.B. liefert C<< $obj->list_properties >> (oder
C<Glib::Type::list_properties> Klassenname) eine Liste von Arrayrefs mit
Name, Typ, Flags und Beschreibung zurück, die man sich z.B. mit folgender
Funktion ausgeben lassen kann:

   use Gtk2;

   sub gobj_props {
      for ($_[0]->list_properties) {
         printf "%-16s %-24s %-24s %s\n", $_->{name}, $_->{type}, (join ":", @{$_->{flags}}), $_->{descr};
      }
   }

Der Aufruf C<gobj_props "Gtk2::Widget"> (oder mit einem
C<Gtk2::Window>-Object als Argument) liefert folgende Properties, die alle
Gtk2-Widgets besitzen:

   user-data        gpointer                 readable:writable
      Anonymous User Data Pointer
   name             Glib::String             readable:writable
      The name of the widget
   parent           Gtk2::Container          readable:writable
      The parent widget of this widget. Must be a Container widget
   width-request    Glib::Int                readable:writable
      Override for width request of the widget, or -1 if natural request should be used
   ...
   extension-events Gtk2::Gdk::ExtensionMode readable:writable
      The mask that decides what kind of extension events this widget gets
   no-show-all      Glib::Boolean            readable:writable
      Whether gtk_widget_show_all() should not affect this widget

Signale lassen sich ebenso abfragen:

   sub gobj_signals($) {
      # Signale haben Argumente und Parameter, daher Dumpvalue
      use Dumpvalue;
      Dumpvalue->new (bareStringify => 0)->dumpValue ($_)
         for Glib::Type->list_signals ($_[0]);
   }

   gobj_signals "Gtk2::Widget";

   ...
   'signal_id' => 23
   'signal_name' => 'button-press-event'
   'itype' => 'Gtk2::Widget'
   'param_types' => ARRAY(0x83b4f28)
      0  'Gtk2::Gdk::Event'
   'return_type' => 'Glib::Boolean'
   'signal_flags' => [ run-last ]
      -> 2
   ...

Das C<button-press-event>-Signal möchte also ein Event als einziges
Argument und liefert einen Wahrheitswert.

Die Abstammung von C<Gtk2::Window> ist schnell gefunden:

   warn join " ", Glib::Type->list_ancestors ("Gtk2::Window");
   Gtk2::Window Gtk2::Bin Gtk2::Container Gtk2::Widget
      Gtk2::Object Glib::Object at gtk.pl line xx.

   # und list_interfaces wollte ich auch erwähnen:
   warn join " ", Glib::Type->list_interfaces ("Gtk2::Window");
   Gtk2::Atk::ImplementorIface at gtk.pl line xx.

Wenn man gtk+ von C her kennt (oder eben die C-Dokumentation benutzt),
kann man aus dem C-Typnamen den Namen in Perl erfahren:

   warn Glib::Type->package_from_cname ("GtkWindowPosition");
   Gtk2::WindowPosition at gtk.pl line xx.

   warn Glib::Type->package_from_cname ("GdkPixbuf");
   Gtk2::Gdk::Pixbuf at gtk.pl line xx.

Aufzählungen und Flags kann man ebenso hinterfragen:

   sub g_vals($) {
      for (Glib::Type->list_values ($_[0])) {
         printf "%-30s %s\n", $_->{name}, $_->{nick};
      }
   }

   g_vals "Gtk2::Gdk::EventMask";

   GDK_EXPOSURE_MASK              exposure-mask
   GDK_POINTER_MOTION_MASK        pointer-motion-mask
   ...
   GDK_SCROLL_MASK                scroll-mask
   GDK_ALL_EVENTS_MASK            all-events-mask

=head3 Aufzählungen und Flags

Natürlich kann man zur Laufzeit auch eigene Typen hinzufügen. Z.B. ein
neuer Flag-Typ:

   Glib::Type->register_flags (Meine::Flags =>
      'eins',            # implizit 1<<0
      'zwei',            # implizit 1<<1
      ['drei' => 15 ],   # explizit 15
      ['vier' => 35 ],   # explizit 35
      'fuenf',           # implizit 1<<4
   );

Diese neuen Typen sind gleichwertig zu den vorhandenen, können also von C
oder anderen Programmiersprachen aus benutzt werden.

Aufzählungen und Flags sind in Perl überladen. Das ist besonders hilfreich
in Event-Handlern:

   $widget->signal_connect (button_press_event => sub {
      if ($_[1]->type eq "button-press") {
         if ($_[1]->button == 1) {
            if ($_[1]->state == "shift-mask") {
               # Umschalt-Klick
            if ($_[1]->state * "shift-mask") { # oder '&'
               # Umschalt-Klick (eventuell plus anderen Modifiern)
            if ($_[1]->state * ["control-mask", "shift-mask"]) { # oder '&'
               # Klick + Umschalt ODER Strg (eventuell plus anderen Modifieern)
            if ($_[1]->state >= ["control-mask", "shift-mask"]) {
               # Klick + Umschalt UND Strg (Übermenge)

Oder beim Manipulieren von Event-Masken:

   $widget->set (events =>
      $widget->get ('events') - [qw(key_press_mask button-motion-mask)]
   );

Auch eigene Klassen sind möglich, siehe Teil 2 :)


=head2 Beispiel: Session-Management

Häufig gibt es in C sogenannte I<convinience methods>
("Bequemlichkeitsfunktionen"). Sofern sie sinnvoll sind, wurden sie
bei Glib und Gtk2 umgesetzt. So gibt es z.B. eine C<set_events>- und
eine C<add_events>-Methode, die bei Gtk2-Widgets die Event-Maske
verändert. Doch für alle Properties kann man die generischen C<set>- und
C<get>-Methoden verwenden.

Damit läßt sich ein einfaches Session-Management schreiben:

   use Scalar::Util;

   my %get = (
      window_size     => sub { [ ($_[0]->allocation->values)[2,3] ] },
      column_size     => sub { $_[0]->get ("width") || $_[0]->get ("fixed_width") },
      modelsortorder  => sub { [ $_[0]->get_sort_column_id ] },
   );

   my %set = (
      window_size     => sub { $_[0]->set_default_size (@{$_[1]}) },
      column_size     => sub { $_[0]->set (fixed_width => $_[1]) },
      modelsortorder  => sub { $_[0]->set_sort_column_id (@{$_[1]}) },
   );

   my $state = Storable::retrieve "session.dat"; # Alte Session-Daten laden
   my %widget;

   sub state {
      my ($widget, $class, %attr) = @_;

      while (my ($k, $v) = each %attr) {
         $v = $state->{$class}{$k}
            if exists $state->{$class} && exists $state->{$class}{$k};

         $set{$k} ? $set{$k}->($widget, $v) : $widget->set ($k => $v);
      }

      $widget{$widget} = [$widget, $class, \%attr];
      Scalar::Util::weaken $widget{$widget}[0];
   }

Naja, I<gaanz> so einfach ist es nicht: Man kann damit shcon recht viel
anfangen, und es sind zugegebenermaßen mehr als drei Zeilen.

Was macht der Code? Es gibt Eigenschaften, die man über eine Session
hinweg retten möchte, aber keine Properties sind. Für diese Eigenschaften
(z.B. C<window_size>) definiere ich eigene C<set>- und C<get>-Funktionen.

Die Eigentliche Schnittstelle ist die C<state>-Funktion. Sie wird so benutzt:

   my $window = new Gtk2::Window;
   state $window, "game::window", window_size => [600, 500];

   my $hpane = new Gtk2::HPaned;
   state $hpane, "game::hpane", position => 500;

Diese beiden Widgets werden in einem (nicht sehr fiktiven) Go-Programm
benutzt um ein Spiel darzustellen. Der erste Aufruf von C<state>
sagt: Beim Widget vom Typ C<game::window> (ein willkürlicher Name) soll
die Property C<window_size> von einer Session in die nächste Übertragen
werden. Falls keine Sessiondaten existieren, nimm als Default C<[600,
500]>. Der zweite Aufruf macht das gleiche für die C<Position>-Property
des C<Gtk2::HPaned>-Widgets.

Beides Zusammen sorgt dafür, daß neue Spielfenster in der gleichen
Größe erscheinen wie bei der letzten Benutzung und daß die horizontale
Unterteiling (links Spielbrett, rechts Chat-Bereich) ebenfalls erhalten
bleibt.

In der Realität benutze ich eine etwas erweiterte C<state>-Funktion mit
einem C<$instance>-Argument: manche Benutzer möchten z.B. verschiedene
Chat-Räume in verschieden großen Fenstern darstellen. Das zusätzliche
Argument dient der Unterscheidung: Wird ein neuer Raum betreten, werden
die Werte des Raum-Typs benutzt, wird ein bekannter Raum betreten, werden
dessen bekannte Werte benutzt.

Die Funktion liest übrigens nur Werte aus den Sessiondaten C<$state> aus,
aber irgendwie müssen sie auch dort abgelegt werden. Dies geschieht in
meinen Programmen meistens durch Benutzeraufforderung: der Benutzer stellt
sein gewünschtes Layout zusammen und drückt dann C<Layout Speichern> o.ä.,
worauf dann folgende Funktion aufgerufen wird.

   sub save_state {
      for (grep $_, values %widget) {
         my ($widget, $class, $attr) = @$_;
      
         next unless $widget; # widget schon tot...
         $widget->realize if $widget->can ("realize");

         while (my ($k, $v) = each %$attr) {
      
            $state->{$class}{$k} =
               $get{$k} ? $get{$k}->($widget) : $widget->get ($k);
         }
      }  

      Storable::nstore $state, "session.dat";
   }        

Sie geht alle Widgets durch, die mit C<state> behandelt wurden, prüft, ob
sie noch existieren, sorgt (mit C<realize>) dafür, daß die Eigenschaften
auch mit sinnvollen Werten gefüllt sind, und speichert dann die
entsprechenden Eigenschaften in C<$state>.

=head2 Beispiel: Rapid Application Development mit Glade - mein Weg

Ich will es nicht verschweigen: Ich I<HASSE> GUI-Programmierung. Nichts
ist langweiliger bzw. nerviger, als Dialogboxen zusammenzustöpseln oder
Widgets in der Hierarchie zu verschieben.

Glücklicherweise gibt es RAD-Tools, mit denen man sich seine Applikation
zusammenklicken kann. Was mich an RAD-Tools allerdings stört ist ihre
Starrheit: meistens wollen sie gleich den Quelltext schreiben, inklusive
des Hauptprogramms. Und häufig ist es schwierig, generelle Klassen zu
definieren, z.B. ein Chat-Room-Widget, von dem es zur Laufzeit beliebig
viele geben kann.

Auch I<Glade>, ein (das!) Gtk+ und Gtk+2 RAD-Tool, ist keine Ausnahme
davon. Zum Glück kann man Glade auch etwas anders zum Entwickeln benutzen,
und diesen anderen Weg (ich kenne niemanden, der Glade so benutzt), möchte
ich hier beschreiben.

Zuallererst ist es notwendig, die Widget oder die UI in Glade zu
erstellen und als GladeXML-Datei zu speichern. Z.B. habe ich für
ein Bilder-Anzeige-Programm (Gtk2::CV, reiner Beta-Code) einen
"Ausdrucken"-Dialog erstellt:

=for latex
\begin{center}\includegraphics{freenet1.png}\end{center}

Die Beschreibung ist in der XML-Datei C<cv.glade> gespeichert. Darin habe
ich den einzelnen Widgets Namen gegeben, z.B. heißt das Dialogfenster
C<PrintDialog>, das Option-Menü zum Auswählen der Papiergröße C<papersize>
usw.

Den ganzen Dialog kapsele ich in einem Perl-Modul namens
C<Gtk2::CV::PrintDialog> ab, mit insgesamt 70 Zeilen und zwei Methoden.
Die kürzeste davon benutzt ein anderes Modul C<Gtk2::CV::PostScript>
zum Ausdrucken und ist völlig uninteressant :) Die längste ist die
C<new>-Methode, die ein neues PrintDialog-Widget erzeugt. Zuerst der
Standardkopf:

   use Gtk2;
   use Gtk2::GladeXML;
   # uvm.

   sub new {   
      my $class = shift;
      my $self = bless { @_ }, $class;
         
Als nächstes wird die GladeXML-Datei geladen:

      $self->{dialog} = my $d = new Gtk2::GladeXML ".../cv.glade", "PrintDialog";

Mit C<PrintDialog> wird ein Teilbaum aus dem Widget-Baum geladen, und zwar
der mit dem C<PrintDialog>-Namen. So kann man viele verschiedene Dialoge
in einer Datei ablegen. Das Laden ist nicht unbedingt eine schnelle
Angelegenheit, ist aber in den meisten Fällen flott genug, um bei jedem
Aufruf von neuem gemacht zu werden (und man hat sowieso keine Wahl :)

Das Ergebnis ist I<kein> Widget, sondern ein C<Gtk2::GladeXML>-Objekt, das
die Methode C<get_widget> besitzt, mit der man anhand des Namens einzelne
Widgets "herausgreifen" kann.

Damit fülle ich den Dialog mit Leben:

      $d->get_widget ("destination")->set (text => $ENV{CV_PRINT_DESTINATION} || "| lpr");

      my $menu = $d->get_widget ("papersize")->get_menu;
      for (Gtk2::CV::PostScript->papersizes) {
         my ($code, $name, $w, $h) = @$_;
         $menu->append (my $item = new Gtk2::MenuItem $name);
         $item->set_name ($code);
      }
      $menu->show_all;
      $d->get_widget ("papersize")->set_history (0);

      $d->get_widget ("PrintDialog")->signal_connect (close => sub {
         $_[0]->destroy;
      });
      $d->get_widget ("PrintDialog")->signal_connect (response => sub {
         if ($_[1] eq "ok") {
            $self->print (
               size        => (Gtk2::CV::PostScript->papersizes)
                                 [$d->get_widget ("papersize")->get_history],
               margin      => $d->get_widget ("margin")->get_value,
               ...
               destination => $d->get_widget ("destination")->get ("text"),
               binary      => $d->get_widget ("encoding_binary")->get ("active"),
            );
         }
         $_[0]->destroy;
      });

      return $self; # Ende
   }

Jetzt wird klar, warum das Ding C<$d> heißt und nicht einen längeren Namen trägt.

Wer Das GladeXML-Modul kennt, weiß, daß es noch viel "einfacher" geht,
z.B. mit C<signal_autoconnect_from_package>. Leider weiß man in den
Callbacks, die diese Methode mit den Widgets verbindet, nichts mehr über
das ursprüngliche C<PrintDialog>-Objekt, so daß sie mir recht nutzlos
erscheint, wenn man nicht alles in globalen Variablen ablegen will (was
häufig der Fall ist).

Daher habe ich die Funktion C<signal_autoconnect_all> geschrieben. Sie
geht einen etwas anderen Weg und erlaubt es, die Signal-Callbacks als
Closures anzugeben. Damit wäre das Namensraum-Problem gelöst. Leider
muss man dazu jedem Signal-Handler einen Namen geben, und das ist so
umständlich, daß ich die Funktion selbst nie benutzt habe und es einfach
"per Hand" Anhand der Widget-Namen mache.

Dies alles heißt nicht, daß man es nicht einfacher anders besser machen
könnte. Es ist einfach "mein Weg", Glade zu benutzen. Und wenn ich noch
etwas darüber nachdenke, muß ich sagen, daß es mit Glade nicht wirklich
einfacher ist, Widgets umzustellen oder GUIs zu designen.

*seufz*.


=head1 Teil 2 - Gtk+ als solide Grundlage für Eigenentwicklungen

#TODO

=head2 Perl-Objekte vs. Glib-Objekte


=head3 Die Perl-Methode

#TODO

=head3 Die unsaubere Glib-Methode

#TODO

=head3 Die saubere Glib-Methode

#TODO

#TODO

=head2 Objekte aus anderen Sprachen nutzen

#TODO

=head1 Verweise

=over 4

=item http://www.gtk.org/

Die Dokumentation zu Gtk+, Glib usw.

=item apt-get install devhelp-book-gtk2 # oder devhelp-books

Installiert unter debian I<devhelp>, einen inetraktiven Help-Browser und
das Gtk2-Buch (dazu gehört auch GObject, Glib-Doku uvm.). Sehr hilfreich
beim Programmieren.

=item Gtk2::PodViewer, Gtk2::GoBoard, Gtk2::CV

Verschiedene Module, die Gtk2-Widgets implementieren.

=back


Revision:	1.9
Committed:	Thu May 27 19:51:01 2004 UTC (22 years, 4 months ago) by root
Branch:	MAIN
Changes since 1.8:	+380 -15 lines
Log Message:	* empty log message *