Re: Need Some idea

Hi Dave,

On Thu, 2003-07-17 at 20:04, Dave Malcolm wrote:
> I want to embed MathML inside Conglomerate (

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

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

> (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...)

> 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

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

> (ii) Does Bonobo allow me to embed widgets created using GTK1.* inside a
> container built using GTK2.* ?

as I said, gtkmathview has been ported to GTK2, so this should not be a
concern for us

-- luca

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]