[WebODF] ODF editing

[Jos van den Oever]

On 03/21/2013 12:52 AM, Philip Peitsch wrote:
> Is there a delivery road-map, or a backlog somewhere of the planned
> features? I'm in the middle of sorting out the various requirements I
> have for the editing behaviours and am basically trying to answer where
> to best start.

We are at a point on the roadmap where we deliver features, but have not 
written a follow up roadmap yet. Roughly our roadmap is to add all odf 
features eventually and by priority of customer wishes.

> The complete features I will need to support in the next few months are:
>
> * Paragraph add / delete
> * Page-break add / delete
> * Table add/delete (rows & columns as well)
> * Character range changes (i.e., modifying the character styles of a
> selected range of text)
> * Paragraph style changes (already covered by your work in some fashion)
> * Paragraph alignment changes (create a new style based on an existing,
> modify the alignment)
> * Bulleted & numbered list creation
> * Image insertion & removal
> * Cut/Copy/Paste (both WebODF => WebODF, external => WebODF, and WebODF
> => external)
> * Page view (as opposed to the "continuous" view currently supported.
> vandenoever mentioned he had some ideas on how to fix this)

Yes for pagination there is a solution which will work well for all 
pages without columns. For pages with columns either more complex 
javascript or good support for CSS Regions is required.

> Is the stuff you are doing for the collaborative editing
> straight-forward enough that I (and you) would benefit if I implement
> these editing operations using that framework, or is my life going to be
> much simpler to implement the DOM changing independently?

That is a very sensible question. And I can give you a counter question: 
will you need to support undo and redo?
If you do, then you need a way to serialize the operations that you 
perform on the dom and create a reverse operation. And that is also a 
requirement for collaborative editing. In collaborative editing there is 
the option to allow to swap the order operations, but that is not a 
requirement for the operations.

> Ideally, if you have a roadmap and timeline that aligns partially with
> what I'm going to need to build, I can choose tasks that won't tread on
> your toes or re-do work you are already scheduling and planning for. It
> would hopefully also mean there is the best chance that the code I write
> is useful to the WebODF project in general, rather than a standalone
> hack branch which I'd prefer to avoid if at all possible :). I'm open to
> any suggestions on how I might tackle this in a way that will make it
> possible for you to integrate the work back in if you think it might be
> useful. Is it possibly a good idea for me to start to plan some of this
> on a public wiki somewhere if you have specific design suggestions or
> feedback?

We work quite agilly and all operations have their own file.
  http://gitorious.org/webodf/webodf/trees/master/webodf/lib/ops

In fact, our operations do not currently have the reverse yet, but that 
will come. I think that organizing DOM operations is not a difficult 
overhead though and a nice way of modularizating the code.

> Please don't feel pressured about this either way. If your time is
> better spent doing things other than helping me design/plan/integrate
> this, I'll figure something out on my own. I'm just conscious there is a
> greater risk that the resulting code I produce won't be able to be
> easily contributed back if I just make it up on my own :)

I think it's a worthwhile 'investment' of time to help you. :-)
That's a large part of a community project. Of course there is an effort 
on both sides to coordinate this, but that is fine.

As to a roadmap for your features, I think that simply implementing the 
operations is the best thing you can do. In our current use case they 
will not bite when not used anyway so there is also little need to keep 
multiple branches that are hard to synchronize. Even if there are 
separate branches, since the operations are separate files, that should 
not be a big problem.

Cheers,
Jos