[Glade-devel] Multiple toplevels in GladeDesignView

Tristan Van Berkom tristanvb at openismus.com
Wed Jan 26 02:40:56 EST 2011


On Wed, 2011-01-26 at 16:36 +0900, Tristan Van Berkom wrote:
> On Tue, 2011-01-25 at 22:26 -0300, Juan Pablo Ugarte wrote:
> > Hello guys, I just created a new branch multiple-toplevels
> > and pushed a quick hackish implementation to see how it would look like
> > to have multiple toplevels in the same GladeDesignView
> > 
> > Comments are welcome, specially about functionality and stuff like that
> > 
> > I know the implementation is just a hack, but i think discussing how to
> > best implement this could lead to some nice cleanups.
> 
> I quickly looked at the branch.
> 
> Actually I dont mind that the design-view adds/removes widgets to
> the layout by itself... however as I mentioned on irc last night,
> this has to dynamically change when a GladeWidget becomes
> visible/invisible (i.e. glade_widget_show/hide())
> 
> Currently the GladeWidget already tracks a "visible" flag, 
> it should be exported as a property and have a
> glade_widget_get_visible() api so that GladeDesignView
> can check that to decide whether or not to add the child
> to the view.
> 
> So probably all this needs:
>    - A project signal to indicate that GtkDesignView's connected
>      to the project should update which child is visible
>      "widget-visibility-changed" for instance.
> 
>    - An exported property and api from GladeWidget for
>      GladeWidget->priv->visible
> 
>    - glade_widget_show/hide() to provoke the project signal
>      to fire
> 
>    - GladeDesignView to catch the "visibility-changed" signal
>      on it's GladeProject and update visible toplevels from
>      there.
> 
> I also like how the GladeDesignView updates the selection of
> it's internal GladeDesignLayouts based on project selection
> changes, this should however get rid of the code in 
> glade_project which does this explicitly.
> 

Also, after testing it briefly I noticed a bug.

When many toplevels are present (I tried it when
loading glom.glade for instance), some dialogs dont
get the full height that they need (i.e. the bottom
portion of the GladeDesignLayout is "clipped" out
of the view, so one cannot view the whole widget
and one cannot vertically resize that widget).

I'm happy to see that when selection changes the
design view scrolls to the position of the widget's
toplevel... really nicely done :)

Cheers,
        -Tristan




More information about the Glade-devel mailing list