[Glade-devel] Multiple toplevels in GladeDesignView

[tristanvb at openismus.com (Tristan Van Berkom)]

On Thu, 2011-01-27 at 22:24 +0900, Tristan Van Berkom wrote:
> On Wed, 2011-01-26 at 20:18 -0300, Juan Pablo Ugarte wrote:
> > I think I have all the ui pretty much covered.
> > GladeDesignLayout shoud not need any other change
> >
> > Screenshot http://imagebin.org/134540 here
> >
> >
> > On Wed, 2011-01-26 at 16:48 +0900, Tristan Van Berkom wrote:
> > [...]
> > > > 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 think i can fix that adding a dummy widget at the end of the vbox and
> > making it expand.
> >
> > > > I'm happy to see that when selection changes the
> > > > design view scrolls to the position of the widget's
> > > > toplevel... really nicely done :)
> >
> > I have to make it a little bit more smart in the sense that it should
> > not change the position if the widget is fully visible, and perhaps
> > animate it.
> > But i will take a look at that after i fix the code
> >
> > > 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).
> >
> > Yeah, I just fixed that drawing the base color of the widget state.
>
> Cool, I tried it and it all looks very nice.
>
> Some things:
>   - When clicking on the resize-grip-window-title-tab-thingy,
>     it would be nice to cause that to select the window
>     (I don't know, it just feels strange to me that selection
>     doesn't follow the window you are currently interacting with).
>
>   - We still have the 2 bugs:
>
>     o When I open the glade file with a toolpalette that
>       I'm attaching here... the group-header widget still
>       goes into the workspace instead of into the palette.
>
>     o When I open glom.glade, some widgets dont get their
>       full vertical size, I have no idea why that's happening
>       but I suspect that the GladeDesignLayout is not requesting
>       enough vertical space (this bug naturally never showed 
>       before because the request of a scrollable widget is
>       somewhat unimportant, it always receives the full size
>       of the scrolled window content area anyway).
>
> I know you're aware of these bugs already, just wanted to sum up
> where we are with the branch... we can merge as soon as we fix
> these 2 problems.
>
> As I mentioned in a previous mail, adding widgets to the
> GladeDesignLayout needs to follow the GladeWidget's visible
> state... so... when adding a toplevel widget to the project;
> the GladeWidget's visible state has to be checked... furthermore,
> when glade_widget_show/hide() is called, it has to cause the
> widget to be added/removed from the GladeDesignLayout where
> appropriate (i.e. if glade_widget_show() is called on a previously
> hidden GladeWidget *and* the GladeWidget is indeed toplevel *and*
> it's in the project... then it should appear).
>
> I think this can be done pretty straightforwardly by adding
> a signal to the GladeProject and a property to the GladeWidget:
>
>   - GladeWidget:visible property
>
>   - GladeProject::widget-visibility-changed signal with a 
>     signature like:
>
>     void visibility_changed (GladeProject *project,
>                              GladeWidget  *widget);
>
> By handling the "visibility-changed" signal of GladeProject
> and by inspecting glade_widget_is_visible() add "add-object"
> time, the GladeDesignView should be able to easily add/remove
> toplevels from itself according to the project and visible
> state of widgets (glade_widget_show/hide() would then be
> responsible for notifying the project and calling
> glade_project_notify_visibility_changed() to notify about 
> widget visibility...).

Hi, I noticed a workspace/selection related bug today that
maybe is implicitly fixed by multiple-toplevels.

In current master, I dont see the selection painted
on a GtkToolPaletteGroup's custom "header widget".

I guess the right semantic to check if one should
paint selection for a said project selected widget
in a GladeDesignLayout should be:

if ((layout = gtk_widget_get_ancestor (selected_widget, 
                                       GLADE_TYPE_DESIGN_LAYOUT) &&
    layout == this_layout)
 {
   paint_selection();
 }

... rather than glade_widget_get_toplevel().


Cheers,
        -Tristan