Re: [gtk-perl-xs] A bug with CellRenderer?

Jörn Reder said:

I have problems setting cells to a bold font. I think this should work:

hehe, a big can of worms...

  $tree->add_column ( $column );

i presume pseudocode...  append_column is what you want.  (took me a minute to
find it, myself.)

  $ctext = Gtk2::CellRendererText->new;
  $ctext->set ( weight => 'bold' );

you'd like to think that, wouldn't you?  but no!  you are thwarted by the gtk
type system!

according to the docs for GtkCellRendererText, the weight property is

  "weight" (gint: Read/Write)

gint!  not PangoWeight!  this means that you can't use the built-in enum
conversion stuff, which means that 'bold', the obvious string, is completely
useless!  in fact, i'm running your code (with a window wrapped around it)
with strict and warnings and perl tells me

  Argument "bold" isn't numeric in subroutine entry at [weight => 'bold']

the type system looks up the parameter specification for the weight property
and sees that it wants an integer, and you gave it a string.  (it would only
try to convert that string to the corresponding enum if the paramspec gave an
enum type instead of G_TYPE_INT.)

annoying, isn't it?

and like several other annoying things about the bindings, you can't trap this
at the binding level because the code is actually triggered from within
glib/gtk+ itself and there's no reliable way to trick it out.

so, to solve a situation just like this when porting the textview portion of
gtk-demo, you might notice a bunch of constants defined at the top of the file
and used when setting the font weight on the tags....

 use constant PANGO_WEIGHT_BOLD => 700;
 $buffer->create_tag ("heading",
                      weight => PANGO_WEIGHT_BOLD

i, for one, don't really like that solution, because now you carry that to
every file.  the next option is to define these as constants in the Pango
module, but you'd have to refer to them with a package name (or export them,
which i would rather not do), a la Gtk2::Pango->SCALE.

i don't like any of those, so you get what you've got.

any better ideas?

muppet <scott at asofyet dot org>

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