[Glade-users] Glade, DevHelp and PyGTK



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]