Re: Problems with Gtk::Expander

[Jef Driesen <jefdriesen hotmail com>]

Jonathon Jongsma wrote:
> On 12/1/06, Jef Driesen <jefdriesen hotmail com> wrote:
> > I have created a toplevel window like this:
> >
> > <window>
> >    <vbox>
> >      <expander>
> >        <treeview>
> >      <table>
> >        <label><entry>
> >        <label><entry>
> >        ...
> >
> > The glade file is available on my website [1].
> >
> > The labels and entries in the table have a fixed height. Thus, resizing
> > the window should change the size of the treeview (if it's not hidden by
> > the expander of course). But it doesn' work the way I want it.
> >
> > The window starts with the expander collapsed. When I use the arrow to
> > expand it, the arrow changes its state, but the treeview remains
> > invisible. See screenshot [2]. Only when I enlarge the toplevel window,
> > I can make the treeview visible. It seems like the initial height of the
> > treeview is zero? If I replace the treeview with another widget like a
> > button, it is shown instantly (e.g. without enlarging the toplevel window).
>
> This is probably because the treeview doesn't specify a minimum size /
> size request, whereas a button does.  If you set a minimum size, it'll
> probably expand the window when you expand the expander.
>
> > Now, if I collapse again, the treeview disappears like it should, but
> > the space where it used to be remains empty. See screenshot [3]. And
> > that's not certainly not what I wanted. This empty space should be gone
> > and the toplevel window should shrink. How can I do that?
>
> I think this is a pretty common issue with GTK apps.  I think the
> general solution is: avoid designing your UI so that the top-level
> window can change size based on user interaction.  However, there are
> a couple of things you can do.  One is to connect to the expander
> activation signal, and resize your window manually (note: I think if
> you set the height to some small value like 1 then GTK will try to
> make it as small as it can while still showing all widgets, but then
> the user will lose any resizing they did before they collapsed the
> window).  Another option is to make your window non-resizeable, and
> then GTK+ will automatically shrink the size when you collapse the
> expander.  Of course the disadavantage of this is that your window is
> ... non-resizeable.

I found a partial solution to my problem. If I remember the width and 
m_height, I can restore the previous window size:

void
expander::on_expander_changed()
{
   if (m_expander->get_expanded()) {
      this->resize(m_width, m_height);
   } else {
      this->get_size(m_width, m_height);
      this->resize(1,1);
   }
}

Now, there is still a problem if the window is resized in the collapsed 
state. The extra space is assigned to the expander because it was packed 
with expand and fill settings enabled (which is the correct behavior in 
the expanded state). But in the collapsed state, I want that extra empty 
space at the end of the window. Making the window non-resizable in the 
collapsed state (like the gtk 'save as' dialog does) is not the right 
solution, because the expander is inside a notebook and other pages can 
still benefit from being resized.

I think changing the expand and fill settings of the expander will fix 
this too. Is there a way to change them after they are already packed to 
the container?