Discussion:
Auto update for the preview feature
Marco Diego Aurélio Mesquita
2011-02-10 01:15:26 UTC
Permalink
Hi Devs!

Auto-updating previews seems a good feature to have and I'm interested
in implementing it. Currently, to update a preview, the whole
interface is sent from glade to glade-previewer. Tristan told me that
if glade is going to have auto updating previews, it must be done with
finer granularity, i.e: sending only the toplevel of the preview that
will be updated.

I decided to take a look on how to do it. It seems that the easiest
way to do it is creating a new function just like glade_project_write
that would take a new argument: the toplevel widget of the preview.
This new function would then generate an xml definition for all non
widget objects plus the widget that is going to be previewed. The
reason why all non widget objects will be on the xml definition is
because it is complicated to determine which one are needed or not for
the toplevel widget to be displayed properly. Is this idea acceptable?

Also, UI-wise, how should the user tell glade that a preview should be
auto update-able?

I think that's all. It doesn't seem too complicated to implement. Any
objection? Thought? Comment?
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
Tristan Van Berkom
2011-02-24 05:57:20 UTC
Permalink
Post by Marco Diego Aurélio Mesquita
Hi Devs!
Auto-updating previews seems a good feature to have and I'm interested
in implementing it. Currently, to update a preview, the whole
interface is sent from glade to glade-previewer. Tristan told me that
if glade is going to have auto updating previews, it must be done with
finer granularity, i.e: sending only the toplevel of the preview that
will be updated.
I decided to take a look on how to do it. It seems that the easiest
way to do it is creating a new function just like glade_project_write
that would take a new argument: the toplevel widget of the preview.
This new function would then generate an xml definition for all non
widget objects plus the widget that is going to be previewed. The
reason why all non widget objects will be on the xml definition is
because it is complicated to determine which one are needed or not for
the toplevel widget to be displayed properly. Is this idea acceptable?
Not exactly but close.

Some widgets and not only non-widget objects can be referred to outside
the widget heirarchy... for instance a GtkImageMenuItem's "image widget"
is a property, not a child (there are a few cases of this).

So what needs to be done here is the heirarchy and it's properties
need to be traversed.

Some thing vaguely like:

recursive_get_dependancies (widget)
{
for (property in properties)
{
if (is_object (property) && !is_default (property))
add_object_value_of_property_to_list (property);
}

for (property in packing_properties)
{
if (is_object (property) && !is_default (property))
add_object_value_of_property_to_list (property);
}

for (child in children)
recursive_get_dependancies (child);
}

The idea here is to go through all properties and packing properties
of all widgets and accumulate the dependant properties in a list
of toplevels that should be sent to preview the said widget.

2 things that are kindof tricky to watch out for:

a.) Glade supports properties that are just a single
GObject property and also properties that are a list
of objects

b.) The toplevel preview object should be passed into
the recursive function as well... the list of toplevels
should not include any duplicates (i.e. any objects that
are already built as a child of another object should
not be serialized twice).
Post by Marco Diego Aurélio Mesquita
Also, UI-wise, how should the user tell glade that a preview should be
auto update-able?
We need a user preferences dialog for Glade that should go at the bottom
of the "Edit" menu... it should have a notebook and one of the tabs
should be reserved for preview options.

Every user preference should be loaded and saved in Glade's
GKeyFile for this (glade_app_config_load/glade_app_config_save).
(We dont use GConf or GSettings from Glade because that's a
dependency that is not guaranteed on all platforms we build for).
Post by Marco Diego Aurélio Mesquita
I think that's all. It doesn't seem too complicated to implement. Any
objection? Thought? Comment?
Sounds good to me... I would like to start with adding the code that
gets only the relevant project portion serialized into
glade_project_preview first and then we can add options for auto-updates
along with a preferences dialog in another patch (there is a growing
list of other candidate options that can go into the preferences dialog
so actually it's long overdue).

Cheers,
-Tristan


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

Loading...