Discussion:
Future of the preview feature
Marco Diego Aurélio Mesquita
2010-10-12 14:55:24 UTC
Permalink
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?
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
Tristan Van Berkom
2010-10-12 18:00:05 UTC
Permalink
Post by Marco Diego Aurélio Mesquita
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).
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.co
Marco Diego Aurélio Mesquita
2010-10-12 18:11:06 UTC
Permalink
Post by Tristan Van Berkom
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.
After using the feature a little, I changed my mind a bit. But I'm
still not sure which way is better. Having snapshots seems good but
having tons of open previews is bad.
Post by Tristan Van Berkom
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 think both options can co-exist without causing feature bloat. The
popup menu can be used to launch snapshot previews, while the toolbar
button can be used to launch dynamic previews for the current toplevel
(if there is one).

(oops replied this one privately by accident, re-replying
to the list).
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
Marco Diego Aurélio Mesquita
2010-10-12 20:07:51 UTC
Permalink
Hi devs!

I just talked with tristan on IRC about this subject. This is what happened:

(16:45:39) Marco: tristan: hi!
(16:45:51) tristan: hey Marco
(16:46:00) tristan: damn its late
(16:46:05) Marco: :/
(16:46:10) tristan: heh
(16:46:12) Marco: can we talk about the preview feature?
(16:46:23) tristan: tried to stay up for gtk+ meeting
(16:46:29) tristan: we'll see if I last
(16:46:52) tristan: about preview feature, well I guess... for a bit
(16:47:33) Marco: well, do you really think having snapshot previews
alongside dynamic previews would cause feature creep?
(16:48:06) tristan: I think so
(16:48:13) Marco: hmmm
(16:48:13) tristan: however that's not what I said on the list ;-)
(16:48:17) tristan: but now that you ask
(16:48:22) tristan: yes I kindof think so
(16:48:57) Marco: what about my idea of having the toolbar button for
dynamic previews and the popup menu for snapshots?
(16:49:28) tristan: eh
(16:49:48) Marco: ?
(16:50:06) tristan: I'm not so hot on the idea of having the toolbar
do something different from the menu
(16:50:18) tristan: actually I'm leaning towards unifying it more
(16:50:33) tristan: i.e. the menu should take the input GladeWidget
and crawl up the hierarchy
(16:50:37) tristan: only show the toplevel
(16:50:50) tristan: another thing that needs fixing actually I noticed
(16:50:50) Marco: hmmm...
(16:50:55) Marco: seems reasonable
(16:50:57) tristan: projects dont all have GtkWindows
(16:51:23) tristan: so.. when using the toolbar preview, I think I saw
some test for GTK_IS_WINDOW
(16:51:39) tristan: i.e. if there's no selected widget
(16:51:55) tristan: it should also just use the first topmost GladeWidget
(16:52:38) tristan: dynamic previews are going to be tough to do
(16:52:40) Marco: hum... yes, there is such test
(16:52:54) tristan: for toplevels, we dont want to recreate the
toplevel every time
(16:53:08) Marco: but doesn't seems too difficult to fix
(16:53:20) tristan: right, for that test.. that code should consider
that a project can be comprised of toplevel GladeWidgets that are not
GtkWindow
(16:53:30) Marco: ok
(16:53:41) tristan: in the hopeful near future, a project will be
comprised of a handful of Glade files
(16:53:58) Marco: so, what about the protocol to update the ui?
(16:54:00) tristan: i.e., one Glade file to define the UI of every
composite widget in the project
(16:54:31) tristan: another thing would be nice... when a preview is
displaying a toplevel... and the toplevel has a window title
(16:54:51) tristan: the window title should be changed for "Preview:
Original Window Title"
(16:54:56) tristan: that would help
(16:55:01) Marco: ok
(16:55:15) Marco: and, what about the protocol?
(16:55:19) tristan: about the protocol to update the UI, I suppose
ideally when window content changes and its a window
(16:55:30) tristan: then we need to not recreate the toplevel
(16:55:37) tristan: just sync its properties
(16:55:44) tristan: and recreate the contents completely
(16:55:53) tristan: better than trying some fancy merge
(16:56:01) Marco: hmmm
(16:56:21) Marco: the toplevel reamains, the rest is rebuilt with new
properties?
(16:57:26) tristan: the whole UI is rebuilt, the present toplevel has
its contents removed and consequently destroyed, the new UI has its
child reparented into the old UI, the original windows properties get
synced to the properties for the new window
(16:57:59) tristan: end of story (much easier and more reliable than
fine grain fixing)
(16:58:44) tristan: Marco, for all of this, it would be best to start with:
(16:59:04) tristan: - Adding GladePreview (represents a preview of a
toplevel project object)
(16:59:24) tristan: (and implements the protocol and its an api to be
used by GladeProject internally)
(16:59:50) tristan: - Start by bookkeeping the running previews by
toplevel GladeWidget
(17:00:11) tristan: i.e. that part is sending the "raise" command to
the preview if a current preview is already running for that toplevel
(17:00:30) tristan: making sure there is only one preview for each
toplevel at a time
(17:00:51) tristan: and handling the case where a toplevel gets a new
parent cleanly
(17:01:22) Marco: ok
(17:01:48) Marco: can send an e-mail explaining it to the devel list?
(or else I'll forget it)
(17:02:20) tristan: Feel free to send one and paste the text from irc
(17:02:35) Marco: ok
(17:02:56) Marco: so, AFAICS, my idea of snapshots will be gone?
(17:03:02) tristan: Marco, getting Glade to compile and work with the
offscreen branch is really my Glade priority right now
(17:03:16) tristan: so dont be offended if I'm latent with previews
(17:03:19) tristan: I'll get to it
(17:03:26) Marco: ok
(17:03:34) Marco: I'm not in a hurry
(17:03:38) tristan: snapshots will dissapear in favour of the new
dynamic preview I think
(17:04:06) tristan: unless people on the list complain, which I doubt
(17:04:27) Marco: now that the patch is in I won't feel bad to spend
some time to design future improvements
(17:04:33) tristan: I think its really best to keep to the context of
a UI designer tool, and be simplest and best usable
(17:04:54) Marco: ok
(17:05:22) Marco: I'll copy-paste it to the list as a reminder. Any objection?
(17:06:11) tristan: sure, reply to the current thread that we had an
irc conversation... that way people will also feel free to comment on
this stuff
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

Loading...