Re: [gtk-list] Automatic generation of gtk+ interface
- From: Didimo Emilio Grimaldo Tunon <emilio_tunon nl compuware com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Automatic generation of gtk+ interface
- Date: Fri, 3 Jul 1998 09:44:19 +0200 (METDST)
> * 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
> 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
> (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
firstname.lastname@example.org Tel. +31 (0)20 3116 200 ext. 413
] [Thread Prev