[Glade-users] Glade, DevHelp and PyGTK

[Fabio Rafael da Rosa]

I'll see what I can do :).
The introspection idea seems good. 
When do the next release cicle starts?


Em Ter, 2009-01-27 às 17:47 -0500, Tristan Van Berkom escreveu:
> On Tue, Jan 27, 2009 at 7:53 AM, Fabio Rafael da Rosa
> <fabiorafael.rosa at gmail.com> wrote:
> > Hi All,
> > I usually develop in pygtk , using glade for the interface.
> > I'm starting to teach python and GUI programming with pygtk, and use
> > devhelp a lot.
> > The problem is, the devhelp button on glade always drives us to the C
> > GTK API documentation.
> > Is there a way to configure glade to use pygtk reference instead of
> > plain C GTK documetation ?
> >
> > It would be nice if we can configure that on glade, no only for pygtk,
> > but gtkmm and other bindings too.
> >
> > I can even help implementing that if you just give a quickstart on how
> > can I change glade for doing that (if possible).
> 
> It can be complex, as I dont want to add exraneous information to the
> widget catalogs about where there various devhelp docs can be found -
> heres a little outline of how its implemented:
> 
> Glade looks at widget type names and introspected properties and
> signals (signal doc shortcuts are missing but need to be implemented
> in the signal editor) to form the correct search string for devhelp.
> 
> In Glade currently, the GladeEditorProperty (gladeui/glade-editor-property.c)
> sends a property contextual search string on the main GladeEditor, and
> the main app listens to the main GladeEditor and calls devhelp from there
> (in Glade that would be src/glade-window.c).
> 
> You can probably achieve something by playing with the "book" portion
> of the devhelp search command (remember though that books are contextual
> to catalogs, so it may be very difficult to know which docs are available for
> which catalog for which binding - right now we have a "book" attribute to
> the catalog which is used for the devhelp doc book).
> 
> BTW, In the next release cycle I would like to focus on bringing out
> introspected
> data from gir files into glade, such as auto-updated versioning information
> and hell, why not get the doc strings from properties and signals from there
> too ?
> 
> Anyway, look at it, if you think you can manage something usable that
> hopefully will fail in a friendly way when some plugin specific docs are not
> found, and can manage to do it from the frontend (i.e.
> glade3/src/glade-window.c)
> without giving the core any knowlage of bindings and their docs, then let me
> know and I'll give you a hand where needed...
> 
> Cheers,
>                  -Tristan