Post by Juan Pablo UgarteI think I have all the ui pretty much covered.
GladeDesignLayout shoud not need any other change
Screenshot http://imagebin.org/134540 here
[...]
Post by Tristan Van BerkomPost by Tristan Van BerkomWhen 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.
Post by Tristan Van BerkomPost by Tristan Van BerkomI'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
Post by Tristan Van BerkomWhen 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...).
Sounds reasonable ?
Cheers,
-Tristan