Bug in pixbuf->copy ?

Hi,

Could it be that there is a bug in the "copy"
method for the 
gtk2::Gdk::Pixbug object ?

I have the following situation, I use
Gtk2::Widget->render_icon to get a 
"missing-image" icon. But since I want to tread
each image as a separate 
object I want to make a private copy of this pixbuf.

Say I create 3 of these pixbufs. If I do not use
"copy" all 3 of them 
are the same perl object (warn "$object\n"),
but if I do use "copy" the 
second differs from the first but the third is the same as
the second, 
regardless of the copy() call.

I would expect that "copy()" always initializes
a new perl object.

Any suggestions ?

-- Jaap Karssenberg <parduscpan.org>

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

P.S.

I forgot to name my versions:

gtk2      2.8.16
gtk2-perl 1.102


I fixed my problem now by the following work around:

I assign a key into the Pixbuf perl object
$pixbuf-> = 1 then 
when constructing a new one if the copy() function returns
an object 
with this key set I call the copy(0 function again on this
object.

It seems that the problem with the copy() function is not
recursize (the 
copies of a copy are not the same) so this works for now.

-- Jaap
_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

On Apr 17, 2006, at 9:27 AM, Jaap Karssenberg wrote:

> It seems that the problem with the copy() function is
not recursize  
> (the copies of a copy are not the same) so this works
for now.

It would help to see your code and hear your explanation of
how you  
know the objects are not distinct copies.  I tried a simple
script  
and could not reproduce your results.

Gtk2::Gdk::Pixbuf::copy() has a trivial implementation that
calls  
gdk_pixbuf_copy() and transfers ownership of the new pixbuf
to the  
caller.  gdk_pixbuf_copy()'s documentation claims that it
returns  
either a new pixbuf or NULL, which is confirmed by a quick
read of  
the source.  The origin of the source pixbuf (how many
references, is  
it already a copy of something) is never queried, and the
actual data  
of the pixbuf is a real in-memory duplicate of the original,
via  
g_try_malloc() and memcpy().


--
I don't have a drinking problem,
'cept when i can't get drink.
   -- Tom Waits

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Hi Muppet,

The pixbuf thing appears to be have been a coding mistake on
my side - 
sorry to have wasted your time. A friend of mine spotted it
and it seems 
to me like a loophole in the "strict" pragma.

What I was doing was something like:

    use strict; #!!!

    sub insert_image {
       my ($textbuffer, $file) = _;
       my $pixbuf = Gtk2::Pixbuf->new_from_file($file) if
-f $file and -r _;
       $pixbuf ||=
Gtk2::Image->new->render_icon('gtk-missing-image', 
'dialog')->copy;
      
       # ...
    }

Now the trouble was that my "missing image"
icons all got to be the same 
object.
What is happening is that $pixbuf although supposed to be
locally scoped 
variable becomes global in the case "-f $file and -r
_" evaluates false. 
Not sure if this works the same in other versions of perl -
I'm 
surprised that I didn't notice this behavior earlier in
other programs.

Anyway, thanks for your time.

-- Jaap

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list