[Glade-devel] Multiple toplevels in GladeDesignView
Tristan Van Berkom
tristanvb at openismus.com
Fri Jan 28 04:25:27 EST 2011
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
More information about the Glade-devel
mailing list