MlView hacktivity

Hi list,

First, I forgot to wish a happy new year to you guys ;)
May this new year bring serenity and good health to you and
your relatives.

Now, back to xml editing stuffs.

I would like to share some thoughts I have concerning
the directions we are taking.

First, let's talk about a nice feature that I have called
the "multi-type-of-editing-view" feature.

What is the "multi-type-of-editing-view" feature ?
It's the ability for the editor to support several types
of editing views.

Why this feature ?
Basically, I think that there are several "XML editing uses case"' that
we need to address. Someone who edits a docbook document doesn't need
the same editing capabilities as someone who edits a glade file, or a
J2EE web.xml file. So the editing tool should be able to provide the
user with several editing views, each view adressing a specific set of
use cases.

Today mlview provides a powerful, reliable and working tree oriented
editing view. This tree oriented editing view is made of separate
documented editing widgets.
Now, it would be cool to add the ability for the editor to support
additional editing views made of a combination of some of the existing
editing widgets and new ones that would address new editing
use cases.

This feature obviously needs some changes in how we handle things today,
eventhough the major needed stuffs are already in the box.
In the short term, the "multi-type-of-view" feature requires that
an editing view "exposes" the editing actions it allows the user to
perform on the XML document. This means that the view must own and
build the contextual menu when requested, that it edit some part of the
application's menu etc ...
Today, the (broken) contextual menu we have is build statically and is
global to the application. Same thing for the menu and toolbar.
This must change.

I have created a branch named "mlview-app-refactoring" where I have
started to re-organize the code, so that we can have the minimum
infrastructure needed for the "multi-type-of-view" feature.
I have removed our dependency on the libgnomeui's GnomeApp and it's
static menu building scheme. MlView now relies on a glade build
interface for the topmost application container. The other specific
editing widgets remain unchanged. Our current single tree view is now
responsible to build the contextual menu. I have thus removed the old
global edition toolbar.
If a toolbar is really needed by an editing view in the future, that
toolbar will be owned by that specific view.

Of course, I try to make sure that the code stays in a testable state at
any time. It would be cool if some of you start testing the
mlview-app-refactoring branch and give feedback.
Those of you who don't feel like testing an early development branch can
still test the CVS HEAD version (the stable one) and give feedback.

To get the code from the CVS, here is what to do:

export CVSROOT=:pserver:[email protected]:/cvs/gnome
cvs login
(just type enter at the password prompt)

(to get the HEAD, stable code, type)
cvs -z3 co mlview

(to get the mlview-app-refactoring branch code, type)
cvs -z3 co -r mlview-app-refactoring mlview


Happy XML editing,

Dodji.