On Mon, 26 Jun 2000, Fred L. Drake, Jr. wrote:

> 
> James Henstridge writes:
>  > It provides a non GUI base for objects.  I have been wondering about
>  > whether to put the base gobject support into a separate module or not, and
>  > whether I should keep it separate from the gtk package (when you import
>  > gtk, it initialises the GUI).  Does this sound like a good idea?
> 
>   I like the idea.  The real question is how many libraries will be
> built with it that don't also require GTK+?  I have little idea about
> this, especially since I'm largely disconnected with the C-only
> world.

Well, this is one of those things where we won't know how many useful non
gui libraries will use the object model until after the glib/gtk 2.0
release.  I have decided to put the GObject wrapper stuff in a separate
module just in case.

> 
>  > I don't know how many non gui libraries will be using gobject, and how
>  > many of those will be useful to python programmers.  If we want to wrap
>  > those libraries and not require gtk be loaded, it will have to be compiled
>  > as a separate module.
> 
>   Overall, it's probably best to assume that at least some interesting
> libraries will be built, especially if "interesting" includes "we have
> to support X because Y is interesting and requires X objects".  I
> think the biggest problem we'll have to deal with is the addition of
> symbols from libraries required by extension modules to the global
> symbol table; I've not played with enough of the recent code to know
> if that's still a big problem.  I'll try and spend a little time on it
> in about three weeks (I'm waiting for a motherboard for my machine
> before I can do much on Unix ;( ).

For quite a while, I have been passing function pointers around as
CObjects in the modules (eg. gtk._gtk._PyGtk_API in the 0.7.0 release),
which means that the different wrapper modules don't need to see each
other's symbols.

As for symbols from libraries, I think from python 1.5.2, it doesn't use
the RTLD_GLOBAL flag when loading extensions, so the extensions don't
pollute the global symbol table.

What would be nice would be if ExtensionClass integrated better with
python (so that all the special cases for normal classes work for
ExtensionClasses).

> 
>   -Fred
> 

James.

-- 
Email: [EMAIL PROTECTED]
WWW:   http://www.daa.com.au/~james/



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

Reply via email to