Another gtk_text embedded widget problem



I spent yesterday afternoon reading through the gtk_text sources and
thinking about how to make it into a suitable Web page display widget.
Conceptually, it shouldn't be that hard, but I forsee at least one
additional snag.

   The problem is how to move the embedded widgets around when
scrolling. The most straightforward way is to call size_allocate on the
child widget with new (x,y) coordinates - the width and height stay
constant. Unfortunately, for most NO_WINDOW widgets (including
gtk_preview, which is used for image display), size_allocate blanks the
widget. Thus, it will flash something terrible.

   What's needed is a way to move the widget without causing repaints. I
think the fundamental problem here is that the gtk design mashes
repainting and size negotiation together in the same mechanism. There
are times you want to resize (or at least move) the widget without
repainting it (including most of gzilla), and there are other times you
want to repaint a widget without resizing it (as in Shawn's gtkcalendar
widget).

   In any case, there is a hack that will probably work well, but makes
me uncomfortable anyway because it seems to violate the object
encapsulation: update the child widget's allocation.{x,y} fields at the
same time as actually scrolling the pixmap, then call size_allocate on
the child widget. In most cases, this size_allocate will be a no-op
because the allocation given as an argument will match the allocation.
But futzing with an object's fields seems wrong. I suppose it would be
possible to add a non-clearing size_allocate method, but that's YAWM
(yet another widget method) and I've proposed quite a few of those
recently.

   Another way around the problem would be to put each paragraph in its
own window. Then, the underlying windows could be moved around, carrying
all child widgets with them, making it unnecessary to do size_allocate
calls on the child widgets at all, at least for scrolling. Actually, if
you want to avoid flashing when the size of the paragraph changes, you
have to use two windows: a large one that doesn't change size (like
gtk_page now), and a viewport opening on the large window that does
change size. It's kind of analogous to double-forking :-)

   It looks like my prediction that gzilla would be a stress test of gtk
is turning out to be quite true.

Raph



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