Re: Strange bug



muppet wrote:

that may not be *the* bug, but it should help.  let me know.

Nope, still there.
to finish the GdkBitmap story... since there's no GType for GdkBitmap, we have to do a couple of hacks to round out the object support. the Perl-to-C path uses the standard macros-around-gperl_get_object trick, but without a GType gperl_new_object would bless into the wrong class. so, newSVGdkBitmap and newSVGdkBitmap_noinc are actual functions, implemented in Gtk2/xs/GdkPixmap.xs ... the basic trick is to create the object with gperl_new_object, let it get blessed into the bottommost known GType, and then re-bless it into Gtk2::Gdk::Bitmap, for which we added an @ISA to Gtk2::Gdk::Pixmap in the BOOT section.

as you can see, it's all very straightforward. *cough*


Very.... I haven't really looked into this, but from the Gtk docs it seems that there is no such thing as a GdkBitmap, a bitmap is just a pixmap that happens to have a depth of 1 bit. But thanks for the explanation, I'll keep looking.

BTW, why SvTRUE and not SvOK? It shouldn't make any difference in this case, but there are cases where an SV could be false, and still be defined.

in general, however, i just avoid the use of GdkBitmaps, because GdkPixbuf is a lot easier, especially when you already have to transfer all the data to the server anyway. you could replace most of that loading code with:

  my $pixbuf = Gtk2::Gdk::Pixbuf->new_from_file ($filename);
  $image->set_from_pixbuf ($pixbuf);

That's what I started out with. Problem was that my drawing area is scrolled, and all my additions were gone as soon as I scrolled them out of the viewport. The plan is to update a pixmap as well as the window (can't draw to a pixbuf), and then bring the pixmap forth when needed. Not necessarily a good plan, but it's the best I've come up with so far.

Bjarne




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]