Re: [gtk-list] Re: Gtk & Perl

[Kenneth Albanowski <kjahds kjahds com>]

On 16 Aug 1997, Owen Taylor wrote:

> Great! If I had known in advance, I might (maybe) have been able to
> save you some work, since I had already had a mostly functioning
> version going. But it had some problems, and since I wasn't getting
> a release out, I'm more than happy to let a real Perl expert take on
> the job.

Mine is definitely functional, though I do get some interesting crashses
every now and then. I apologize for not asking whether anyone else was
working on such a project, but I more or less started the thing on a lark,
and it just got out of hand. :-) 

> I take it you mean Gtk objects ... I don't think there is any
> reference counting for Gdk objects. 

For Gdk windows, yes, there is. Except that it seems very unevenly used.
New windows (and related types) get their ref_count set to 1. When you
destroy such an object, the ref_count is decremented. gdk_window_destroy
always destroys the window, even if the ref_count is positive, whereas
gdk_pixmap_destroy only destroys the pixmap if the ref_count is already
zero.

> I can't answer for Gtk reference counting, but actually, I'm interested
> in what you do for Gdk structures -- I suppose as long as there is never
> a case where a malloc'ed Gdk structure is passed into a function and
> persists (which I suppose would be broken design), you could just use
> Perl refernce counting.

No, not really. You see, objects need to persist both inside and outside
Gdk. If I create a new object:

   $pixmap = new Gtk::Gdk::Pixmap $window, 20, 20, 16;

then that object should persist as long as both Perl references it, as as
long as any other Gdk or Gtk objects reference it. I don't honestly know
if any code links to Gdk objects instead of just copying them, though.

This problem is more subtle for Gtk objects, which do have consistent
reference counting, but if the Perl reference adds to the Gtk reference,
then the entire chain triggered on "destroy" breaks down, because there
are still references to the supposedly destroyed object.

> I agree wholeheartedly. I had to do pretty much the same sort of
> things with signals. (In the .pm for each class, have code that
> identified in detail the signature of each signal for that class).

My code doesn't actually have much .pm code, being just a big C wrapper,
but the idea is certainly the same. (I simply went with copying the C
interface directly.) 

> The enum problem is looking like even more of a big deal with the
> the new _new/_setv mechanism (see the 970707 simple.c). It would be
> really nice if we could have
> 
>    $frame->setv ( shadow_type => 'in' )
> 
> instead of
>    
>    $frame->setv ( shadow_type => Gtk->SHADOW_IN )
> 
> (And it get's a lot worse than that example in terms of length - 
>  e.g., GTK_MENU_FACTORY_MENU_BAR)

Precisely. As it happens, the arg code I see (in 970606) doesn't have any
enumerated arguments, but if it did it would look like this:

    $viewport->set( GtkViewport::ShadowType => 1);

whereas the equivalent direct function is much more comprehensible:

    $viewport->set_shadow_type( 'in' );

Note that my code doesn't make any numeric constants available at all. It
translates all of the Gtk/Gdk enumerations into strings, and back again.
I'm contemplating another mechanism that would use objects to represent
enumeration values, but in any case I won't use simple numbers.

Anyhow, the set() mechanism is practically useless from Perl, as both the
names and values of the items are locked into the C code where my wrapper
can't get at them and translate them into something more useful.

Of course, even with these limitations, much is possible. This is my
translation of 970606's simple.c:

	use Gtk;
	
	use vars qw($window $button);
	
	sub hello {
	        Gtk->print("hello world\n");
	}
	
	$window = new Gtk::Widget       "GtkWindow",
	                GtkObject::user_data            =>      undef,
	                GtkWindow::type                 =>      0,
	                GtkWindow::title                =>      "hello world",
	                GtkWindow::allow_grow           =>      0,
	                GtkWindow::allow_shrink         =>      0,
	                GtkContainer::border_width      =>      10;
	
	$button = new Gtk::Widget       "GtkButton",
	                GtkButton::label                =>      "hello world",
	                GtkObject::signal::clicked      =>      "hello",
	                GtkWidget::parent               =>      $window,
	                GtkWidget::visible              =>      1;
	
	show $window;

	main Gtk;


> But just creating a whole bunch of new enums might cause problems for
> code (like the signal handling code) that needs to know the size of
> parameters, nothing more. Either there could be a translation function
> from long enum types to short types, or possibily there could be a 
> type/subtype scheme. (Either way means changing a lot of stuff, but
> hopefully mostly internal to GTK)

How about something with bits? The high eight bits describe the size of
the variable (INT, POINTER, SIGNAL, etc.) and the low eight bits (or
whatever) describe the exact meaning. Anything that doesn't care about the
meaning can discard the bits they don't want.

> Anyways, its great you are working on this. There are lot's of details
> I'll be curious to see how you are handling. I also have some example
> programs that might be of interest (a 300 line graphical FTP program
> that does background transfers...)

I'll mail you a copy -- it's not too large.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)