Re: [pygtk] 'About' strangeness.
On Mon, 2003-09-01 at 18:22, Colin Fox wrote:
On Mon, 2003-09-01 at 00:48, Malcolm Tredinnick wrote:
Set the 'name' and 'version' properties on the GnomeAbout widget before
the widget is shown. I can see the logic of not setting the version
number in Glade (it changes more often than you want to change your
.glade file), but the lack of name setting has always seemed a bit odd,
I agree.
Cool. So now I have:
aboutbox.set_property('name','Demo Program')
aboutbox.set_property('version','0.1')
and it works. I don't remember seeing any docs on this anywhere.
Would it be worth putting this into the FAQ?
By the way, the name you want shown in the about box is not necessarily
the name string you pass in to the gnome.init() method. It really wants
to be the same as whatever the 'human-readable-name' property of
GnomeProgram to (if you set that property), but that is getting pretty
subtle (not a lot of programs do that).
Ok - is there some documentation somewhere that states all of the
properties of the various Gnome components and their purposes?
Not really. The libgnome (C language) API documentation explains some of
this, but bits of it need updating, since I didn't understand some bits
when I wrote it (and other bits were written by other people going back
as far as GNOME 1.0 in places).
However, I just looked and it does not contain a list of properties that
can set on things like the GnomeProgram object. That needs looking into
at some point. The state of GNOME developer documentation always makes
me feel sad, but it's such an enormous job to fix everything and
baby-step fixes are the only way to work.
I cannot really recommend the way I learnt this as the best method: I
wrote a lot of the libgnome API documentation, so at one point a couple
of years ago (just pre-GNOME 2.0) I had read pretty much every line of
code in libgnome and libgnomeui. It was not particularly fun. :-(
Cheers,
Malcolm
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] 'About' strangeness.
On Tue, 2003-09-02 at 04:59, Colin Fox wrote: [...] Hmm. I put this in: def on_aboutbox_response( dialog, arg1, *args ): if arg1 0: dialog.hide() dialog.emit_stop_by_name( 'response' ) This causes it to work properly if the user clicks the Ok button, but it's a hack. Why should you have to force a signal to be stopped just because you're using an about box? I don't think the old versions of the library required such contortions... Regardless, if the user clicks the close box, it will still crash when you try to re-invoke it. I'm catching the close signal, and it NEVER gets sent. That seems to be a bug, too. Same with the delete event. The ONLY event sent by the about box is 'response'. OK, pretend I am waving my hand in a Jedi-like fashion and saying There is no problem here. Convinced? I'm not kidding ... everything is working normally. If you are still reading this, my powers are weaker than I thought, so here is an explanation of what is going on... A GtkDialog box has two main signals it implements: 'close' and 'response'. It also inherits the 'delete-event' signal from the GtkWidget class which also has a role to play here. The 'response' signal is emitted pretty much whenever any action happens that causes the dialog box to finish running. The response signal emission will contain a response ID which can be user-defined or any one of the gtk.RESPONSE_* constants in pyGTK. The standard values correspond to things like one of the standard buttons being pushed or the window being destroyed. You can act differently based on the response ID. The 'delete' signal is emitted whenever the corresponding GtkWidget is deleted in a strange (for want of a better word) way. The main case here is when the user closes the window via the window manager (Alt-F4, or clicking on the 'X' button in a typical window manager, for example). In that case, you also get a 'response' signal, so generally you just ignore the 'delete' signal (return gtk.TRUE as has been mentioned elsewhere). For your standard GtkDialog widget, the only way the 'close' signal is emitted is when the Escape key is pressed. Widgets deriving from GtkDialog may have other buttons that are hooked up to emit 'close', but by default it is only bound to the Escape key (try it and see for the About dialog -- you can close it with Escape and it emits the predicted signal). So, in short, for something like the About dialog box: connect to 'response', hide the dialog box and then call the emit_stop_by_name() method. Connect to 'delete' and ignore it by returning gtk.TRUE. Ignore 'close' -- it is not useful in this case. Does this clarify things? If not, please sing out, because my psychic abilities tell me that Christian may end up using his cut-and-paste buttons to drop portions into the FAQ (possibly as an extension to 10.6), so it would be good if it was vaguely understandable. Cheers, Malcolm ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] 'About' strangeness.
On Mon, 2003-09-01 at 20:09, Malcolm Tredinnick wrote: This causes it to work properly if the user clicks the Ok button, but it's a hack. Why should you have to force a signal to be stopped just because you're using an about box? I don't think the old versions of the library required such contortions... Regardless, if the user clicks the close box, it will still crash when you try to re-invoke it. I'm catching the close signal, and it NEVER gets sent. That seems to be a bug, too. Same with the delete event. The ONLY event sent by the about box is 'response'. OK, pretend I am waving my hand in a Jedi-like fashion and saying There is no problem here. Convinced? I'm not kidding ... everything is working normally. Cool! Being a gnome developer gives you Jedi powers! If you are still reading this, my powers are weaker than I thought, so here is an explanation of what is going on... Your explanation is quite clear. Thank you! For your standard GtkDialog widget, the only way the 'close' signal is emitted is when the Escape key is pressed. Widgets deriving from GtkDialog may have other buttons that are hooked up to emit 'close', but by default it is only bound to the Escape key (try it and see for the About dialog -- you can close it with Escape and it emits the predicted signal). So, in short, for something like the About dialog box: connect to 'response', hide the dialog box and then call the emit_stop_by_name() method. Connect to 'delete' and ignore it by returning gtk.TRUE. Ignore 'close' -- it is not useful in this case. Except, as you've pointed out, that it's used for the Escape key handling. If you catch 'close', the escape key works. Otherwise it's ignored. I like making it go away with an escape key, so I'll keep the close handler. Does this clarify things? If not, please sing out, because my psychic abilities tell me that Christian may end up using his cut-and-paste buttons to drop portions into the FAQ (possibly as an extension to 10.6), so it would be good if it was vaguely understandable. Amazing - Jedi powers psychic abilities. Who said programmers were boring? :) Just to sum it up - this is what I needed in my program to make the about box work completely (these handlers are part of a class): def on_aboutbox_response( self, dialog, arg1, *args ): # system-defined GtkDialog responses are always negative, # in which case we want to hide it print aboutbox_response if arg1 0: dialog.hide() dialog.emit_stop_by_name( 'response' ) def on_aboutbox_close(self, widget, event=None): self.aboutbox.hide() return gtk.TRUE def on_aboutbox_delete_event(self, widget, event=None): self.aboutbox.hide() return gtk.TRUE Naturally, the 'close' and 'delete_event' signals could point at the same handler. It's just useful to have them separate for debugging. I still think the response handler having to do an emit_stop_by_name() is weird. Why can't I just hide it, like the other handlers? Regards, cf -- Colin Fox [EMAIL PROTECTED] CF Consulting Inc. signature.asc Description: This is a digitally signed message part ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] 'About' strangeness.
On Tue, 2003-09-02 at 13:58, Colin Fox wrote: On Mon, 2003-09-01 at 20:09, Malcolm Tredinnick wrote: [...] For your standard GtkDialog widget, the only way the 'close' signal is emitted is when the Escape key is pressed. Widgets deriving from GtkDialog may have other buttons that are hooked up to emit 'close', but by default it is only bound to the Escape key (try it and see for the About dialog -- you can close it with Escape and it emits the predicted signal). So, in short, for something like the About dialog box: connect to 'response', hide the dialog box and then call the emit_stop_by_name() method. Connect to 'delete' and ignore it by returning gtk.TRUE. Ignore 'close' -- it is not useful in this case. Except, as you've pointed out, that it's used for the Escape key handling. If you catch 'close', the escape key works. Otherwise it's ignored. I like making it go away with an escape key, so I'll keep the close handler. Fair enough. The Escape key binding seems pretty non-intuitive to me for the About box (it's just a mysterious accelerator with no mouse equivalent), so I tend to ignore it. But your view has validity too. Does this clarify things? If not, please sing out, because my psychic abilities tell me that Christian may end up using his cut-and-paste buttons to drop portions into the FAQ (possibly as an extension to 10.6), so it would be good if it was vaguely understandable. Amazing - Jedi powers psychic abilities. Who said programmers were boring? :) Just to sum it up - this is what I needed in my program to make the about box work completely (these handlers are part of a class): def on_aboutbox_response( self, dialog, arg1, *args ): # system-defined GtkDialog responses are always negative, # in which case we want to hide it print aboutbox_response if arg1 0: dialog.hide() dialog.emit_stop_by_name( 'response' ) def on_aboutbox_close(self, widget, event=None): self.aboutbox.hide() return gtk.TRUE def on_aboutbox_delete_event(self, widget, event=None): self.aboutbox.hide() return gtk.TRUE The self.aboutbox.hide() call is not strictly required in the delete-event handler. This is because if a GtkDialog receives a delete-event signal, it will emit a response signal (this is documented in the C language GTK API documentation and backed up by the C source code). So just preventing the further propogation of the delete-event signal should be sufficient (you can't ignore it or your widget gets destroyed which is what started us down this thread). Of course, leaving it in does no harm either, since calling hide() on an already hidden widget is fine. Naturally, the 'close' and 'delete_event' signals could point at the same handler. It's just useful to have them separate for debugging. I still think the response handler having to do an emit_stop_by_name() is weird. Why can't I just hide it, like the other handlers? Because life sucks. :) Seriously, I do not know -- but all my own various attempts to do this other ways have failed (as well as other peoples' on this list), so I'm now walking the party line on this one. Cheers, Malcolm ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] 'About' strangeness.
On Tue, Sep 02, 2003 at 02:16:15PM +1000, Malcolm Tredinnick wrote: Except, as you've pointed out, that it's used for the Escape key handling. If you catch 'close', the escape key works. Otherwise it's ignored. I like making it go away with an escape key, so I'll keep the close handler. Fair enough. The Escape key binding seems pretty non-intuitive to me for the About box (it's just a mysterious accelerator with no mouse equivalent), so I tend to ignore it. But your view has validity too. In modal dialogs, Escape is conventioned as the get the hell out of here key, so it's a good usability practice to have it close the dialog (or any other modal dialog, for that matter). Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: PyORBit 2.0.0
PyORBit 2.0.0, the Python binding for the ORBit2 CORBA ORB, is now available at: http://ftp.gnome.org/pub/GNOME/sources/pyorbit/2.0/ PyORBit provides both client and server side CORBA bindings, and aims to follow the standard Python language mapping for CORBA (http://www.omg.org/cgi-bin/doc?formal/02-09-07). PyORBit is capable of calling in process servers implemented using ORBit2, and being called by in process C code. This makes it ideal for use in the Gnome environment, and is used by the gnome-python Gnome bindings. PyORBit requires ORBit2 = 2.4.4 and Python = 2.2. Questions about PyORBit can be directed to the PyGTK list: http://www.daa.com.au/mailman/listinfo/pygtk Bug reports should be filed at the Gnome bug tracker: http://bugzilla.gnome.org/enter_bug.cgi?product=pyorbit James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] 'About' strangeness.
On Tue, Sep 02, 2003 at 01:09:09PM +1000, Malcolm Tredinnick wrote: Does this clarify things? If not, please sing out, because my psychic abilities tell me that Christian may end up using his cut-and-paste buttons to drop portions into the FAQ (possibly as an extension to 10.6), so it would be good if it was vaguely understandable. Heh. - FAQ 10.13 http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq10.013.htp I moved the cruft out from 10.6 into there, and from your explanation I'm assuming this will happen with any GtkDialog subclass. Correct me if I'm wrong. By the way, can't we get a stack trace to show why exactly we crash when emit_stop_by_name() isn't called in the response handler? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: Gnome-Python 2.0.0
Gnome-Python 2.0.0 is now available at: http://ftp.gnome.org/pub/GNOME/sources/gnome-python/2.0/ Gnome-Python provides bindings for the Gnome 2.x development platform libraries. It builds on top of PyGTK, and includes bindings for the following: * the GConf configuration database * the Bonobo component system * the Gnome-VFS file access library * support for writing panel applets and Nautilus views * the GtkHTML2 widget. * the Gnome-Print print libraries. Gnome-Python requires PyGTK, PyORBit, Python = 2.2 and the Gnome 2.x development platform to build. Questions about Gnome-Python can be directed to the PyGTK list: http://www.daa.com.au/mailman/listinfo/pygtk Bug reports should be filed at the Gnome bug tracker: http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-python James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANN: Guis-1.3 a GTK2 widget server (scriptable in Python Ruby)
The following message is a courtesy copy of an article that has been posted to comp.lang.ruby,comp.lang.python as well. Dear All, It is my pleasure to announce the release 1.3 of Guis, which is a programmable graphical user interface widget server. Guis communicate with a (one) client application thru textual communication channels; input requests (from application to guis) are Python (or Ruby) instructions (using the PyGTK binding of GTK2 to Python or the ruby-gnome2 binding of GTK2 to Ruby) and output replies (or events) are arbitrary textual lines from Guis to application (sent by Python or Ruby script). There is a possibility to trace the exchanges between application guis (in a graphical window) Guis is therefore a programmable (in Python or in Ruby) GTK2 widget server. The GTK related code of Guis can easily be ported to any embeddable scripting language offering a GTK2 binding. Guis is opensource, under GNU General Public License, developped under Linux. See http://www.starynkevitch.net/Basile/guisdoc.html for documentation on Guis, and also http://freshmeat.net/projects/guis and download source code (with demo) from http://www.starynkevitch.net/Basile/guis-1.3.tar.gz (a 482780 byte gzipped tar file of md5sum 70993058c397b04ff9b3030f0eda475c) There are actually 2 binaries: pyguis is Guis for Python2.2 and ruguis is Guis for Ruby1.8 Guis is developed under Linux and should run on most Posix systems with GTK2. Comments, suggestions and patches are welcome! Changes to this release: minor bugfixes, and (mostly) an experimental Ruby version. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basileatstarynkevitchdotnet aliases: basileattunesdotorg = bstarynkatnerimdotnet 8, rue de la Faïencerie, 92340 Bourg La Reine, France ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] CVS branches and plans for the future.
I have just branched pygtk, pyorbit and gnome-python in CVS. If you want to get the 2.0 branches, you will need to switch your branches over to the branches: cd pygtk; cvs update -r pygtk-2-0 . cd pyorbit; cvs update -r pyorbit-2-0 . cd gnome-python; cvs update -r gnome-python-2-0 . Development on the HEAD branch of pygtk will look at adding support for new GTK 2.2 APIs. It shouldn't take anywhere near as long to get the 2.2.0 release ready. If no one complains, I would also like to remove the GtkGLArea bindings from PyGTK. Since GtkGLExt seems to have an active maintainer and Python bindings, there doesn't seem to be too much need for it. If it is needed, the binding could easily be moved to GtkGLArea itself. For gnome-python, it probably makes sense to focus on Gnome 2.4 as it is very close to release, since it includes a number of improvements relevant to the Python bindings. Among other things, it probably makes sense to kill the gnome.zvt binding. I don't have many plans for pyorbit enhancements, other than removing cruft needed to support older ORBit2 versions. Any comments? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: PyGTK 2.0.0
Nice to see this release! One question: Does pygtk works in M$ Windows? If not, what should be done to get that? Thanks! ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: PyGTK 2.0.0
On Tue, Sep 02, 2003 at 08:17:40PM +0400, Alejandro David Weil wrote: One question: Does pygtk works in M$ Windows? See below: Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ In particular: http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq21.001.htp Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] [PATCH] Trivial patch for pygtk/configure.in
Hi. I've had this for a while in my configure.in file. The automake docs say somewhere or another that the first AM_ macro should be AM_INIT_AUTOMAKE. As autoconf offers AC_CONFIG_HEADERS to replace AM_CONFIG_HEADER, I made the following change. Perhaps this can go on the branch and head of pygtk? Art Haas Index: pygtk/configure.in === RCS file: /cvs/gnome/gnome-python/pygtk/configure.in,v retrieving revision 1.81 diff -u -u -r1.81 configure.in --- pygtk/configure.in 1 Sep 2003 12:47:39 - 1.81 +++ pygtk/configure.in 2 Sep 2003 18:37:19 - @@ -23,9 +23,9 @@ AC_DEFINE(PYGTK_MICRO_VERSION, pygtk_micro_version, [PyGtk macro version]) AC_CONFIG_SRCDIR([gtk/gtkmodule.c]) -AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE +AC_CONFIG_HEADERS([config.h]) AC_CHECK_FUNCS(bind_textdomain_codeset) dnl put the ACLOCAL flags in the makefile -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] [PATCH] Trivial patch for pygtk/configure.in
Hi. Looking at my patch again I don't know why I didn't do it like this earlier ... Index: configure.in === RCS file: /cvs/gnome/gnome-python/pygtk/configure.in,v retrieving revision 1.81 diff -u -u -r1.81 configure.in --- configure.in1 Sep 2003 12:47:39 - 1.81 +++ configure.in2 Sep 2003 23:17:48 - @@ -23,7 +23,7 @@ AC_DEFINE(PYGTK_MICRO_VERSION, pygtk_micro_version, [PyGtk macro version]) AC_CONFIG_SRCDIR([gtk/gtkmodule.c]) -AM_CONFIG_HEADER(config.h) +AC_CONFIG_HEADERS([config.h]) AM_INIT_AUTOMAKE AC_CHECK_FUNCS(bind_textdomain_codeset) -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] CVS branches and plans for the future.
On Wed, 2003-09-03 at 00:46, James Henstridge wrote: I have just branched pygtk, pyorbit and gnome-python in CVS. If you want to get the 2.0 branches, you will need to switch your branches over to the branches: cd pygtk; cvs update -r pygtk-2-0 . cd pyorbit; cvs update -r pyorbit-2-0 . cd gnome-python; cvs update -r gnome-python-2-0 . Firstly, sincere congratulations on making the 2.0.0 releases. It is wonderful to see all your hard work over the years pay off so far. :) Development on the HEAD branch of pygtk will look at adding support for new GTK 2.2 APIs. It shouldn't take anywhere near as long to get the 2.2.0 release ready. If no one complains, I would also like to remove the GtkGLArea bindings from PyGTK. Since GtkGLExt seems to have an active maintainer and Python bindings, there doesn't seem to be too much need for it. If it is needed, the binding could easily be moved to GtkGLArea itself. Agreed. For gnome-python, it probably makes sense to focus on Gnome 2.4 as it is very close to release, since it includes a number of improvements relevant to the Python bindings. Among other things, it probably makes sense to kill the gnome.zvt binding. Yes and yes. What do you think about moving the gtksourceview bindings into the main module (I'm not sure where exactly in the directory tree)? This is all said without having talked to the maintainer about his plans, but I like the idea of having a single-source download for this kind of stuff. Things like vte are different, since it includes the Python bindings in the main module. I don't have many plans for pyorbit enhancements, other than removing cruft needed to support older ORBit2 versions. Any comments? My only real request is to continue supporting Python 2.2. I was one of the people in favour of requiring 2.2 early on, so this risks sounding hypocritical, but the changes between 2.2 and 2.3 are not as large as from 2.1 to 2.2 and there will be a lot of installations with no plans to upgrade for some time. (OK, this is partly selfish: I've just got people at work beginning to use some apps in PyGTK and we have no upgrade plans in the near future for a large number of pragmatic reasons.) (In case that sounds wrong in email, I am not sure what your plans are -- this is just a pre-emptive $0.02 strike. :-) ) Cheers, Malcolm signature.asc Description: This is a digitally signed message part ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] CVS branches and plans for the future.
On Wed, Sep 03, 2003 at 11:50:41AM +1000, Malcolm Tredinnick wrote: Any comments? My only real request is to continue supporting Python 2.2. I was one of Seconded, for similar reasons as Malcolm's. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: Gnome-Python 2.0.0
On Tue, 2003-09-02 at 23:55, James Henstridge wrote: Gnome-Python 2.0.0 is now available at: http://ftp.gnome.org/pub/GNOME/sources/gnome-python/2.0/ Gnome-Python provides bindings for the Gnome 2.x development platform libraries. It builds on top of PyGTK, and includes bindings for the following: * the GConf configuration database * the Bonobo component system * the Gnome-VFS file access library * support for writing panel applets and Nautilus views * the GtkHTML2 widget. * the Gnome-Print print libraries. Just a thought for future release announcements: it may not be clear from this that it also wraps libgnome and libgnomeui (which adds some more widget types and helper functions). Cheers, Malcolm ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
