January 2014 - WebODF - lists.nlnet.nl

Evaluating colabeditor
by Rui Rosado 22 Jan '14

22 Jan '14

Hi all, I'm working on a project in which I think that the collaborative WebODF editor would be a nice tool. After downloading WebODF source from GitHub, I was able to edit documents using src-localeditor.html In the project we really need different people to work collaboratively on documents. So I thought I was being smart ;-) by opening the src-colabeditor.html page However, to proceed I need to enter login data. I would need that for at least 2 users. Is this information (username/password) available for at least 2 (preferably 3 or 4) users? And how can I get hold on that? Thank you. Regards, Rui

2 1

Undo & Operation groups
by Philip Peitsch 21 Jan '14

21 Jan '14

Greetings webodfers, I'm spending some time in the next 3 weeks improving the behaviour of undo slightly. I am specifically looking at fixing how undo states are created to group things more intuitively for the user. For a nice clear example of the existing problem, try the following steps: 1) Open the editor (http://www.webodf.org/demo) 2) Select 2 or 3 paragraphs 3) Indent these 1 step left 4) Now hit undo If you persist long enough, you can eventually unindent each paragraph. Every second undo appears to do nothing, as this is rolling back the AddStyle operation, which is not really user visible. You'll notice if you look at the Session.enqueue function that it takes an array. In most places, we're quite careful to group all operations from a single user operation into one group. In order to get the next level of improvement to undo, I really need to know what group an operation original executed in. This would allow me to ensure all operations from a single group appear in a single undo state (for example). I have two ideas for how to do this cleanly. Option 1) Add an argument to the signalOperationStart & signalOperationEnd that specify the group being started. The group id can simply be an incrementing number or similar. Pros - * Easy to implement * Group id only needs to be locally unique * Definitely not over-engineered :) * Very transient. Can't be accidentally leaked to other clients etc. * Maximum flexibility to how the server batches up operations e.g., the server can choose to group multiple text inputs in the same region into a single operation Cons - * Very transient! No way to regain the group after the signal has fired * No remote client will ever known how a batch of operations are divided up Option 2) Add a groupid (or transactionid) to each operation. Have the session assign a guid as the groupid so it is generally likely to be globally unique across all clients. Pros - * Clean extension of current system. Easy to implement * Allows remote clients to reconstruct sensible undo states similar to the local client (not that we support collab-undo yet) * Accessible to the local undo, or other consumers that might want to be aware of this (e.g., save points?) Cons - * Increases amount of data sent * No firm decisions as to how remote undo should work yet, so this may not have any bearing on the "right" solution * Server cannot group operations from multiple clients or groups (note, this doesn't stop LOCAL clients from performing clever optimizations however) There are other variations on the theme, but the thoughts are: * Are groups permanent or temporary? * Can groups be modified after being added to the session? (e.g., similar to how SQL transactions work) * How widely known is a group (local or remote)? * If groups are transmitted remotely, how do other clients know when they have received all operations in a single group? * Again, if remotely received, can remote clients interleave ops from multiple groups? I would like to open the email for discussion. Do people have any preference between option 1 or 2 (or another suggestion entirely)? Are there other opinions about how these groups should work? Is there obvious issues I've missed? I plan to start cutting code next week Tuesday AEST, so there are some time pressures for reply. Having said that... we can always tweak it later. Neither option is a lot of code so far :) Cheers, -- Philip Peitsch Mob: 0439 810 260

2 3

Step iterators introduction & design concepts
by Philip Peitsch 20 Jan '14

20 Jan '14

