I'll be using this file for a list of bugs, goals, and my general
intentions for Perl/Gtk+. I'd appreciate it if folks would keep an eye on
the sections and at least strip out the bug listings when/if they get
fixed.
- Kenneth Albanowski
Revision notes:
New with release 0.7005.
* GnomePrint support added.
* Experimental Bonobo support added.
* Experimental Mozilla support added.
* No longer required to call the init method on most of the submodules.
* Updated support for GtkHTML (added a Gtk::HTML::Simple package that handles
all the http connections for you using LWP).
* Added a perl variable change event source for the gtk mainloop.
* Simpler support for building your own submodules.
* The toplevel Makefile will compile all the submodules for you (if you have
the requires libraries installed).
* Moved the Applet code to its own submodule.
* Documentation updates (including a brand-new Gtk::cookbook!).
* Many fixes, cleanups and other small enhancements here and there.
Old stuff follows...
As of public release 0.7000, the submodules in Perl/Gtk need to be
built separately as outlined in the INSTALL file. This may change
in a future point release if there is demand for compiling all the
modules at once.
As of public release 0.5000, Perl/Gtk+ now contains both the Gtk and
Gnome sections (in 0.4 they were split apart), and a build mechanism
capable of building everything that the user desires. The files have
been moved around substantially, and Makefile.PL severely tweaked to
support this. (This may turn out to be unportable -- I'll find out.)
For the moment, Perl/Gnome will be a permanent part of the Perl/Gtk+
module.
Release 0.5000 has been tested with Gtk+ 0.99.10 through 1.1.something,
and should work properly with all of them. I'm sure I've left some newer
functions out, of course. (Please be careful when adding or modifying
code, to try and avoid breaking the support for older versions.) I've
compiled it up through 1.1.9 successfully, and it ran file up until
1.1.8, where it started freezing up.
The directory rearrangement has moved all buildable packages into
separate subdirectories of the main (Gtk, GdkImlib, Gnome, etc.), with
.xs and sample files being stored in $package/xs and $package/samples
directories, respectively.
Makefile.PL looks automatically for */pkg*.pl and presents the user with
a list of package names to choose from. There is currently no
auto-detection. Gnome is turned off by default, along with everything
else.
"make test" now runs a master test program that lets you easily launch
any sample file from any of the packages (as long as it contains a
TITLE: comment.)
Getting back to the Gtk/Gnome split and recombination, this involves an
experimental design to allow Perl/Gtk+ "submodules" (specifically, the
bindings for a particular Gtk+ widget set) to be compiled independantly,
allowing them to be distributed and maintained separately. This
mechanism was used in Gtk 0.4 and the separate Gnome 0.3000 module, but
the results didn't seem favourable, and I'm still unsure of the
stability of the mechanism. For the time being, I want to roll both Gtk
and Gnome back into a single distribution.
Note that this itself was always a goal (that is, putting any of those
separate modules together and building them all at once), and the
mechanisms involved are still in place (tools/genext.pl and the
Perl*DeclareFunc/Var macros), and will be quite easy to revive if it
seems worth the effort.
Programming guidelines:
xsubpp requires all named types to be mentioned in the typemap file,
even for functions that are #ifdef'd out. That's why separate files are
needed to fully support some of the different Gtk+ versions of widgets, and why
#ifdef "mysteriously" fails to work sometimes.
As much as possible avoid building direct interfaces to GLib objects
(especially GNodes). Perl already has support for all of the data types
needed, and I don't want to try to tie GLib into Perl along with
everything else.
Most parameters (and return values) are cross-checked at run-time to
make sure they are of the proper time, and are not NULL/undefined. If a
NULL/undefined parameter or return value is desirable, please append
_OrNULL to the type.
BUGS:
Resize of swatch inside ColorSelectButton is delayed (at least with
gtk+ 1.2.2).
Selection handling (and/or atoms?) is out to lunch, dinner, breakfest,
etc.
Pixmap changing of notebook tabs in test.pl is broken. (Seems to be fixed.)
Memory management of Gtk objects (things related to GtkObject) is fairly
solid, but management of other types (structures, abstract pointers,
etc.) is still clumsy.
Version configuration is based heavily on a hex/BCD scheme (1.2.3 ==
0x010203). If any version component of Gtk+ ever has more then three
digits, this will break, messily. Any other suggestions?
widget.pl doesn't work with all versions, as the "string" Gtk type
has changed names.
The Gtk packer sample is completely out of it.
RC support slacks off after 1.1.5.
"BASIC" and the other gtk widget flags seem to be at complete a lost,
for the moment.
There are a lot of #ifdefs that just chop things out that probably
ought to provide decent alternatives.
There's a very serious problem affecting GtkColorSelectButton, and every
else in general, specifically the need to manually invoke init on Gtk
before doing anything. Unfortunately this rather kills GCSB, which
registers its type when used -- before Gtk has been initialized. It's
rather hard to come up with an auto-init solution for this because you
can only init one thing (gnome, gtk, or gdk), and if its gnome, you may
need parameters. Ugh.
The CAST mechanism in the .def format isn't very regular across types,
and it almost certainly oughtn't to be there, or at least should be
modified so that a language independant technique could be used. (Or
language _specific_, so that Perl, Scheme, whatever, can each have their
own overrides.)
GtkXmHTML is only hanging on via a thread, due to the casting mechanism
being a bit more complex then I had remembered.
Each package (Gtk, XmHTML, Gnome, etc.) currently partakes of the same
wodge of include files, which really isn't good, since it could lead to
namespace problems, and also slows everything down parsing stuff like
the GNOME includes. gendefs/genext should work separately on each
package, so that they can refer to each other if they have to, but
aren't required to. (This is a good steps towards module separation, of
course.) All modules still link with the same libraries, of course,
since they are all linked together.
Goals:
Switch signal handling over to _interp calls.
GtkGC from 0.99.
Auto-detect available packages (use Configure from Term::ReadKey).
Revisit the GtkObject garbage collection system, make sure there aren't
any leaks, that cycles unwind themselves, and that cleanup is relatively
timely.
There are currently three types of memory thingy: boxed, struct, and
GtkObject. GtkObject's are the most advanced, and are complexly bound
into the Perl typesystem, with a cache of Perl objects serving as
proxies for the C GtkObject pointers, along with garbage collected
reference counting.
boxed thingies are one step down. They have a separate cache, but
there is less reference counting so thingies tend to drop out of the
cache, leading to the possibility of the same C pointer showing up as
different Perl objects over time. "boxed" refers to the fact that these
objects have ref/unref functions, making then reference counted.
struct thingies don't work at all the same, and are more sort of
pass-by-value then pass-by-reference, or at least that is the tack I've
taken. Usually these are copied directly into Perl data types intstead
of being referred to through a proxy.
Problems abound: many "boxed" thingies have stubbed out ref/unref
functions, or have copy/delete functions (which is _not_ the same
thing). It's a miracle some of this stuff works at all. "struct"'s don't
fair much better -- there's little consistent use of them, the
interfaces tend to be different, and they often aren't used at all,
in favour of a little special purpose code.
All of these types need to be reviewed, both towards fixing up
Perl/Gtk+, and towards changing C/Gtk+ to solve some of these issues at
the source.
On the naming of widgets:
GTK widget abc_def_ghi becomes Perl widget Gtk::Abc::DefGhi
GTK widget gtk_def_ghi becomes Perl widget Gtk::DefGhi
GDK widget gdk_def_ghi becomes Perl widget Gtk::Gdk::DefGhi
GNOME widget gnome_foo_bar becomes Perl widget Gnome::FooBar
GNOME widget gtk_gnome_foo_bar becomes Perl widget Gtk::Gnome::FooBar
XS code may refer to PerlGtk objects, along with these variants:
Gtk::FooBar_Sink = sink the object before returning it
(this doesn't hurt anything because Perl
grabs a reference when it first sees
the object, which makes the sink
superfluous)
Gtk::Widget_Up = upcast the object to its real object type
Gtk::Widget_Sink_Up = Both
Gtk::Widget_OrNULL = accept undef as a null ptr