Re: meuh

Avec les bons bindings on peut faire du développement Gtk sans se prendre la tête avec du C bien verbeux.

OCaml:

rlwrap lablgtk2 -thread
# let w = GWindow.window ();;
val w : GWindow.window =
# let l = GMisc.label ~text:"Hello world of OCaml!" ~packing:w#add ();;
val l : GMisc.label =
# w#show ();;
- : unit = ()

Ruby:

require 'gtk2'

Gtk.init

window = Gtk::Window.new(Gtk::Window::TOPLEVEL)
button = Gtk::Button.new('Hello World')
window.add button
button.show
window.show

Gtk.main

La même concision qu'OCaml (Je ne suis pas spécialiste donc pas de petits raccourcis genre packing), la grosse différence est que c'est un langage dynamique.

Python:
http://live.gnome.org/PyGTK(...)
Pareil que ruby.

Perl:

use strict ;

use Gtk2 ’-init’ ;

my $fenetre = Gtk2::Window->new(’toplevel’ ) ;
$fenetre->show ;

Gtk2->main ;

C++ :

#include <gtkmm.h>

int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);

Gtk::Window window;

Gtk::Main::run(window);

return 0;
}

http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch03.html#id(...)
Je suis favorablement surpris. Comme en OCaml, on a un typage statique (et même assez fort).


Java-gnome:
http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JavaGnomeHe(...)
(Un peu plus long, mais glade s'en sort bien.)

Il y en a beaucoup plus (cf http://live.gnome.org/GnomeLanguageBindings),(...) en
fait le choix du langage apparait comme assez secondaire pour bénéficier de glib/gtk/glade/cairo...

Par contre tous n'ont pas le même niveau de support du reste des bibliothèques (GConf, gnomeVFS, DBus...). La couverture des API devrait bientôt s'améliorer grace à l'utilisation plus intensive d'introspection dans GObject - on peut automatiser de façon plus poussée la génération de code (la plupart des langages rajouteront quand une deuxième couche d'API pour affiner le style). Ce travail approche du but, avec un binding poppler pour python généré de façon dynamique:
http://www.advogato.org/person/jdahlin/diary.html?start=12(...)