[gtk-list] gtk issues for gzilla

[Raph Levien <raph acm org>]

Work on gzilla continues apace. I have, however, run into a few small
glitches. Hopefully, the people here will have some answers.

* Only one qualifies as a bona fide bug in gtk. If a label is inside a
scrolledwindow, and you change the label using gtk_label_set, it is not
always redrawn. It should be easy to duplicate this bug by modifying
(say) the timeout example in testgtk. If anyone has trouble doing so,
let me know and I will post code.

* I'd like to set the initial size of the default window to something
like 500x600. Using gtk_widget_set_usize does _almost_ what I want, but
not quite: it sets a minimum size, after which it's possible to do a
window resize to make the window bigger but not smaller. Also, the
window size info displayed by fvwm95-2 while resizing measures how much
bigger the window is than minimum, not the absolute size of the window.
I suspect that this will cause problems when trying to specify the
geometry of the window as well.

* Removing a widget from a scrolledwindow throws one of these:

** WARNING **: file gtkwidget.c: line 767 (gtk_widget_size_request):
"widget != NULL"

   Originally, I was going to jump from doc to doc by removing the old
doc from the scrolledwindow and adding the new, but now I think I'll do
this in a box added between the page and scrolledwindow. There is a
another reason to do this other than just avioding the warning. Thus,
it's not a priority for me that this gets fixed.

* From looking at the code, it appears to me that gtk_preview_size won't
cause a check_resize if the widget is visible. I haven't verified this
in actual code yet. This will be important when an image of unknown size
is created, and the size becomes known later when the image starts
downloading from the network.

* What's the right way for the doc widget to find out the size of the
viewport of the enclosing scrolledwindow (minus the size of the padding
in the enclosing box if there's a box between them)? I think I'll just
walk up the tree by following the parent links until I find one that
meets the gtk_type_is_a predicate for scrolledwindow, then poke around
in the scrolledwindow structure. This feels a little gorpy though - I'd
prefer not to access the widget data structure internals if I can help
it.

* I hope the 0.99.10 release is soon so I can write the HTTP handling
code (which will rely heavily on gdk_input_add) without having to worry
about syntax changes.

   Lest this sound like a gripefest, I want to commend you guys for all
the things you did right. So far, the feeling I've been getting is that
gtk+ is working with me, rather than being the beast I have to fight
against to get the UI I want. Coupling gzilla tightly to the gtk+ widget
hierarchy is increasingly looking like a good idea. For example, the
gtk_table widget is going to make it _much_ easier for me to get tables
right. Gambai!

Raph

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null