July 2013 - WebODF - lists.nlnet.nl

Undo/redo actions
by Philip Peitsch 31 Jul '13

31 Jul '13

Hi everybody, I've been considering the following thought experiment for undo/redo: 1. Doc state = A 2. Op A is performed by Mandy, Doc state = B 3. Op B is performed by Fred, Doc state = C 4. Mandy hits undo on her local editor 5. Doc state = ?? What does Mandy expect to have happen? Does this undo Op A or Op B? Etherepad's timeline view is a global undo stack, i.e., you can undo changes from any person to revert the document back to a previous state. In contrast, when typing on a collaborative document, does the user expect undo to revert *their* most recent change, or the *document's* most recent change? This leads directly into the next question. Does undo either: a) revert the document to a previous state, resulting in a document in an identical state as before the operation was originally performed e.g., 1. Doc state = A 2. Op A is performed, Doc state = B 3. Op A is undone via magic, Doc state = A OR b) undo a previous action, resulting in a document that is *similar* but not identical to before the operation was performed 1. Doc state = A 2. Op A is performed, Doc state = B 3. Op A is undone via magic, Doc state = C What is the difference you ask? Undo for direct formatting, range removal, etc. is really tricky because in the current implementations data is irretreviably lost as part of execution. The interactions are also far more complex than most other operations. E.g., What should happen if Fred inserts new text into the middle of a block Mandy is removing? What should happen if Fred inserts new text into the middle of a block Mandy is formatting? To implement undo option A with these types of operations the ops must be re-written to do less, pushing the complexity out into what generates the op. E.g., OpRemoveText is only allowed to remove text nodes, and SessionController (or a helper) is responsible for coming up with the exact list of text nodes to be removed, and generating an OpRemoveText for each of these. If however Option B is acceptable (i.e., the document should be visually indistinguishable, but is allowed to be different at the DOM level) there is another potential solution. Assuming option B and local undo stack: * Each client will generate their own local undo stack as each local operation is executed. * This local undo stack is rebased on every external change using the standard OT behaviours, and is not shared. * At the point the user undoes their recent change, the undo operations are forwarded from their local client as if it was a normal change. Thoughts, criticisms, concerns or shouting are all welcome :) Philip

3 2

RFC: Making OpApplyStyle and OpUpdateParagraphStyle more consistent
by Friedrich W. H. Kossebau 27 Jul '13

27 Jul '13

Hi, OpApplyStyle and OpUpdateParagraphStyle are currently quite different: a) how they encode the style attributes to change b) OpApplyStyle does not really support unsetting of attributes c) OpApplyStyle and related code only does textstyle properties d) OpApplyStyle does not directly modify existing styles, but create any needed automatic styles to have the given styling e) OpApplyStyle has a too generic name Before I start to write anything for OT of OpApplyStyle things needs to be cleaned up a little, to reduce the complexity due to the different behaviour. For a) OpApplyStyle takes some "info" payload that are actually directly the ODF element names and properties+values that should be set to the direct formatting. The names of the property and attributes use the usual prefix to indicate the namespace. OpUpdateParagraphStyle instead has a "setProperties" payload that carries the properties+values to set, with an own id scheme that first needs to be mapped to the ODF values. Q: anyone would mind to rename that "info" property to "setProperties", for some more entropy in the name? Okay to remove the custom property names and mapping in OpUpdateParagraphStyle and use directly the ODF attribute names as well? In matters of b), OpUpdateParagraphStyle has a payload "removedProperties" which stores the names of all attributes that should be removed. That was done like that instead of listing the attribute with value >null<, >undefined< or "" in the "setProperties" to express that is should be removed, because >null< and >undefined< might not exist in other languages and "" could be an actual valid value. Q: does it make sense to add something similar like "removedProperties" to OpApplyStyle? I guess it does. For c) I wonder what the plans are for paragraph styling. There is no TODO or anything else mentioned. And I am only thinking of the op spec, not of the actual implementation how to execute this op. Q: Should the same op be used for direct paragraph styling? So should there be, like in OpUpdateParagraphStyle, another section "paragraphProperties", next to "textProperties"? The difference mentioned in d) seems wanted, as this op is rather a direct mapping of some UI action, like we have with OpRemoveText or OpSplitParagraph. So no question about that issue. WRT e), I propose the name "OpApplyDirectStyling" Q: Better name? Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

3 3

On architecture/layers of WebODF
by Friedrich W. H. Kossebau 23 Jul '13

23 Jul '13

