Table of Contents
MlView is an xml editor designed to run on gnome based systems. Its main goal is to ease xml edition with and without validation. Besides that functional goal, MlView has been designed to have to following properties :
the generated code should remain relatively small
should be embeddable in any gnome application at least as a library
should be extensible by a pluggins system
Table of Contents
MlView is coded using an object oriented aproach. Although it is coded in C, it relies on the gtk+ and thus uses the gtk object typing system. It is made of classes and objects just like programs in object oriented languages like C++, or Java.
One could ask "So why haven't you used C++ or Java to code it then ?". Well, one of the goals of the MlView project was to keep the generated code relatively small and embeddable in any type of gnome application. It appears to me that so far, C is more likely to achieve that goal than C++. I don't even talk about Java. Don't get me wrong. I am totally dedicated to object oriented programming and to the object oriented languages like C++ or Java that i use every day in my food job. But in the particular case of mlview, I thought C was a better choice at least for the core of the software.
MlView is basically designed around several main classes :
MlViewXMLDocument
This class is a wrapper of the xml tree or xml document object model. It wraps the xml tree edition functions provided by the libxml2 apis. Each method of this class that perform an edition action (cut a node, add a child node etc..) on the underlying xml tree emits a gtk signal to say "hey, i've done something someone should care about !". That way, each object of MlView that needs to be notified upon a modification of the underlying xml tree just has to connect to the right signal.
MlViewXMLDocumentView
This class is the base class of the views of MlView. Basically, a view is the only visual interface through which one can manipulate an xml tree. So, to edit an xml tree one must first create a view that takes that xml tree in parameter. Then, that view will provide the user means to edit the xml tree passed in parameter. For example, a tree oriented view will present a visual abstraction of the underlying xml tree and allow the end user to perform edition actions (create a new node, cut an other etc..) on that visual tree.
MlViewXMLDocTreeView
This is a child class of MlViewXMLDocumentView. This view is what i call a tree view. It obviously presents the underlying xml tree as a visual tree. It also allows the user to perform edition actions (add a child node, cut a node, paste a node as previous sibling etc...) If a programmer wants to define a new type of view, let's say "an xml text view" he just has to create a new child class of MlViewXMLDocumentView that may be called MlViewXMLTextView and that's it.
MlViewEditor
From the programmer point of view, this class is the abstraction of the xml editor. It is basically a container of instances of MlViewXMLDocumentViews. Each instance of MlViewXMLDocumentView being itself related to an instance of MlViewXMLDocument. The job of the MlViewEditor class is to allow the end user to select the instance of MlViewXMLDocumentView the user wants to work on, and to let the user perform edition actions through that instance of MlViewXMLDocumentView.
MlViewAppContext
This class is the communication path between all the objects of MlView. When an object A wants an object B to access an information (for example some user settings) A puts the data in an instance of MlViewAppContext and passes that instance to B. MlViewAppContext is basically there to prevent the use of global variables in the code of MlView. As i said before, MlView can be embedded in an other application as a library or whatever. It therefore must be truly reentrant. That is why it is highly recommended to avoid as much as possible the use of global variable that can be seen of the scope of a given source file.
MlViewApp