Implementing preview feature in glade

[Marco Diego Aurélio Mesquita]

Hi,
I've been implementing a preview feature for glade but I would like
suggestions on the best way to do it.

As of now, the implementation is pretty hackish: it saves a
/tmp/out.glade file, loads it with gtkbuilder, get the window1 object
and shows it.

Of course, doing it this way will not work for projects that do not
have a widget named window1. And it is clear that this is not the best
strategy, so I have several questions on how to do it right.

I will investigate trough glade save functions to find a way to get
the string of the saved file so that it won't be needed to save the
file. But, how can I get the name of a toplevel object in glade?
Should we ask the user witch object to preview? Isn't it the best way
to do it? What better alternative to implement a preview feature in
glade?
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom-2]

2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:
> Hi,
> I've been implementing a preview feature for glade but I would like
> suggestions on the best way to do it.

Cool :)

We probably want a api on the GladeProject that will allow us
to preview a said widget in the project, like you say I agree its
best to give the user the choice, projects may have more than
one toplevel, or may not contain any toplevels at all (in which
case we need to parent them somewhere).

What I would really like, is something spawned with g_spawn_async_with_pipes,
and capture the errors through the pipe so we can report them back
in the Glade process (would be also nice if glade had a fancy logging
system to save and display logs by domain/project/widget etc but thats
another story, for now it would be nice if Glade could at least capture
error messages that may have prevented the preview from showing
and at least showing a window from Glade about those errors would
be enough).

I'm really really busy these days but I'll try my best to answer
all your questions and guide you through the source as much
as I can...

>
> As of now, the implementation is pretty hackish: it saves a
> /tmp/out.glade file, loads it with gtkbuilder, get the window1 object
> and shows it.
>
> Of course, doing it this way will not work for projects that do not
> have a widget named window1. And it is clear that this is not the best
> strategy, so I have several questions on how to do it right.
>
> I will investigate trough glade save functions to find a way to get
> the string of the saved file so that it won't be needed to save the
> file. But, how can I get the name of a toplevel object in glade?
> Should we ask the user witch object to preview? Isn't it the best way
> to do it? What better alternative to implement a preview feature in
> glade?
> _______________________________________________
> Glade-devel maillist  -  Glade-devel@...
> http://lists.ximian.com/mailman/listinfo/glade-devel
>

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

[Tristan Van Berkom-2]

2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:
> 2009/3/24 Tristan Van Berkom <tristan.van.berkom@...>:
>> I'm really really busy these days but I'll try my best to answer
>> all your questions and guide you through the source as much
>> as I can...
>
> Ok! So, my first question is: is my ideia of getting the string of the
> generated glade file and passing it to gtk_builder acceptable?
>

Yes, I want to feed the actual string to builder because its a
better test case, in its own process so that Glade is safe from
any side effects :)

For this you'll need to take a look at how glade_project_save
works, see if you can get it to do the same thing without
actually saving or resetting the projects "unmodified" state.

Cheers,
        -Tristan
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Marco Diego Aurélio Mesquita]

2009/3/24 Tristan Van Berkom <tristan.van.berkom@...>:

> 2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:
>> 2009/3/24 Tristan Van Berkom <tristan.van.berkom@...>:
>>> I'm really really busy these days but I'll try my best to answer
>>> all your questions and guide you through the source as much
>>> as I can...
>>
>> Ok! So, my first question is: is my ideia of getting the string of the
>> generated glade file and passing it to gtk_builder acceptable?
>>
>
> Yes, I want to feed the actual string to builder because its a
> better test case, in its own process so that Glade is safe from
> any side effects :)
>
> For this you'll need to take a look at how glade_project_save
> works, see if you can get it to do the same thing without
> actually saving or resetting the projects "unmodified" state.

Done, now I'm passing the string with the xml definition for
gtk_builder. What's next?
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom-2]

2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:
[...]
> Done, now I'm passing the string with the xml definition for
> gtk_builder. What's next?
>

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),
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.

Note you should check here the project format, just silently
return from here if your in libglade format...
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Marco Diego Aurélio Mesquita]

Let's go slowly...

2009/3/24 Tristan Van Berkom <tristan.van.berkom@...>:
> [...]
>
> 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?

> 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.

> Note you should check here the project format, just silently
> return from here if your in libglade format...

Will be done.

Some doubts remain:
Where and how should I send my patch?
What to do with projects that do not have a toplevel widget?
What to do with projects that have many toplevel widgets?
(It doesn't even work if the project doesn't have a widget called "window1")
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom-2]

2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:
> 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@...>:
>> [...]
>>
>> 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...
_______________________________________________
Glade-devel maillist  -  Glade-devel@...
http://lists.ximian.com/mailman/listinfo/glade-devel

[Michał Karnicki]

Just wanted to tell you guys how happy I am that I subscribed. By reading what you write here others (including myself!) can really benefit and see how things work and how they're done. I'll enjoy following your discussions. This preview function sounds very neat :)

Cheers!
Mike

2009/3/25 Tristan Van Berkom <tristan.van.berkom@...>

2009/3/24 Marco Diego Aurélio Mesquita <marcodiegomesquita@...>:

> 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
[....]

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