Re: [pygtk] pygtk for gtk+-2.0 snapshot

2000-10-31 Thread Hassan Aurag

 Ok This is off-topic, but any timeline about next major gtk/gnome/pygtk/pygnome 
release?

 
 In case anyone is interested, I have put up a snapshot of pygtk for the
 HEAD branch of CVS gtk+,glib and pango.  You can get it at:
   http://www.gnome.org/~james/pygtk2-SNAP-20001030.tar.gz
 
 You will need a fairly recent version of gtk+ and glib from CVS, as it
 uses the GSignal code that Tim Janik checked in a week ago.  I don't think
 it will be too difficult to add support for creating new GObject
 subclasses from python, and adding new signals to GObjects.  As the
 GObject code is split off into a separate module (gobject), you may find
 it useful as a general purpose notification framework for non GUI apps.
 
 You will probably run into dynamic linker problems at first.  It is
 necessary to relink the pango modules and gdk-imlib modules so that they
 link against the libraries they use.  Alternatively, you can modify your
 python sources so that extension modules are loaded with the RTLD_GLOBAL
 flag.
 
 You can almost test out the new text widget with these bindings.  The
 problem is with signal handlers, as the GtkTextIter arguments are not
 identified as such, so you only get opaque cobjects instead.
 
 You will need python 2.0 (or maybe 1.6) as some of the unicode
 features.  When importing the gtk module, it will set the default encoding
 to UTF8, so you can pass unicode strings to most parts of gtk, and they
 will convert to UTF8 and display correctly.
 
 Thread support is disabled at present because I haven't worked out how to
 get things working with the GObject system.  With pygtk-0.6.x, we used
 some hacks that relied on the global GDK lock to synchronise access to the
 python lock.  If there are any threading gurus on the list, I could use
 some help working out how to get things working without the benefit of
 this lock.  I can post some notes on the requirements to get things
 working if that would be helpful.
 
 James.
 
 
 ___
 pygtk mailing list   [EMAIL PROTECTED]
 http://www.daa.com.au/mailman/listinfo/pygtk
 



-- 
--
--
Hassan Aurag
--
CAE Electronics Ltd |   Universite de Montreal
System update specialist|   Centre de Recherches Mathematiques
++
Maximum Linux Magazine  |   Universite de Montreal
Contributing Editor |   Departement de Maths/Stat
++
EMAIL:  [EMAIL PROTECTED], [EMAIL PROTECTED], 
--
--

History is the version of past events that people have decided to agree on.
-- Napoleon Bonaparte, "Maxims"
--


___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



[pygtk] pygtk for gtk+-2.0 snapshot

2000-10-30 Thread James Henstridge

In case anyone is interested, I have put up a snapshot of pygtk for the
HEAD branch of CVS gtk+,glib and pango.  You can get it at:
  http://www.gnome.org/~james/pygtk2-SNAP-20001030.tar.gz

You will need a fairly recent version of gtk+ and glib from CVS, as it
uses the GSignal code that Tim Janik checked in a week ago.  I don't think
it will be too difficult to add support for creating new GObject
subclasses from python, and adding new signals to GObjects.  As the
GObject code is split off into a separate module (gobject), you may find
it useful as a general purpose notification framework for non GUI apps.

You will probably run into dynamic linker problems at first.  It is
necessary to relink the pango modules and gdk-imlib modules so that they
link against the libraries they use.  Alternatively, you can modify your
python sources so that extension modules are loaded with the RTLD_GLOBAL
flag.

You can almost test out the new text widget with these bindings.  The
problem is with signal handlers, as the GtkTextIter arguments are not
identified as such, so you only get opaque cobjects instead.

You will need python 2.0 (or maybe 1.6) as some of the unicode
features.  When importing the gtk module, it will set the default encoding
to UTF8, so you can pass unicode strings to most parts of gtk, and they
will convert to UTF8 and display correctly.

Thread support is disabled at present because I haven't worked out how to
get things working with the GObject system.  With pygtk-0.6.x, we used
some hacks that relied on the global GDK lock to synchronise access to the
python lock.  If there are any threading gurus on the list, I could use
some help working out how to get things working without the benefit of
this lock.  I can post some notes on the requirements to get things
working if that would be helpful.

James.


___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



Re: [pygtk] pygtk for gtk+-2.0 snapshot

2000-10-30 Thread Yasushi Shoji

Hi James,

Great work!

At Tue, 31 Oct 2000 09:59:33 +0800 (WST),
James Henstridge [EMAIL PROTECTED] wrote:
 
 You will need a fairly recent version of gtk+ and glib from CVS, as it
 uses the GSignal code that Tim Janik checked in a week ago.  I don't think
 it will be too difficult to add support for creating new GObject
 subclasses from python, and adding new signals to GObjects.

does it mean we'd be able to create a subclass from, say, GtkLabel and
add new signal to it?

tia,
--
  yashi

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk