Re: [gtk-list] Automatic generation of gtk+ interface

[Didimo Emilio Grimaldo Tunon <emilio_tunon nl compuware com>]

> * Language wrappers would always be up-to-date and people could generate
>   them from any gtk+ version without problems, even when the interface
>   has been changed considerably between versions.
> 
  That is something, at the moment I am confronting a bit of a problem on
  my 'home development machine', got GTK 0.99 because if I remove it
  a lot of my distribution programs (RH5.0) would break and I have spent
  *a lot* of time doing the OS distribution upgrade, then I also have
  1.0.4 installed on /opt for which I have to use a wrapper script to
  exec my program so that it uses the libs in /opt rather than /usr/lib
  (somehow /usr/lib also shows libgtk.so.1) and on top of that I would
  rather use C++ but then that introduces the problem of yet another
  runaway piece of code that has to be sync'ed with the rest. Quite frankly
  I would rather concentrate on developing my application.

> * Things like gui builders would be able to use this information to
>   generate automatically much of the support of widgets. Currently
> 
  In XForms the GUI builder (comes with the distribution) allows you
  to create your presentation part, but it's a one way only thing. If
  you decide to add a new widget *after* you have added your own
  code then you can't go back to the GUI builder.

  VisualTcl on the other hand, allows you to define and write your own
  code within the GUI builder and that's very neat.

> This kind of thing would rise the abstraction level of gtk's internal
> code and I believe it'd make changing gtk+ easier and give benefits of
> changes faster to users.
> 
  Back to that I think it would be nice to have some sort of compatibility
  table or map available on Gtk.Org (?) that could tell you which versions
  of Glade, GladeMM, Gtk-- etc etc etc are compatible with a particular
  version of gtk/gdk/glib. Specially now that Glib will be distributed
  separately (???).

> we need specialized sollution to match exactly gtk+'s object model and
> which has parser already available so that language wrapper can be
> implemented just by writing a small text file describing target
> languages features.
> 
  Hum, a job for PCCTS (Purdue Compiler Construction Tool Set) or
  ANTLR? 

> (There has been talks with some people using gtk--'s signals in other
> projects about making the signal system/object model a separate
> library - Making it language independent would be important to keep it
> consistent on all platforms.)
> 
  Oh boy, yet another spinoff :( some time ago (last month?) there was
  an interesting article on Dr. Dobbs (unfortunately WinCough oriented)
  about an event listener class, other objects simply register themselves
  to the listener and when the event occurs all the objects get notified.

  Again, I would rather develop on C++ but here at work this machine doesn't
  have a C++ compiler and I don't want to bother with wrappers yet.


-- 
D. Emilio Grimaldo Tunon       Compuware Europe B.V. (Uniface Lab)
Software Engineer	       Amsterdam, The Netherlands
emilio_tunon@nl.compuware.com  Tel. +31 (0)20 3116 200 ext. 413