Hi, ((disclaimer: most of the following was done before Jos took back project- lead, so he might have different opinions on some things :) )) so here some notes from the last months regarding parts of the architecture of WebODF: one is a chart showing the MVC-alike structure, to separate the (extended) ODF model things as mapped into the DOM from those which deal with proper display in the rendered html page and those which deal with turning any input into operations on the (extended) ODF model. The other are about plans how to reorganize the classes fo the (extended) ODF model. The attached image is a quick sketch showing the MVC related classes/architecture of WebODF as drafted in November (things have slightly changed since then, but in general still valid). Please ignore UML-mistakes ;) As said before, the idea is to separate display (so showing things to the user) related stuff from pure document model stuff. So the latter can be used independently in some future, e.g. with another XML/DOM-based system, like a node.js server. There was work started on this, working title "xmlodf", but then the stream of patches from Down-Under :) and OT-work stalled things. Which also means the (extended) ODF model classes should have no clue about the display related classes. Instead the latter should connect to signals and other means of the first ones to get any data (updates) they need. The planned structuring/layering of the WebODF module was already partially integrated in master, so the classes of WebODF could be grouped into ... ... model oriented classes/layers G1: loading/saving of pure odf doc G2: changing of pure odf doc G3: cursor extended odf doc G4: changing of cursor extended odf doc ... and display oriented classes/layers G5: displaying of pure odf doc G6: displaying of cursor extended odf doc where dependencies are a DAG and basically Gn+1 depends on Gn...G1, except that G5 only needs G2+G1 ("G" as in "Group"). These days G3 and G4 also includes the EditInfo, while G6 got the EditInfoHandle/EditInfoMarker. The current namespaces (core, gui, odf, ops, xmldom) are not really ideal IMHO. So the proposal from that work branch was like this for the (extended) ODF model classes: xmlodf.utils : (all utility classes) Base64, ByteArray, ByteArrayWriter, RawInflate, Zip, xmldom.LSSerializer, xmldom.LSSerializerFilter EventNotifier, LoopWatchDog xmldom.XPath PositionIterator, PositionFilter, Selection, Cursor, SelectionManager, SelectionMover (create own (sub-)submodule for them?) xmlodf.core : (the project core type classes) StyleInfo (detail of OdfContainer, Formatting) OdfContainer, Formatting OdtDocument, OdtCursor xmlodf.ops : (could possibly moved to xmlodf.core) Operation xmlodf.ops.redset : (our current operation set, "red" pointing to bloody beginners ;) ) OpInsertText, OpRemoveText, OpSplitParagraph, OpSetParagraphStyle, OpUpdateParagraphStyle, OpCloneParagraphStyle, OpDeleteParagraphStyle, OpInsertTable, OpAddCursor, OpRemoveCursor, OpMoveCursor Hopefully this sheeds some lights into things. I hope we soon have some break from the feature rush and can do some more documentation and (complete the) redesign, to make the architecture more obvious and also have everyone in the same boat. Possibly I should do a patch to properly order and group with comments at least all files in the manifest.js/CMakeLists.txt, to help remembering the layers. Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 1

Reverted commit 0c811f2404e306fb7ea84cb282d9e56b958d399d.
by Philip Peitsch 21 Jul '13

21 Jul '13

Hi guys, Just noticed this was reverted. Was hoping someone might be able to provide information as to why? The commit comment lacked any detail unfortunately :( Cheers, -- Philip Peitsch Mob: 0439 810 260

2 1

Different behaviour on delete and backspace for emptied spans?
by Friedrich W. H. Kossebau 03 Jul '13

03 Jul '13

Hi, when testing if there will be any regressions on always normalizing* the position and length in OpRemoveText I found that there is different behaviour if in the following structure the char is removed by a backspace or a delete: <text:p><text:span>A</text:span></text:p> Currently these are the results: ... on a backspace from behind the "A" <text:p><c:cursor/><text:span></text:span></text:p> (ignore the cursor position, different topic, handled in separate email) ... on a delete from before the "A" <text:p><c:cursor/></text:p> I would have expected to get the same results in both cases. Playing with LO I found that there the span is kept in both cases (tested by creating an empty document, inserting an "A", marking it and directly formatting it to bold, removing the A in either ways again and saving as .fodt and inspecting with a text editor, while also seeing that with the empty document the Bold is toggled and any inserted chars are ending up in the span, being formatted with Bold). * normalizing by doing this inside the execute method and restoring original values afterwards: if (length < 0) { position = position + length; length = -length; } What do you think? Should emptied spans be deleted in this case? Or should empty spans only be deleted once a deletion range crosses their border? Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

4 3