Followup questions... Well eventually I found an old email I knew I'd seen somewhere: http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00293.html
Simply utilizing the "size-allocate" signal has worked out very well, but I'm afraid I'm calling it too many times. There are also a few instances where I somehow attempt to allocate negative positions and sizes and GTK spits out a few warnings. All this results in a lot of GUI flickering when I click a button (where does clicking a button emit "size-allocate" signals?). Other than this: http://developer.gnome.org/doc/API/2.0/gtk/GtkContainer.html#size-allocation Where else can I find information on what functions trigger "size-allocate"? Unfortunately, I can't just use my debugger because this old system didn't come with the GTK 2.4 source code. Are there cases where gtk_widget_size_allocate() triggers "size-allocate" on the parent? ~Thanks On 2/15/07, v4r4n <[EMAIL PROTECTED]> wrote: > > I'd really like to implement this old Window Interface library based on > Motif with GtkBoxes, but I simply cannot accurately predict when the > application code needs an hbox or a vbox, or switch an old hbox to a vbox. > The library I'm trying to implement with Gtk must be able to put boxes > within boxes at any location in any order. > > As far as I can tell when looking at the GtkContainers, my only choice is > to attempt to manage everything within GtkFixeds, except that when building > a Gtk GUI, none of the widgets know their dimensions and locations until > they're just about to be rendered. I have been able to pass around some > useful information using gtk_widget_set_size_request(), but as soon as I try > to listen for "configure-event", "size-allocate", or "size-request" and > attempt to make additional gtk_widget_set_size_request()s I start an > infinite loop where the window keeps growing to accommodate its hungry > children. Another negative side effect of using a bunch of > gtk_widget_set_size_request()s everywhere is that I rob the user's ability > to shrink all windows to less than their original sizes (annoying). > > I've been trying to avoid GtkFixed because I'll end up doing a lot of work > that Gtk wants to do for me, but at this point I'm forced to attempt to > manage everything on my own. > > So how am I 'supposed' to disobey Gtk and micromanage every GtkFixed's > position and size when the window is first shown to the user and after they > make their own adjustments? Are "configure-event", "size-request", and > "size-allocate" the core signals I need to focus on or am I going about this > entirely the wrong way? > > An example problem I've run into involves my root application window. > I add a GtkFixed to the GtkWindow to put the rest of the widgets inside, but > when I try to keep the GtkFixed widget the same size as the GtkWindow, so > that the other widgets know how much space they have to work with, the > window just gets bigger every time the GtkFixed asks how big the window is > and fills it up. > > I need some more balanced size negotiation. At what exact point does the > parent know what it has to work with so that the child can calulate how much > of that the child actually wants? > > Suggestions on where to look for extensive use of GtkFixed or other ways > of implementing a lower level packing system would be a big help. > > ~Thanks > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
