Re: Resizing widgets and GtkScrolledWindow
- From: nicholas allen <nicholas allen ireland sun com>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Resizing widgets and GtkScrolledWindow
- Date: Fri, 13 Jul 2001 17:27:26 +0100
Thanks Havoc again for your speedy response! Calling
gtk_widget_size_request for the children of my custom widget is easy
enough because I can just ignore their requests. However, if I have to
call gtk_widget_size_allocate from the custom container class's
size_allocate this will change the bounds of the child widget and I
really don't want to do this as I want layout managed by Java (not GTK).
I could maintain a cache of where Java wants every widget to be in some
kind of hash table (or better still in a child structure a bit like
GtkFixed does) and then just call gtk_widget_size_allocate using this
information to ensure they are in the same place as Java left them. This
would be pretty messy though and also quite inefficient as the layout
would effectively be done twice (once by Java and then again by gtk) and
I would have to duplicate the layout information, thus using more
memory, that would otherwise be done in Java only (actaully this
wouldn't be stored notmally but derived on the fly). It is possible, of
course, but not the most ideal solution.
Do you know why a container must allocate its children when it is
allocated? This seems quite strange/unnecessary to me. In Java,
containers can have a "null" layout manager which means that components
will be left exactly where you left them and no layout will be done when
the container changes size. This is the kind of thing I'm trying to
achieve in Gtk. I would have thought that such a feature would be possible.
Basically this is what my size allocate fuction looks like:
static void
awt_gtk_panel_size_allocate (GtkWidget *widget, GtkAllocation *allocation)
{
widget->allocation = *allocation;
if (GTK_WIDGET_REALIZED (widget))
gdk_window_move_resize (widget->window,
allocation->x,
allocation->y,
allocation->width,
allocation->height);
}
As you can see it is very minimilistic and does not call
gtk_widget_size_allocate on its children.
Maybe I could just call gtk_size_allocate on the children using their
curtrent allocation. This would have the effect of doing nothing I guess
but still ensure the method is called. I'll try this anyhow....
Thanks again,
Havoc Pennington wrote:
Hi,
ScrolledWindow relies more heavily than your average widget on the way
GTK's size request/allocate cycle works; so that's probably where
you're running into trouble.
Owen can probably list the invariants that need maintaining better
than me. One is that you want to call gtk_widget_size_request() on
children of your custom widget when the custom widget is size
requested, even if you don't really care about their size
request. This is because a) you must always request at least once
before you allocate and b) some widgets will assume they get a size
request when a resize is queued on the toplevel window, e.g. this
happens when the theme changes. So you want to be sure you kept the
size_request implementation from GtkFixed, at least to the extent that
you still request all widgets.
The same basic thing is true of allocate, when the fixed is allocated
you need to allocate all children.
If that doesn't help and Owen can't guess the problem you might want
to email us your custom container code and we can try to figure it
out. We are eager to have working Java for GTK. ;-)
Havoc
--
Nick Allen
Software Engineer
Sun Microsystems Ireland Ltd
Hamilton House
East Point Business Park
Dublin 3
email: nicholas allen ireland sun com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]