MlView activity News

Hello folks,

I have been away from emails for a long time now, unfortunately.
A lot of activity happened in the GNU Arch repository of MlView though.

We have done a lot since the last 0.7.1 release that happened in
November last year.


Here is a summary of what happened in the mlview--main--0.8 branch (that =
will give birth to the coming 0.8 release) :

* a new "create document" dialog=20

* a new source oriented editing view.=20
  MlView is no more a tree oriented (only) editor. Okay, we need
  to add a lot of editing feature to this new source view so that
  people writing docs can use it efficiently.=20

* added some DBus stuffs so that application can be controlled remotely.
  this is an initial work to add a non regression tests framework.
  In the future, after compiling MlView, 'make tests" should run the
  editor, and launch series of tests to catch possible regressions.

*  A new firefox like search UI. This only works in the tree oriented
   editing view. The source editing view doesn't have any search feature =
yet.
   Any volunteer ?

* tons of bug fixes

All this changes are now committed into CVS HEAD.

In the mean time, we have been pondering switching the code base to C++.
Yeah, I know that will hurt some people. But I am tired of writing gobjec=
ts in
C, really. It's bug prone, long, and tedious. What makes the process tedi=
ous is
not the use of the C libraries. It more the need of concepts like
inheritance, polymorphism that makes the use of gobjects tedious in C.

Basically, we needed a language that=20

	*let us write object oriented code easily,=20
	 without re-writing the project.=20

	* let us leverage easily on
	 the existing C code base around in GNOME.=20

	* has a rather complete set of bindings in GNOME today.=20

	* enforces type safety at compile time,=20
	  to help catch more bugs.
=09
To me, the best language that matches these requirements *today* is C++.=20
Okay it has drawbacks. But which language doesn't ?=20
All in all this is a matter of trade off.

So we started to port the entire MlView code base to C++.
The first step of this process was the compile the project using g++, kee=
ping
the code unchanged, except for the parts that needed compilation errors f=
ixing do
to the stronger type strictness of C++.
This first step is completed now.

The next step is to re-factor the former C classes (that derive from gobj=
ect)
and make them be good c++ citizens. This implies starting from the upper =
level
classes and going downward. I'd like this work to be done progressively s=
o
that the code compiles and runs after the porting of each class. I think =
that
we should not enter a long "tunnel" where nothing works until all the cla=
sses
are ported. Moving forward through incremental changes is usually a good =
thing.=20

All this c++ related changes are taking place in the mlview--cpp--0.8
branch, in GNU Arch. I haven't committed anything to CVS yet,=20
and I don't think I will, unless some of you want it.

Furthermore, this work won't be merged back in the 0.8 line, but rather i=
n a
further code line. Maybe, maybe 0.10, I don't know for now.

Only bug fixes and changes that affect classes that haven't been
ported to C++ will be merged in the mlview--main--0.8 code line.

Oh, and I would like to thank Philippe Mecha=EF, Stephane Wirtel=20
and Benjamin Dauvergne for their invaluable help.

Best wishes,

Dodji