Re: Limit Decimal Places in a GtkTreeColumn

On Wed, Dec 1, 2010 at 1:57 PM, Marius Feraru wrote: > Zettai Muri wrote: >> Is someone able to show me how to use the set_cell_data_func: > The attached patch should fix your homework, but you might wanna > review some Perl 5 references documentation, at least the sections > regarding code refer

Re: Limit Decimal Places in a GtkTreeColumn

Zettai Muri wrote: > Is someone able to show me how to use the set_cell_data_func: The attached patch should fix your homework, but you might wanna review some Perl 5 references documentation, at least the sections regarding code references (and calling subroutines). > http://gtk2-perl.sourceforg

Limit Decimal Places in a GtkTreeColumn

Hi All, I have attached a small program which lists the top 20 movies from the imdb database. The 'Rating' column is Glib::Double and when it is displayed in the treeview it shows a rating as: 9.20. Is someone able to show me how to use the set_cell_data_func: http://gtk2-perl.sourceforge.ne

Re: gdk-pixbuf-set-option missing?

Torsten Schoenfeld writes: > > It's now wrapped in git master. I didn't realize set_option() won't replace existing option settings. Puts a dampener on it for general storage or amending options after loading :( Might like to know the option keys that have been loaded too, but I can't see anywhe

Re: Stop stepping on other perl extension's toes

Florian Ragwitz writes: > > Most of the time glib related modules want to use the gobject/gboxed > interfaces anyway and don't really care about associating plain pointers > with scalars. Except those whacky bits like wrapping callback funcs for CellLayout or TreeSortable to expose back to perl :

Re: Stop stepping on other perl extension's toes

Florian Ragwitz writes: > > "do something special when $this gets freed" ... The ones I think I've seen seem to be mainly for scalars rather than hashes like the glib::object thingie. Does a tied hash go through magic? If someone was crazy enough to want to tie their gobject hash ... -- Don'

Re: [PATCH] Use Glib's infrastructure for attaching magic

Florian Ragwitz writes: > > I wondered that too. I briefly looked over how it's used and it turned > out to be used as a return-by-reference value in some glib callback. Looks like it's only an IV passed out to the perl, and the newSVsv copies to pass there anyway. >> newCONSTSUB > > On versions

Re: Stop stepping on other perl extension's toes

Kevin Ryde writes: > Florian Ragwitz writes: >> >> If anyone other than us wants to use this functionality, he's >> free to use XS::Object::Magic. The goal here is not to provide a >> general purpose API - that already exists. > > I suppose friends or subclasses of gobject/gboxed mig

Re: [PATCH 1/2] Allow for more than one PERL_MAGIC_ext magic

Kevin Ryde writes: > Florian Ragwitz writes: >> >> +void >> +gperl_attach_mg (SV * sv, void * ptr) >> +{ >> +sv_magicext (sv, NULL, PERL_MAGIC_ext, &gperl_mg_vtbl, >> + (const char *)ptr, 0); > > I suppose the alternative to magic would be a pointer->pointer hash > table woul

Re: Stop stepping on other perl extension's toes

Florian Ragwitz writes: > > If anyone other than us wants to use this functionality, he's free > to use XS::Object::Magic. The goal here is not to provide a general > purpose API - that already exists. I suppose friends or subclasses of gobject/gboxed might use it eventually, but star

Re: Stop stepping on other perl extension's toes

Kevin Ryde writes: > Florian Ragwitz writes: > >> extensions also using the PERL_MAGIC_ext mechanism. > > The magic is only the underlying hash is it, what sort of things might > add further magic to that? Something fiddling around with what hash > keys are visible etc? If a popular package st

Re: [PATCH 1/2] Allow for more than one PERL_MAGIC_ext magic

Florian Ragwitz writes: > > +void > +gperl_attach_mg (SV * sv, void * ptr) > +{ > + sv_magicext (sv, NULL, PERL_MAGIC_ext, &gperl_mg_vtbl, > + (const char *)ptr, 0); I suppose the alternative to magic would be a pointer->pointer hash table would it? Would that be slower than

Re: Stop stepping on other perl extension's toes

Florian Ragwitz writes: > > more robust and improve interoperability Yes. > extensions also using the PERL_MAGIC_ext mechanism. The magic is only the underlying hash is it, what sort of things might add further magic to that? Something fiddling around with what hash keys are visible etc? If a

cursor for display segv

The program below gets a segv for me with i386 debian "experimental" gtk 2.22 and glib 2.27.3. It's a GdkDisplay with a cursor created on that display, and the display destroyed before the cursor. Looks like the segv is at the "undef $c" stage, with gdb per below. I wonder if gdk_cursor_unref()

Re: [PATCH] Use Glib's infrastructure for attaching magic

Kevin Ryde writes: > Florian Ragwitz writes: >> >> data_sv = newSViv (PTR2IV (wrapper)); >> -sv_magic ((SV *) dummy_cv, 0, PERL_MAGIC_ext, (const char *) data_sv, >> 0); >> +gperl_attach_mg ((SV *) dummy_cv, data_sv); > > Incidentally, that data_sv looks like it's leaked on DESTROY

Re: [PATCH] Use Glib's infrastructure for attaching magic

Florian Ragwitz writes: > > data_sv = newSViv (PTR2IV (wrapper)); > - sv_magic ((SV *) dummy_cv, 0, PERL_MAGIC_ext, (const char *) data_sv, > 0); > + gperl_attach_mg ((SV *) dummy_cv, data_sv); Incidentally, that data_sv looks like it's leaked on DESTROY -- with or without this dif