convenience API for applying PangoAttributes to a GtkLabel
Hi, libgimpwidgets includes an API for conveniently apply PangoAttributes to a GtkLabel and I wonder if I should propose it for inclusion in GTK+: http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-GimpWidgets.html#gimp-label-set-attributes It is IMO more convenient than using g_strdup_printf() to embed a string into PangoMarkup. Here's a short example to make a label large and bold: gimp_label_set_attributes (GTK_LABEL (label), PANGO_ATTR_SCALE, PANGO_SCALE_LARGE, PANGO_ATTR_WEIGHT, PANGO_WEIGHT_BOLD, -1); The implementation can be reviewed in http://svn.gnome.org/viewcvs/gimp/trunk/libgimpwidgets/gimpwidgets.c?view=markup Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
Hey Sven, On Mon, 2007-03-12 at 23:09 +0100, Sven Neumann wrote: > Hi, > > libgimpwidgets includes an API for conveniently apply PangoAttributes to > a GtkLabel and I wonder if I should propose it for inclusion in GTK+: > > http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-GimpWidgets.html#gimp-label-set-attributes > > It is IMO more convenient than using g_strdup_printf() to embed a string > into PangoMarkup. Here's a short example to make a label large and bold: That's very nice, but the worst use of markup-in-message is caused by glade/libglade. It would be nice if this could be taken into consideration as well: http://bugzilla.gnome.org/show_bug.cgi?id=97061 For the sake of this 5-year old bug. -- Bastien Nocera <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
On Mon, 2007-03-12 at 18:09 -0400, Sven Neumann wrote: > Hi, > > libgimpwidgets includes an API for conveniently apply PangoAttributes to > a GtkLabel and I wonder if I should propose it for inclusion in GTK+: > > http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-GimpWidgets.html#gimp-label-set-attributes > > It is IMO more convenient than using g_strdup_printf() to embed a string > into PangoMarkup. Here's a short example to make a label large and bold: > > gimp_label_set_attributes (GTK_LABEL (label), > PANGO_ATTR_SCALE, PANGO_SCALE_LARGE, > PANGO_ATTR_WEIGHT, PANGO_WEIGHT_BOLD, > -1); > > The implementation can be reviewed in > http://svn.gnome.org/viewcvs/gimp/trunk/libgimpwidgets/gimpwidgets.c?view=markup > > > Sven This is nice. Makes sense to have it in Pango in fact I guess. As pango_attr_list_new_something(). Probably a pango_attr_new(type, ...) too. The only inconsistency here is that currently the various color attribute constructors take separate r, g, b, instead of a PangoColor *. Feel free to file a bug. I also spotted a typo in the implementation: For PANGO_ATTR_STRIKETHROUGH, it's doing a pango_attr_underline_new() instead of a pango_attr_strikethrough_new(). -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
On Mon, 2007-03-12 at 23:09 +0100, Sven Neumann wrote: > libgimpwidgets includes an API for conveniently apply PangoAttributes to > a GtkLabel and I wonder if I should propose it for inclusion in GTK+: > > http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-GimpWidgets.html#gimp-label-set-attributes > > It is IMO more convenient than using g_strdup_printf() to embed a string > into PangoMarkup. Here's a short example to make a label large and bold: > > gimp_label_set_attributes (GTK_LABEL (label), > PANGO_ATTR_SCALE, PANGO_SCALE_LARGE, > PANGO_ATTR_WEIGHT, PANGO_WEIGHT_BOLD, > -1); > > The implementation can be reviewed in > http://svn.gnome.org/viewcvs/gimp/trunk/libgimpwidgets/gimpwidgets.c?view=markup Oh, very nice. This could remove the manual PangoAttribute-fu in matchbox-desktop-2, and as Bastien says remove the markup in SJ's Glade files. As the arguments are a list of (PangoAttrType, value) tuples would it makes sense to terminate with PANGO_ATTR_INVALID (which is 0), rather than -1? Does gcc differentiate between 0 and NULL when you mark a function with G_GNUC_NULL_TERMINATED? I've a feeling it would (due to the different types) but I'm not sure. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
Hi, On Tue, 2007-03-13 at 07:52 +, Ross Burton wrote: > As the arguments are a list of (PangoAttrType, value) tuples would it > makes sense to terminate with PANGO_ATTR_INVALID (which is 0), rather > than -1? The current implementation allows both 0 and -1 to terminate the list. I don't have a strong opinion which one should be preferred but it would be nice if both could be accepted since that would make it easier for us to deprecate the gimp variant at some point. Behdad is probably right that this code should be in Pango. But it would still be convenient if GTK+ could wrap the call to pango_attr_list_new_something() into gtk_label_set_attr_list() or similar. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
Hi, On Mon, 2007-03-12 at 18:44 -0400, Behdad Esfahbod wrote: > Feel free to file a bug. I have filed bug #41 against Pango. I might want to file another bug against GTK+ later and let it depend on the Pango bug. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
