- WebODF - lists.nlnet.nl

class hierarchy graph and refactor
by Jos van den Oever 09 Feb '14

09 Feb '14

I've pushed code that will generate a relatively clean class hierarchy for the WebODF classes. The file is available as dependencies.dot after every build. Solid colors mean the file contains a class or a collection of utility functions. An white oval with a colored line indicates an interface. In reality, there are many more connections between classes, but not all are shown. Consider this small graph: A -> B B -> C A -> C The connection between A and C is already implied by A -> B -> C so the direct line A -> C is left out. This makes the graph less cluttered and cramped. But do not be disappointed when you want to sever a tie between classes and you find that another connection becomes visible when you do. As you can see the dependencies are pretty nice at the moment, but they could be improved. The ODF classes occur roughly in a block. The gui classes are a mostly on top. All ops classes are connected to each other. Here are some suggestions for improvements: - rename OdtCursor to ops/Cursor.js - split the ops directory in ops and odtops (an xmlops dir is on the way) Have fun! Jos

1 0

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

road to achieving 100% typing
by Jos van den Oever 02 Dec '13

02 Dec '13

Dear list readers, In WebODF we use JSLint and Closure Compiler to get good quality. We can improve the code quality in WebODF further by activating a new compile flag for Closure Compiler: --jscomp_error reportUnknownTypes This flag will abort the compilation if the type of a variable cannot be determined. If a type is unknown, the programmer can add it with a @type or @param annotation. There is no need to put these annotations everywhere. For many cases, the compiler can determine the type. Eventually, I would like all code to be compiled with this flag. That will not happen overnight (not at this latitude anyway). So we need a transition mechanism. Today, a patch landed in WebODF that gives us just that. The top level CMakeLists.txt files now divides the source .js files in three categories: a) 100% typed and depending only on 100% typed files b) not 100% typed but depending only on 100% typed files c) the rest. These categories are determined by a new tool: updateJS.js which scans the source code. All it needs to start its internal list of files that should be 100% typed. Eventually, all files should go into category a). The files in category b) are almost there. This is what needs to happen to get them there. 1) choose a file to make 100% typed 2) add the file to the list in webodf/tools/updateJS.js 3) run 'make manifest.json-target' or 'ninja manifest.json-target' to update the build files. 4) run 'make typecheck-target' or 'ninja typecheck-target' and fix all issues that come up (repeat until they are all fixed) 5) run 'make' or 'ninja' to check that the entire build is fine 6) push your work and submit a pull request. We have probably passed the 50% mark already so we will get there before the end of the year for sure. Cheers, Jos

1 0

FW: Open Document Editors Devroom at FOSDEM 2014, 1 February 2014, Brussels
by Friedrich W. H. Kossebau 26 Nov '13

26 Nov '13

Hi, Call for participation is out, talks about any open document editors or the ODF format welcome, deadline December 22, read in detail below. >From http://mail-archives.apache.org/mod_mbox/openoffice-dev/201311.mbox/<5294F751.4000903(a)apache.org> : --- 8< --- (feel free to forward to other lists and other projects; if you have questions, of course you can ask them on the OpenOffice dev list too) Open Document Editors Devroom at FOSDEM 2014, 1 February 2014, Brussels Open document editors are coming again to FOSDEM with a shared devroom which gives every project in this area a chance to present ODF related developments and innovations. The devroom is organized by Apache OpenOffice and LibreOffice. We invite submission of talks for the Open Document Editors devroom, to be held on Saturday, February 1st, from 10AM to 6PM. Length of talks should be limited to 20 minutes, as we would like to have questions after each presentation, and to fit as many presenters as possible in the schedule. Exceptions must be explicitly requested and justified. Technical talks (code, extensions, localization, QA, tools and significant adoption related cases) about open document editors or the ODF format are welcome. Submissions must be done using the Pentabarf system: https://penta.fosdem.org/submission/FOSDEM14 While filing your proposal, please add a few lines about yourself (although your profile might already be stored at Pentabarf) and specify what product or topic (Apache OpenOffice, LibreOffice, both, other editor, ODF in general...) your talk is about. The deadline is Sunday, December 22, 2013. Accepted speakers will be notified by January 5, 2014. You can send any questions to the devroom mailing list: office-devroom(a)lists.fosdem.org --- 8< --- Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 0

Re: [WebODF] getting started help
by Joshua Kramer 25 Nov '13

25 Nov '13

Hi, I'm replying to news75 and Michiel. I ran into the same problem as news75. Here's the problem: if I do, odfcanvas.load("questions.odt") then I get a "Not well formed" error when it tries to load. If I do odfcanvas.load("file:///home/josh/Documents/questions.odt") then I get a domain restriction error. These errors appear in the Javascript console of Firefox when I have it enabled. Chromium behaves in the same way. Any ideas? Thanks! -JK

2 2

Where can I get the code for the demo site?
by Joshua Kramer 23 Nov '13

23 Nov '13

Hello, Is the code that runs the demo site publicly available? http://www.webodf.org/demo/ci/webodf-0.4.2-1305-g54e8ab4/editor/localeditor… If so, where can I get it? Thanks, -JK

2 1

webviewers.org working to standardize interaction between viewers/editors like WebODF and webapps.
by Caleb James DeLisle 18 Nov '13

18 Nov '13

Hi, I noticed http://viewerjs.org/ which seems to be tied in with the WebODF project (correct me if I'm talking to the wrong people) and I wanted to share a similar project that I and others have been working on as part of the Resilience research project. Perhaps we can collaborate. WebViewers is similar to viewerjs.org except that we concentrated on standardizing the format of a WebViewer so that they can be interchangeably plugged into any supported web application and the application's WebViewers subsystem will automatically begin displaying edit/view buttons in the user interface depending on the viewers which are available. The WebViewers protocol should be well described on http://webviewers.org and if anyone has any questions or if anything is omitted, please do let me know. Also any opinions about what is desirable or might be missing are most welcome. Thanks, Caleb

2 1

getting started help
by news75＠libero.it 16 Nov '13

16 Nov '13

hello guys, I'm a new webodf user and I'm trying to starting from the getting started example on webodf home page but I have some problems... I have downloaded the webodf.js file at http://webodf. org/demo/demobrowser/webodf.js and I have done a html page how listed in the getting started example and I have done a very simple odt page. The problem is that when I load the page in my firefox 25.0 on fedora 19 I get a page that say: "loading myfile.odt" after that nothing heppen, no odt pages are loaded... any suggestions !? g.

2 1