Re: Creating an aggregating GtkContainer

[Tristan Van Berkom <tvb gnome org>]

On Wed, Nov 18, 2009 at 5:40 PM, Per Hermansson
<hermansson per bredband net> wrote:
> Brian J. Tarricone wrote:
> > On Wed, Nov 18, 2009 at 10:35, Per Hermansson
> > <hermansson per bredband net> wrote:
> >
> >
> > > My question is if someone knows a good way to implement this.
> > > I've tested with estimating the widgets size and if the sum of all
> > > children
> > > is larger
> > > then the container the next sub-container is used.
> > > One problem is that the widget's size is not known until the widget gets
> > > visible
> > > so I need to workaround that.
> >
> > Without thinking about this too much (so this may not fit your code or
> > use model), you could defer placing widgets in subcontainers until the
> > container is realized.  At that point you'll know their sizes.
> >
> >     -brian
>
> Thanks, this is actually an requirement for me (which I forgot to mention)
> the widgets
> are created at runtime, after containers are realized (when a new printer is
> selected)
> but the subcontainers are placed by glade (before the window is realized).
>
> Is there a way to after the containers (but before widgets) are realized
> detect if a widget
> will overflow a container?

Maybe a simple answer to your question is, since usually the base
size request for your interface is going to depend on system preferences,
such as if buttons will display icons, or the fonts used in labels and the
default sizes that they are using, it is impossible to guess exactly the
size of a widget before actually mapping it and going through the size-request
rigamarole.

You might consider using a scrolled window that may not appear in most cases,
but will allow for some level of overflow tolerance in your dynamic UI.

Cheers,
      -Tristan