Re: Need Some idea

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
> components

Thanks!

> 
> > 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++
> binding)

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
loudly :-)

> 
> > 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?
> 
> yes
> 
> >   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. 
Ouch.

[snip]

-- 
David Malcolm
www.conglomerate.org