One preview per "topmost" widget

[Marco Diego Aurélio Mesquita]

This is my plan to implement one preview per "topmost" widget in glade:

- Escalate the widget tree (using gtk_widget_get_parent).
- Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
- If it is already been previewed, update the whole interface.
- If not, launch a preview.

Seems pretty simple. Is there any problem with this strategy?
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

 - Escalate the widget tree (using gtk_widget_get_parent).
 - Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
   - If it is already been previewed, update the whole interface.
   - If not, launch a preview.

The association should not be by name, widget names
can change during a running preview.

Perhaps GladePreview object must be an object belonging
to the GladeWidget itself... when the toplevel gets a parent
added to it... the preview should then be placed on the parent.

Something like that.
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Marco Diego Aurélio Mesquita]

Post by Tristan Van Berkom

 - Escalate the widget tree (using gtk_widget_get_parent).
 - Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
   - If it is already been previewed, update the whole interface.
   - If not, launch a preview.

Perhaps GladePreview object must be an object belonging
to the GladeWidget itself... when the toplevel gets a parent
added to it... the preview should then be placed on the parent.

Hmmm... This is fundamentally different from what we're doing right
now. What you're proposing would include an api extension to
GladeWidget so that it would have a preview method and take care to
kill the previewer process by the destructor (most of it is treated by
GladeProject now), is that?
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Marco Diego Aurélio Mesquita

Post by Tristan Van Berkom

 - Escalate the widget tree (using gtk_widget_get_parent).
 - Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
   - If it is already been previewed, update the whole interface.
   - If not, launch a preview.

Perhaps GladePreview object must be an object belonging
to the GladeWidget itself... when the toplevel gets a parent
added to it... the preview should then be placed on the parent.

Hmmm... This is fundamentally different from what we're doing right
now. What you're proposing would include an api extension to
GladeWidget so that it would have a preview method and take care to
kill the previewer process by the destructor (most of it is treated by
GladeProject now), is that?

No, that code must be moved into a GladePreview object anyway,
other than that yes the preview would have to be launched by
GladeWidget.
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Marco Diego Aurélio Mesquita]

Post by Tristan Van Berkom

Post by Marco Diego Aurélio Mesquita

Post by Tristan Van Berkom

 - Escalate the widget tree (using gtk_widget_get_parent).
 - Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
   - If it is already been previewed, update the whole interface.
   - If not, launch a preview.

Perhaps GladePreview object must be an object belonging
to the GladeWidget itself... when the toplevel gets a parent
added to it... the preview should then be placed on the parent.

Hmmm... This is fundamentally different from what we're doing right
now. What you're proposing would include an api extension to
GladeWidget so that it would have a preview method and take care to
kill the previewer process by the destructor (most of it is treated by
GladeProject now), is that?

No, that code must be moved into a GladePreview object anyway,
other than that yes the preview would have to be launched by
GladeWidget.

Ok.

What about changes? Does GladeWidget has events to treat it?
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Marco Diego Aurélio Mesquita

Post by Tristan Van Berkom

Post by Marco Diego Aurélio Mesquita

Post by Tristan Van Berkom

Post by Marco Diego Aurélio Mesquita
- Escalate the widget tree (using gtk_widget_get_parent).
- Check (using gtk_widget_get_name and a list of the names of
widgets currently been previewed) if such widget is already been
previewed.
- If it is already been previewed, update the whole interface.
- If not, launch a preview.

Perhaps GladePreview object must be an object belonging
to the GladeWidget itself... when the toplevel gets a parent
added to it... the preview should then be placed on the parent.

Hmmm... This is fundamentally different from what we're doing right
now. What you're proposing would include an api extension to
GladeWidget so that it would have a preview method and take care to
kill the previewer process by the destructor (most of it is treated by
GladeProject now), is that?

No, that code must be moved into a GladePreview object anyway,
other than that yes the preview would have to be launched by
GladeWidget.

Ok.
What about changes? Does GladeWidget has events to treat it?

In the case that a project toplevel gets a parent widget
assigned, that can be tracked via ->add_child() and
->replace_child() vfuncs.

Also we're going to want to make sure we kill previews
for toplevel widgets that are removed from the project, i.e.
deleted or "cut" widgets.

Cheers,
-Tristan

Post by Marco Diego Aurélio Mesquita
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listin