[Glade-devel] Implementing preview feature in glade

[tristan.van.berkom at gmail.com (Tristan Van Berkom)]

2009/3/24 Marco Diego Aur?lio Mesquita <marcodiegomesquita at gmail.com>:
> Let's go slowly...

Heh, I was surprised how quick you were starting out, figured I'd lay
it on ;-) ... ok ... have you dealt with any stdin/stdout piped ipc
programming before ? ... if not I can help you out with that its not
big a deal (we dont have anything fancy like dbus at our disposal
since were portable, but for our purposes some GIOChannels
on stdin/stdout will do the trick).

> 2009/3/24 Tristan Van Berkom <tristan.van.berkom at gmail.com>:
> > [...]
> >
> > So now you have a glade_project_save & glade_project_save_full or
> > something, so your going to want to export glade_project_preview
> > (GladeProject *project, GladeWidget *widget),
>
> What? Why? Should I write a function called glade_project_preview?
> What should I do with its parameters?

glade_project_preview() will be the entry point to spawn the preview,
we need an entry point in the core (glade3/gladeui/..) ... and then we
will access the feature either from the plugin (glade3/plugins/gtk+/...)
by way of action context menus... or we could also access it from the
frontend (glade3/src/...) by way of the project or view menu (or alternatively
in other frontends, like Anjuta).

> > from here you'll want to add the io channel/spawn with pipes code, so from
> > there you can pass the buffer to the "preview" app via its stdin.
>
> I would like to let the preview be a modal option. So that the user
> could edit the interface, then preview it, then close the preview to
> continue editing it.

Hmmm, generally we dont like modal dialogs, I've gone to some
lengths to make sure the widget editor dialogs dont have to be
modal, there is also something tricky to that: writing portable
code that will make a window from a foreign process "transient".

The main reason why I want the preview to be in a separate
process (btw) is because unfinished Glade files are untrusted; I'd
much rather crash a child process and report a usable error about
why GtkBuilder may have aborted than crash Glade in a preview
routine.

What if a preview could be updated ? (i.e. when the project changes
then the preview is updated, until the preview window is closed and
exits or is killed because a project was closed)... we can also
add "raise-to-front" commands to the preview process and avoid
spawning multiple previews for the same ancestry (may have
some issues when toplevels get parented... can get to that later)

Now, not all of this needs to be done at once ofcourse...

> Some doubts remain:
> Where and how should I send my patch?

bugzilla.gnome.org, enter a bug for the glade3 product and Juan and I will
receive bugmail about it and track the patches etc.

> What to do with projects that do not have a toplevel widget?

The preview can create a toplevel and child the widget, a
prerequisite of glade_project_preview (GladeProject
*project,GladeWidget * widget) is
that (GTK_IS_WIDGET (widget->object) && widget->parent == NULL)
(i.e. a preview is created for a GladeWidget which must be a toplevel
project object,
and it must wrap a GtkWidget).

> What to do with projects that have many toplevel widgets?

Another reason why we have the api that includes a widget specific parameter ;-)

> (It doesn't even work if the project doesn't have a widget called "window1")

... And the GladeWidget parameter has a member widget->name, which will
be the name of the widget to display in the project ... look at bleeding edge
builder apis, if Im not mistaken your now allowed to build fragments of the UI
instead of the whole file (like we had with libglade).

Then I guess the best way to integrate the feature will be via an
"important" action in the plugin, actions are implemented at a
widget class level and available in the context menu in the workspace
or inspector; "important" ones also show up in the main toolbar.

The actions are outlined here actually:
   http://glade.gnome.org/docs/widgetclasses.html
(actually, if you havent seen the docs, you should check em
out/skim over them; I rewrote them last summer and they describe
the core/plugin relationship pretty well)

OK, so I said alot, what would we need I guess for a first revision
of preview ?
  - a preview main built and installed from glade3/gladeui (glade-3-preview ?)
  - a basic expandable protocol outline for communication between the glade core
    and the preview (luckily now we have portable GChildWatchSources which will
    make this easier...), this protocol has to implement only 2 commands:
      - the initial preview command along with the transmission of the
project glade
        file and the widget name to preview.
      - the kill command (which results in the preview exiting)
  - GladeProject to maintain a list of running previews and kill them
at close time,
    update it when they exit on their own (using GChildWatchSource)
  - An action in the GTK+ plugin in the base GtkWidget adaptor
definition to spawn
    the preview (i.e. one line in the catalog and a few added lines to
glade_gtk_widget_action_activate()
    in glade-gtk.c)

The hard part is the IPC, but since were not doing really time critical stuff
then synchronization shouldnt be a problem.

Anyway... let me know what you think...