Re: Convenience functionality for text



Owen Taylor <otaylor@redhat.com> writes:
> [ warning, this is more of a rambling brainstorm rather than
>   a coherent mail for which I expect responses. But responses
>   woudl be appreciated anyways. ]  
>

I'll weigh in with my rambling, on the "two rambles better than one"
principle. ;-) Don't feel like you have to respond, I'm just adding
thoughts.
 
>  int pango_layout_get_pixel_width (PangoLayout *layout);
>

This is exactly what I thought when seeing your initial example,
before hitting page down, so I think it's good.
 
> It might be better, though, to have
> 
>  void pango_layout_get_pixel_size (PangoLayout *layout,
>                                   int          *width,
>                                   int          *height);
> 
> Since height is almost as common, and it is more efficient
> to get both at once.
> 

It seems like you could trivially make it efficient to call
get_pixel_width() and get_pixel_height() separately? Perhaps at
some memory cost though, which may not be worth it. If it isn't fast
to call get_width() and get_height() separately, I think the single
function that returns both is better.
               
>  PangoLayout *layout = gtk_widget_create_pango_layout (widget);
>  gtk_layout_set_text (layout, "Hello", -1);
>  pango_layout_get_pixel_size (layout, &width, NULL);
>  pango_layout_unref (layout);
> 

To me this is the convenience sweet spot. The additional stuff you
suggest below (especially gtk_widget_get_text_size()) seems to break
modularity and encourage replicating all of Pango in the GtkWidget
namespace. (After all, nearly every routine in Pango takes a context
or layout or direction or some other thing we could get from a widget.)

One improvement might be to make gtk_widget_create_pango_layout() take
a "text" arg which can be NULL, much like gtk_label_new(). Of course
this is only good if you almost always set_text immediately.

I think users are going to have to know about PangoLayout, and I don't
think PangoLayout is that hard to understand; it's simply a layed-out
paragraph. There's no real way you could efficiently do fully i18n
text without this concept, and it's a natural concept, not one we're
making up for the sake of programming convenience. 

PangoContext on the other hand is harder to explain, and the above
example code has the virtue of avoiding it. It seems like users mostly
won't need to know about PangoContext.
 
>  pango_context_get_text_pixel_size (gtk_widget_get_pango_context (widget)),
>                                     "Hello", -1,
>                                     &width, NULL);
>

This seems obscure, it's analogous to gdk_gc_string_measure(), which I
guess could make sense if GC's stored a font, but it's still pretty
weird. Also, again I think PangoLayout is inherently more intuitive
than PangoContext. People don't learn about GC's that quickly either.

>  PangoFontDescription *font_desc = pango_font_description_from_string ("Serif 20");
>  gtk_widget_get_text_size (widget, font_desc, "Hello", -1, &width, NULL);
>  gtk_widget_get_text_size (widget, NULL, "Hello", -1, &width, NULL);
>

This seems extra-confusing, since the point of gtk_widget_* is that it
uses the settings from the widget, such as widget->style->font_desc.
 
> A parallel issue is drawing text. Its pretty similar, but in that
> case, the namespace issue is between:
> 
>  gdk_draw_pango_text (drawable, gtk_widget_get_pango_context (widget)), gc,
>                       5, 5, "Hello", -1);
> 
> and :
> 
>  gtk_widget_draw_text (widget, drawable, gc, 5, 5, "Hello", -1);
>

I like gdk_draw_pango_layout() more than these two options for reasons
already mentioned (isn't that function in there already?).

A couple random thoughts:
 - people don't draw text that often anyway, unless they're already 
   delving into the low-level world of GDK
 - for drawing paragraphs, justified text, etc., PangoLayout may
   compare favorably to the old way of doing things   
  
Havoc




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