On Sat, 2006-11-25 at 03:49 +0100, John K Luebs wrote: > If it's only a prototype, then it is assumed that large portions of > the system may need to be rearchitected.
Note that I meant prototype in the "working model" sense, not in a "throwaway"/"proof of concept" sense. > Anyway, what you are asking for cannot be done with the traditional > hammering out of C and C++ code. The idea is to reuse GObject facilities where possible (e.g. types, inheritance, signals, GValues), and simply implement the appropriate vtable semantics overridable at runtime. I was wondering if anyone else has stumbled on this and already solved it. > Have you looked at how pygtk is built. Yes. The problem with PyGTK is that it adds new C code for each GTK class whose methods must be overridable from Python. That works well for GTK which is fairly static, but would be a hassle in a system with a number of evolving classes. _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
