Re: bonobo, gtk widgets, DOM
"Gustavo J. A. M. Carneiro" <[email protected]> 15 Jul 2003 13:34:14 +0100
| Newsgroups | gmane.comp.gnome.components |
|---|---|
| Organization | INESC Porto |
| Message-ID | <[email protected]> |
A Seg, 2003-07-14 às 21:23, Luca Padovani escreveu: > On Mon, 2003-07-14 at 15:06, Gustavo J. A. M. Carneiro wrote: > > > Definitely alternative c) is the best. Maybe XPath identifiers are > > appropriate for this purpose?... > > this is interesting, the problem is that not all the communication is > from the user to the widget. Had it been this way, it would only be the > user to provide Xpath expressions, and our DOM implementation already > supports xpath interpretation. But when the widget has to notify the > user with a particular node, it would have to generate an xpath > expression for that node, and I don't see a sensible way to do this in > general. > > > Alternative a) also has some potencial, but you should create DOM node > > CORBA wrapper objects only on-demand. Don't create a BonoboObject for > > each DOM node in a tree! > > oh that's for sure. BTW, the bonobo wrapper for DOM might be generated > automatically almost completely, but it looks like an overkill solution > anyway. > > Is it possible that nobody else had this problem before? In fact, I did have a similar problem. In NumExp, a math program, a math expression is represented internally a tree of "elements". The bonobo server communicates elements with the outer world with integer identifiers. In the beginning, to obtain an identifier for the address of an element I would cast the address of the element to a long int. Currently, a different implementation is used, where a random number is generated to represent each element. See [1] for the implementation of this, though I'm not 100% sure this is bug free. Anyway, if you find it useful, use it in whatever license you want. Regards, and good luck. PS: Several times I found GtkMathView potentially interesting, but I never could compile it. Too many dependencies, dependencies on unstable an difficult to build dom library (which brings more dependencies), etc. I become some frustrated that I started my own (python) mathml project[2]. Still, I feel a bit bad about all this duplication of code. [1] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/numexp/numexp-core/bindings/bonobo/nxp-ticket-source.c?rev=1.2&content-type=text/vnd.viewcvs-markup [2] http://pymathml.sf.net -- Gustavo João Alves Marques Carneiro <[email protected]> <[email protected]>