Re: Need Some idea
- From: Dave Malcolm <david davemalcolm demon co uk>
- To: Luca Padovani <lpadovan cs unibo it>
- Cc: bonobo <gnome-components-list gnome org>
- Subject: Re: Need Some idea
- Date: 17 Jul 2003 22:02:39 +0000
On Thu, 2003-07-17 at 18:18, Luca Padovani wrote:
> Hi Dave,
> On Thu, 2003-07-17 at 20:04, Dave Malcolm wrote:
> > I want to embed MathML inside Conglomerate (www.conglomerate.org).
> nice job! looks like the typical application that would benefit from
> > My XML tree is a tree of libxml2 nodes stored in-process in the main
> > app. It is wrapped by a GObject which emits signals when changes occur.
> gtkmathview also uses libxml2, but it is hidden at the lowest level. On
> top of libxml2 there's gdome2 providing "standard" DOM interfaces, and
> on top of gdome2 there's a C++ binding that allows the programmer to
> forget about all those nasty things like reference counting, extra
> params for exceptions, ... I also use a notification mechanism for
> changes in the source document tree, but it is based on standard DOM
> events and DOM listeners provided by gdome2 (and, in turn, by the C++
Alas, my notification mechanism is non-standard; just a bunch of useful
events that seemed to make sense when I invented them. If there was a
bonoboified DOM implementation I'd consider porting to it, though it
feels like a lot of hard work for an uncertain reward.
> > So there are two issues I have with a component-based approach:
> > (i) Embedding as a control vs as a "canvas item"
> > Although I don't support it yet, I can probably allow GtkWidgets to be
> > used directly in my custom canvas. So I can extend this to allow Bonobo
> > controls fairly easily. But it will look nicer if there's some kind of
> > interface that assumes some kind of arbitrary canvas.
> you're right. AFAIK embedding a widget implies the component will always
> render in a rectangular area of the container app, which need not be the
> case in general. Also, you'd want to align the piece of math with the
> surrounding text, which means you need to have some knowledge about
> ascent/descent and not just the "height" of the rendered math. For these
> and other reasons I agree that, no matter whether embedding is done via
> a control or via direct linking against gtkmathview's library, the
> interface needs to be customized a bit.
Yes, though I'm in the middle of a big rewrite of my widget and so I'm
not sure yet what the interface is going to look like. (probably
something to do with pouring objects into flow areas, a bit like XSL-FO)
> > (ii) The DOM tree
> > We need some way for the DOM representation to "cross the process
> > boundary", so that it can be traversed by a component, changed, and
> > change notifications can occur. This is a hard problem.
> I posted about this problem on the list just a few days ago
> > A simpler approach might be to simply build a plugin for my app that
> > links with your MathML code and hence brings everything into the same
> > process.
> quick and easy (but does not involve components...)
Hopefully the inhabitants of gnome-components-list will not complain too
> > IIRC, gtkmathview is based on GTK 1.* Am I correct?
> no, we're working on an unreleased version of gtkmathview which has been
> ported to GTK2. As the porting still uses some deprecated APIs we're not
> willing to release it right away, but we're close
> > (i) Am I right in thinking that by implementing the PersistFile
> > interface you can load/save the XML source of the MathML from/to a
> > file?
> > You might be able to fake things by implementing PersistStream so
> > that you can load/save XML source to a stream.
> this is on our schedule
Excellent; if it's simply a case of creating libxml2 reader/writer
classes that talk to a Bonobo::Stream, then that adaptor code is
probably of use to other people as well (at some point I'm going to want
to turn Conglomerate itself into an embeddable control...)
> > just work. It would be an evil, error-prone hack, though.
> The issue of communication between components and container is crucial.
> I have the impression that in the bonobo world people tend to think of
> compund documents this way: a document is made of different fragments,
> each component is responsible for its own fragment and fragments are not
> connected to each other. Still, each component is able to serialize its
> own fragment so that a blob-document can be saved and restored later.
> This works well as long as the integration among components is loose and
> chunky. When integration becomes more involved, the document model
> should become central, and components would only provide views on
> fragments of it. Hence, either you make sure the components can access
> the document in their own address space (this seems to be the case when
> bonobo components are loaded as shared libs), or you make the document
> itself accessible via bonobo/corba interfaces. In my post on 12 Jul 2003
> these are the points b) and a) respectively. I haven't found
> satisfactory alternatives to these extreme possibilities. Gustavo J. A.
> M. Carneiro has suggested another way based on opaque identifiers, but
> then the container app can do very little with such opaque things...
Ideally I want to support editing of entity definitions within
Conglomerate. I can imagine nasty use-cases where a component is
editing an XML subtree that contains a reference to an entity, where the
definition of that entity is being edited in a different component.
] [Thread Prev