[Glade-devel] Future of the preview feature

[Tristan Van Berkom]

On Tue, 2010-10-12 at 11:55 -0300, Marco Diego Aurélio Mesquita wrote:
> Hi devs!
> 
> Now that the preview feature will finally get in, it is time to think
> about future improvements for the feature. One that can be clearly
> seen, is to separate the preview functions defined in glade-project to
> another class. That would make the code a lot cleaner.
> 
> On the previewer side, there are many things that can be experimented
> with. My main feeling is a "dynamic preview", where changes to a
> project are automatically propagated to the preview. Implementing
> dynamic previews would require to extend the protocol used between
> glade and glade-previewer. The simplest way would be to just use a tag
> like "<update>" and then send the new ui definition with the
> modifications that were made.
> 
> Destroying the preview window and creating a new one to reflect the
> changes is ugly and suboptimal. Another idea (richer but not simpler)
> would be to extend the protocol to tell glade-previewer which changes
> were made. I can see 3 types of changes that could be transformed in
> tags for the protocol: property changes, removal of widget and
> addition of widget.
> 
> Changing a property would be easy to propagate to glade-previewer; all
> that is needed is a tag like <change_property object="object_name"
> property="property_name" value="new_value">. Parsing and committing it
> would not be so simple, but do-able.
> 
> Removing a widget is as simple as telling glade-previewer the widget
> to be removed (maybe we'll have tell the widget to be removed and
> which widget is its parent). A tag could be <remove_widget
> parent="parent_name" widget="widget_name">.
> 
> Adding a new widget would be a bit more complicated, but still
> do-able. The previewer would have to know which widget is the parent
> of the new widget and the ui definition of the new widget. This can be
> achieved by a tag like <add_widget parent="parent_name"> followed by
> the ui definition of the new widget.
> 
> Also I'm thinking on other improvements that can improve usefulness of
> a preview, like selecting in glade the widget that has been clicked in
> the preview or adding a new widget to a container in the project if
> the user clicks a widget in the palette and then on a container on a
> preview.
> 
> What do you think about it? Comments? Suggestions?

Kindof contradictory to your original stance which was, "a preview is a
snapshot of the current project state", the user can spawn as many
previews as they wish.

I'm not sure which approach I prefer, however originally I wanted
"one preview per project" or at least "one preview per toplevel"
which would be updated on project changes or simply have
it's window raised when the user redundantly asks for a new
preview of the same window.

The current implementation however is "sweet and simple", regardless
of the desktop pollution it potentially creates by allowing the user to
popup tons of preview snapshots.

In the end, it's important for us to decide on a single approach
for the preview before the next major release - probably around
the same time as GTK+ 3.0 release, and best we stick with that
approach for the long term.

I'd like to hear any opinion other readers may have on this.

Cheers,
       -Tristan

(oops replied this one privately by accident, re-replying
to the list).

> _______________________________________________
> Glade-devel maillist  -  Glade-devel at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/glade-devel