Re: Creating an aggregating GtkContainer

[Tristan Van Berkom <tvb gnome org>]

On Wed, Nov 18, 2009 at 7:22 PM, Per Hermansson
<hermansson per bredband net> wrote:
> Tristan Van Berkom wrote:
> > On Wed, Nov 18, 2009 at 5:40 PM, Per Hermansson
> > <hermansson per bredband net> wrote:
> >
> > > 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
>
> Thanks, maybe I'm asking for the impossible :)
> Say I use a scroll window for the different subcontainers to allow some
> overflow.
> Would it be possible to listen for signals on the containers and when the
> widgets have gotten their size
> allocated move them if the scrollbars became visible as a result of this.
> The user will then probably experience some flicker as containers are
> repainted and widgets moved.
> Would this be reasonable/possible to implement?

First lets clarify, you are writing a container implementation, technically you
allocate space for the children, usually according to the size they requested.

So best not hook onto signals before properly implementing ->size_allocate()
and ->size_request() for your composite widget (from there you should be
able to manage all the main children - when reparenting a child this should
be all automatic, maybe theres a need for gtk_container_check_resize() in
some corner cases I couldnt say off hand).

Somehow I doubt that you want to move widgets around based on size
reallocation, I think that a well designed application layout should just stand
alone and widgets jumping around will confuse the user more than anything
else.

At any rate, there are nice things you can do like making sure an important
widget in the undetermined size window gets focus and is visible inside the
scrolled window - or remembering scroll positions of various tabs when they
get replaced or reloaded or such.

Cheers,
         -Tristan