Re: [libcroco-list] selection engine

[Dodji Seketeli <dodji seketeli org>]

Hey MenTaLguy,

>  Out of curiousity, how did you handle that in mlview?

In MlView, I have MlViewXMLDocument. It's a thin gobject derived class
that basically emits gobject signals whenever an editing action is
performed on an xmlNode *.

Basically, the api of MlViewXMLDocument look like:
MlViewXMLDocument::cut_node (xmlNode *anXMLNode, gboolean emitASignal) ;
Where anXMLNode is the node to cut.

You can look at the api at
http://www.freespiders.org/projects/gmlview/docs/apis/0.6.1/html/mlview-xml-document_8c.html .

Applications can connect to MlViewXMLDocument to get notified whenever
an editing action occurs.
The advantage of such a scheme is that I don't provide any wrapper for
the xmlNode. I can then take benefit of the libxml2 api at "low cost".

MlViewXMLDocument is more a container of xmlDoc than a wrapper.

I am a bit reluctant about writting a real wrapper because of the cost
of maintaining this.

On the other hand, I think it would be nice to be able to work on a real
w3c DOM. In the future, the work we are doing on libcroco and sewfox
could need some javascript + dom interaction. At that time, I think we
will feel the need for a kind of "universal" dom api/library on top  of
libxml2 and that fits well in the GNOME framework.

We have gdom for that. But the problem of gdome is that it's not gobject
based and that can be annoying from a GNOME app perspective.

What would be cool IMHO would be to provide a thin gobject container, in
the spirit of MlViewXMLDocument on top of libgdome.
Today, libgdome can build a DOM from libxml2's xmlDoc and let you access
the underlying libxml2's xmlDoc from a w3c DOM. I think they have done a
really good job there and it would a shame not to to try to leverage on
their work.


Regards,

Dodji.