[Glade-devel] Multiple toplevels in GladeDesignView

[Tristan Van Berkom]

On Wed, 2011-01-26 at 16:40 +0900, Tristan Van Berkom wrote:
> 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 :)

One more minor bug:
   When there is no widget in the project, the background
of the GladeDesignView is grey and not white... when adding
a single window, the background it white only for the height
of the window (and the rest bottom portion still grey).

You probably know that already... just noting... probably
just need to set the background to be grey (maybe using
GtkStyleContextFoo on the GladeDesignLayout).

Cheers,
     -Tristan