Re: treeview/scrolled box resizing

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 11 Apr 2010 11:41:54 -0400
MK <halfcountplus intergate com> wrote:

> Murray Cumming wrote:
> >MK wrote:
> > >  It's kind of beyond stupid that anyone would think this
> > > would count as "functional" under any circumstances...much less
> > > make it incredibly awkward to impliment anything else?????????
> > 
> > This does not make me want to help you.
> 
> I apologize for being hyperbolic, I can see now this looks
> petulant.  I do think there is a sort of design oversight here, but
> sorry again for putting it like that.
> 
> > > GtkAttachOptions to GTK_SHRINK. Cannot I not do this in gtkmm,
> > > and/or with boxes?
> > 
> > Yes, you can:
> > http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-multi-item-containers.html.en#sec-table
> > http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-multi-item-containers.html.en#sec-boxes
> 
> Okay, I have already been doing this, packing options alone are not
> enough. My diagnosis of the issue was a little bit off, in fact what
> prevented the expansion in my previous code was setting widget sizes
> before they are realized, and then leaving them to expand *if* the
> window is made larger manually.  Part of the "oversight" in my mind is
> that the window cannot then be resized smaller, meaning the only way
> to prevent this infinite expansion is to set an arbitrary size *before
> realization.*
> 
> So I'm looking for insight or suggestions.  What I'd like to do is
> allow the window to realize itself, check the size against the
> DisplayWidth/DisplayHeight from Xlib, and then shrink the window down
> if it exceeds the margins using signal_configure_event().  AFAICT,
> however, that is not possible with gtk -- once the widgets have been
> realized unconstrained, subsequent resize requests to become smaller
> are ignored. I have done a little bit of lower level Xlib programming
> and I am sure this is not a window manager issue, it is an internal
> policy of gtk.   
> 
> What it means is that I will have to set an initial minimal size,
> allowing the window to be enlarged by the user.  It is also
> unfortunate that a gtk set size request requires a commitment in both
> dimensions (again, this is not a limitation imposed by X), since in
> this case the issue is only a height issue.
> 
> I'm curious to hear how other people have dealt with this. 

I am not at all clear what you are trying to do, but if it is a way of
dealing with the issue in your first post, namely "I have a treeview
associated with a scrollbar in a box, but I no matter what, the
treeview insists on resizing to 'show' all of it's contents, making the
scrollbar useless, and possibly extending the window way off the bottom
of the screen (making the whole thing useless)", then I have never had
a scrolled window behave other than in the correct way with a tree view,
namely not to resize in the way you mention but to scroll instead.

Possibly you haven't called Gtk::ScrolledWindow::set_policy().  If it
is not that there must be some other oddness in your code.  Out of
interest though, does it make any difference if you explicitly call
Gtk::Container::add() to insert the tree view rather than the overridden
version for the scrolled window?  If it does, for some reason in your
implementation the scrolled window add() method must be calling
gtk_scrolled_add_with_viewport() rather than gtk_container_add() (it
should be calling gtk_container_add()/Gtk::Bin::add() in the case of
a tree view).

Chris