Hi everyone, I wanted to take a moment to introduce a new class I've recently added to webodf to assist with cursor movement. I will explain some of the reasoning behind it and provide examples of best practices. First step is defining some terms. Most of these are drawn from earlier discussions on this list[1]: Position: A DOM node + offset pair Step: A position returns FILTER_ACCEPT when passed to a specific filter A new class has been added to core called a StepIterator. It provides the following methods - * roundToClosestStep * roundToPreviousStep/roundToNextStep * previousStep/nextStep * isStep New instances of this (as of pr#315) are most easily accessed via OdtDocument.createStepIterator. The key aims of this class are: 1. Make it easier to avoid iteration bugs (e.g., not starting step counting from a step) 2. Provide a semantically clearer interface for movement-by-step and movement within restricted containers (e.g., roots/paragraphs) 3. Provide an interface to make further performance improvements to In practice, I'm intending step iterators to supplant the SelectionMover class for all uses. I'm also intending to phase out the recently introduced rounding constraints in the StepTranslator class, as I have found usage of this to be very hard to use properly and I tend to create bugs with it (oops :S). In my mind, the step iterators provide a few strong advantages over existing mechanisms: * Step iterators are not tied to the focus node of a cursor. They can operate on arbitrary points and positions (e.g., shadow cursor) * By allowing the developer to set the subtree over which step iteration will occur, iteration will complete far more quickly for queries that only want to check if there is another step available (e.g., move/extend cursor operations within an annotation) * Limiting the iteration subtree also reduces the chance a dev will unintentionally walk a large number of steps (which is still slow!) * Avoids confusion & performance problems with conversion directly between filters. Using DOM positions as input and output guides developers towards the right way to write performant code. * By binding the iterator and filter together more tightly, major performance improvements can be realised (such as combined node + position filters). Brief testing has shown a 2-3x performance improvement might be available through combining these. Now for some examples. Check if there is at least one more step in the paragraph: // Subtree is limited to the paragraph node. Guarantees the iterator // will not walk more than the maximum paragraph length under any // condition var stepItr = odtDocument.createstepItr( paragraphNode, paragraphNode.childNodes.length, [textPositionFilter, rootFilter], paragraphNode); // step iterator is initialized at // (paragraphNode, paragraphNode.childNodes.length) if (stepItr.nextStep()) { console.log("Has another step!"); } Find the last step within a paragraph: var stepItr = odtDocument.createstepItr( paragraphNode, paragraphNode.childNodes.length, [textPositionFilter, rootFilter], paragraphNode); // step iterator is initialized at // (paragraphNode, paragraphNode.childNodes.length) // Under some circumstances, this will be a valid step, // so just calling previousStep here might skip the last // step. Instead, roundToPrevious can be used to only move // to the previous step if the current position is unwalkable runtime.assert(stepItr.roundToPreviousStep(), "No previous step available"); // Convert to an absolute cursor step using step cache step = odtDocument.convertDomPointToCursorStep(stepItr.container(), stepItr.offset()); Find the last step just after a paragraph: var subtree = odtDocument.getRootElement(paragraphNode), stepItr = odtDocument.createstepItr( paragraphNode, paragraphNode.childNodes.length, [textPositionFilter, rootFilter], subtree); // step iterator is initialized at // (paragraphNode, paragraphNode.childNodes.length) // Move to the next cursor step runtime.assert(stepItr.nextStep(), "No next step available"); // Convert to an absolute cursor step using step cache step = odtDocument.convertDomPointToCursorStep(stepItr.container(), stepItr.offset()); Best practices: * Always make the subtree as small as possible. If you know you need a step within a particular container (E.g., paragraph, annotation), use this for the subtree. This provides very large performance when rounding to the closest step, or checking if there are more steps left within the subtree. * Some filters are very expensive. Use the filters you need, but try and avoid direct access to the filters themselves. Instead, use stepItr.isStep as this is cached to the last position used. * DON'T WALK LARGE NUMBERS OF STEPS. Step iteration is really meant to be fine-tuning of a rough position. Walking a full paragraph via step iteration can take upwards of 30-40ms per paragraph, which adds up very quickly. WebODF eventually needs to be able to perform hundreds of operations per second! As ever, I'm keen for any feedback or improvements (or requested examples) on this interface. Cheers, Philip [1] https://open.nlnet.nl/pipermail/webodf/2013-October/000082.html

1 0