Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » Glade
  • » [Glade-devel] Multiple toplevels in GladeDesignView [RSS Feed]

#1 Jan. 26, 2011 01:27:00

Juan P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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.

greets

Juan Pablo

_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#2 Jan. 26, 2011 07:28:27

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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.

Cheers,
-Tristan


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#3 Jan. 26, 2011 07:33:17

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#4 Jan. 26, 2011 07:41:07

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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



_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#5 Jan. 26, 2011 23:18:18

Juan P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


I think I have all the ui pretty much covered.
GladeDesignLayout shoud not need any other change

Screenshothttp://imagebin.org/134540here


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.


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#6 Jan. 27, 2011 13:16:28

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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
>
> Screenshothttp://imagebin.org/134540here
>
>
> 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...).

Sounds reasonable ?

Cheers,
-Tristanpalette.gladeDescription:application/glade_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Attachments:
attachment palette.glade (11.7 KB)

Offline

#7 Jan. 28, 2011 09:17:49

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


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
> >
> > Screenshothttp://imagebin.org/134540here
> >
> >
> > 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


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#8 Jan. 30, 2011 00:39:00

Juan P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


On Fri, 2011-01-28 at 18:25 +0900, Tristan Van Berkom wrote:

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

Yeah me too, but i think its unrelated, we I add a group i get this
warning. That would explain why the widget does not show up.

(lt-glade:9405): Gdk-WARNING **: gdk_window_set_composited called but
compositing is not supported

I will take a look at that on monday.


BTW
take a look at _glade_design_layout_should_scroll() and tell me if you
can think of anything cleaner to do that.
I also want to add _glade_design_layout_set_name() and call that from
designView project::widget_name_change instead of connecting inside
GladeDesignView but I dont think its a big deal if we leave it how it
is.

greets

JP

_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#9 Jan. 30, 2011 05:02:46

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


On Sat, 2011-01-29 at 21:38 -0300, Juan Pablo Ugarte wrote:
> On Fri, 2011-01-28 at 18:25 +0900, Tristan Van Berkom wrote:
>
> > Hi, I noticed a workspace/selection related bug today that
> > maybe is implicitly fixed by multiple-toplevels.
>
> Yeah me too, but i think its unrelated, we I add a group i get this
> warning. That would explain why the widget does not show up.
>
> (lt-glade:9405): Gdk-WARNING **: gdk_window_set_composited called but
> compositing is not supported
>
> I will take a look at that on monday.
>
>
> BTW
> take a look at _glade_design_layout_should_scroll() and tell me if you
> can think of anything cleaner to do that.

I suppose a private function _glade_design_view_freeze/thaw() would
do the trick to block the project selection change handler while
setting the selection from a GladeDesignLayout.

> I also want to add _glade_design_layout_set_name() and call that from
> designView project::widget_name_change instead of connecting inside
> GladeDesignView but I dont think its a big deal if we leave it how it
> is.

I think that is fine how it is too.

Cheers,
-Tristan


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

#10 Jan. 30, 2011 05:14:29

Tristan V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Glade-devel] Multiple toplevels in GladeDesignView


On Sun, 2011-01-30 at 14:10 +0900, Tristan Van Berkom wrote:
> On Sat, 2011-01-29 at 21:38 -0300, Juan Pablo Ugarte wrote:
> > On Fri, 2011-01-28 at 18:25 +0900, Tristan Van Berkom wrote:
> >
> > > Hi, I noticed a workspace/selection related bug today that
> > > maybe is implicitly fixed by multiple-toplevels.
> >
> > Yeah me too, but i think its unrelated, we I add a group i get this
> > warning. That would explain why the widget does not show up.
> >
> > (lt-glade:9405): Gdk-WARNING **: gdk_window_set_composited called but
> > compositing is not supported
> >
> > I will take a look at that on monday.
> >
> >
> > BTW
> > take a look at _glade_design_layout_should_scroll() and tell me if you
> > can think of anything cleaner to do that.
>
> I suppose a private function _glade_design_view_freeze/thaw() would
> do the trick to block the project selection change handler while
> setting the selection from a GladeDesignLayout.
>
> > I also want to add _glade_design_layout_set_name() and call that from
> > designView project::widget_name_change instead of connecting inside
> > GladeDesignView but I dont think its a big deal if we leave it how it
> > is.
>
> I think that is fine how it is too.
>

I built the branch and found something else... it seems
you made the right change to watch visibility-changed,
but now it fails to catch the signals GladeProject::add-object
and GladeProject::remove-object.

So the current effect is when I load a glade file only one
widget shows up in the workspace :-/

Maybe we also have to review where glade_widget_show() is
called.. I guess widgets should be visible by default until
explicitly hidden ?

Cheers,
-Tristan


_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/glade-devel

Offline

  • Root
  • » Glade
  • » [Glade-devel] Multiple toplevels in GladeDesignView [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support