- WebODF - lists.nlnet.nl

Proposal for solution of current memberdata needs
by Friedrich W. H. Kossebau 06 Nov '13

06 Nov '13

Hi, current situation: there are two operations (one existing, one hypothetical) which create/modify datastructures with the element <dc:creator>: * OpAddAnnotation * OpSetMetadata (would update e.g. <office:meta><dc:creator/></office:meta>) (Ignoring <office:meta><meta:initial-creator/></office:meta> here for now, creating new documents from templates is a separate problem, not thought in detail about that yet) Issue is that ideally the opspec has all data needed for execution and does not need to query for/lookup anything. Also ops currently cannot access the membermodel, as they only see the ops.OdtDocument object, but not the ops.Session one. OpAddAnnotation ATM breaks that concept, as it relies on the execution method (or rather AnnotationViewManager) to set the proper content for <dc;creator>. <dc:creator> would be passed by OpAddAnnotation by the same member, so just the member would need to know what data it should set in, usally the fullname of the member. In the possible case of the change of the fullname it would be a nice feature to have the <dc:creator> of (at least) all annotations created in the current session be updated. That would need a new method OpUpdateAnnotation, but that still would/could be initiated by the member whose fullname changed. Now with OwnCloud we have the case that any member which leaves the session has to do a save, and for that it would need to set the doc's metadata <office:meta><dc:creator/></office:meta> up-to-date about the person which did the last modification WRT the saved state, following the ODF spec §4.3.2.7 <dc:creator>, which defines that <dc:creator> "specifies the name of the person who last modified a document". Meaning, any member's client needs to be able to know the fullname of any other member in case. Ideally the server/host is the one single source for all data about members, so clients could not play evil to each other and pretend members to be someone else, by passing e.g. faked fullname and avatar ids. Demand: So, how to enable clients/members to create opspecs with member detail of other members, more specific, use the fullname to set for <dc:creator>? Proposal: Member metadata is added to the extended ODF model, as session-only data like cursors are, instead of being maintained in a separate pool. There would be new ops: OpAddMember, OpUpdateMember and OpRemoveMember. The hosting system (in owncloud case the server, in local mode the local system) would create and insert these ops into the op stack: * OpAddMember to tell about a new member and the metadata (fullname, avatar, color, editing rights, session_enter_time, idling/afk/pending connection..., etc) Would be inserted during the successful enterSession call by a client * OpUpdateMember to tell about any change with a member's metadata would be inserted by the host on any change of the metadata. * OpRemoveMember to tell that a member has left the session. Would be inserted by the host if the client calls leaveSession or is kicked out. The current memberdata (fullname, color, etc) itself should be kept around at clients, for the case that it is needed for some rendering of session data. No idea if that would also work with Peer2Peer, is ignored for this solution as it's not a target currently. The OpAddMember op for a new member should be part of the opstack before the client queries the genesis doc and the current op stack. That should be expected, due to adding that during the enterSession query from the client, so before any genesis doc & opstack fetching. Any client should only start to create own operations once it has received and replayed the OpAddMember of its own member (because only then it has got the full details about himself, like the fullname). For the transition period the existing MemberModel could be just a wrapper to the member model which should be part of ops.OdtDocument, and later could be merged into the normal ops.OdtDocument API. What do you think? Are there any holes in the concept? Too complicated? Or simply brilliant? Alternative ideas? Cheers Friedrich PS: As reminder, as sketched now and then some future support for chatting might be done in a similar way, by extending the odf model and doing the messages as operations. -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

2 4

How to make a browser spelling check enabled in webodf editor?
by hj 04 Nov '13

04 Nov '13

The browser spelling check does not work in webodf editor. I think the spelling check is very important feature. Any body knows this feature is planned for future milestone? Or any body has an idea how to enable the spelling check in wegodf editor? Thanks

2 1

Advancing WebODF paste support
by Philip Peitsch 01 Nov '13

01 Nov '13

Hi everyone, I'm starting to work towards improving the paste support in webodf so that it can do more than just paste plain text in a single line. The first step here is obviously designing what might work. I've put some documents together on this and have them sitting out in a branch (insert-fragment in my repo if anyone is interested). Here is where I'm at so far: Both of these are available in the branch as well at - https://gitorious.org/webodf/peitschie-webodf/source/insert-fragment:webodf… - https://gitorious.org/webodf/peitschie-webodf/source/insert-fragment:webodf… Copy & paste behaviour and support ================================== Overview -------- Paste support is extremely important to get right for an editor. Users have an expectation that data can be replicated with a high degree of accuracy when copied and pasted. This includes things such as pasting images, styled text (e.g., bold, underline), paragraph breaks, lists etc. This README does not cover details about how data is written or retrieved from the clipboard. For that information, please see README_clipboard.txt. Desired paste support --------------------- * Plain text with paragraphs, tabs, spaces * HTML text with direct formatting * HTML tables * HTML table rows & columns * Images (standalone) * Images within mixed HTML fragments (e.g., HTML fragment with paragraphs & images etc.) * Lists (bulleted & numbered) Requirements ------------ 1. Paste should be able to be undone/redone safely 2. Extra "formatting" steps should be able to be undone without removing the pasted content. E.g., automatically converting to a list or table (optional advanced feature) 3. Want to avoid duplicating logic in other operations (e.g., paragraph splitting & merging behaviours, image insertion, style addition, adding new list items etc.) 4. Any new operations must be able to be OT'ed easily Design ------ There are effectively two opposing approaches that can be taken to handle pasting of new data: 1. Create a complex operation (e.g., OpPasteData) that is responsible for determining how to insert a fragment into the document 2. Create a paste handler that attempts to break the paste fragment into a series of smaller operations Option 1 - Pro: Easily integrates with existing undo/redo manager - Con: OpPasteData likely to contain a lot of duplication of existing ops however - Pro: Less operations generated (less on-the-wire traffic) Option 2 - Pro: Better re-use of existing operations - Pro: Less complex operations required - Con: Need significant re-work of undo operation grouping to allow paste to be undone/redone OT adaption of a paste command is relatively straightforward for both options, as both largely generate insert-only operations. This means that usually the start position just needs to be shifted around to cope with added or removed characters. Based on the pro's and con's, Option 2 is the best approach for paste handling. The key argument for this is that it makes better use of existing operations (requirement#3). The existing undo manager grouping logic is not very extensible, and should be reworked anyways. Example paste steps ------------------- 1. Extract data from clipboard. Order of preference is - Custom webodf fragment ("application/vnd.webodf") - LO/MSWord fragment (??) - RTF fragment (??) - HTML ("text/html") - Plain text ("text/plain") 2. Convert data into webodf fragment (and associated styles) using appropriate import filter 3. Split the fragment up into separate paragraphs 4. Start a new transaction/undo group (this is a new feature...) 5. Add any new named styles (Op???) 6. Add any new auto styles (Op???) 7. For each paragraph - start a new paragraph at the current position (OpSplitParagraph) - insert the new paragraph (OpInsertFragment) 8. After all paragraphs have been inserted, remove the FIRST created split to merge the first inserted paragraph with it's previous sibling (allows the paragraphs to merge with the correct paragraph merge logic) 9. Finish transaction/undo group (Actually, this probably happens on the next edit op start) 10. Auto-convert things to lists, links, etc. (optional). This should be in a new transaction/undo group Questions --------- * Should pasting multiple paragraphs into a list should result in a new list item per paragraph? * Should links be automatically converted? Anyone have thoughts, concerns, feedback or cookies (I'm a little hungry after all this research…)? Cheers, Philip

2 2

Editor Menu Bar Idea
by Ryan Callaghan 29 Oct '13

29 Oct '13

My team is evaluating WebODF / the editor for use as part of an internal tool. In doing this one of the things that has come up that seems like it would be beneficial is to provide a hook to replace the menu bar with a custom one. For us we would nee the save button to save to a server, possibly generate a PDF, and we would likely want to remove several of the default buttons. The idea would be when constructing the editor a optional javascipt file name could be passed down as an argument - this would define the menu bar rather than using the default (there are likely other ways to do this as well). This would allow individuals to leverage the components already within the WebODF editor menu bar, be able to tweak it generically, and not have to rebuild webodf for minor adjustments. A setup like this seems like it would make the API usable with a broader audience without having to add in a significant amount of configuration options. Thoughts? Thanks, Ryan

2 1

using jsdom instead of xmldom
by Jos van den Oever 29 Oct '13

29 Oct '13

Hi all, Our tests in Node.JS do not run the DOM related tests. I looked into using JSDom instead of XmlDom. JSDom is a more complete implementation with e.g. a window object. The patch to use JSDom instead of XmlDom is attached. However, I could not run any additional tests because e.g. createTreeWalker is not implemented in JSDom. So this patch is mainly for future reference when JSDom aquires more of the DOM features that we need. https://npmjs.org/package/jsdom Cheers, Jos

1 0

Pending pull requests - October
by Philip Peitsch 13 Oct '13

13 Oct '13

Hi all, I wanted to check when pull request #24 (direct cursor styling - https://github.com/kogmbh/WebODF/pull/24) was going to get it's next review? This is now close to three weeks old, and has been waiting for the second round of reviewing for over two of those weeks. Cheers, Philip

1 0

SelectionMover and standardising lingo
by Philip Peitsch 09 Oct '13

09 Oct '13

Hi all, Just quickly brain-dumping some recommendations for how to improve the clarity and reduce terminology confusion within SelectionMover. Some commonly repeated terms that appear badly overloaded in SelectionMover are steps, positions and points. Add to this, the functions available are also extremely confusing both in terms of their names, and the internal code (there is a patch coming today to help with the code side). So, new terms of reference I'm standardising on are: Points ====== Raw DOM positions. This is any valid node & offset pair. Related functions ----------------- SelectionMover.StepCounter.countStepsToPosition - converts the distance between two Points into to it's (roughly) equivalent number of Steps Positions ========= A set of positions as returned by the position iterator. This is a subset of points as these can be filtered at the node level via a NodeFilter. Related functions ----------------- SelectionMover.StepCounter.countForwardSteps SelectionMover.StepCounter.countBackwardSteps - converts the number of Steps into it's equivalent number of Positions SelectionMover.movePointForward SelectionMover.movePointBackward - Move the cursor the requested number of Positions in forward or backwards Steps ===== A filtered subset of positions as returned by the position iterator. This is controlled using a PositionFilter. Related functions ----------------- SelectionMover.StepCounter.countStepsToPosition - converts the distance between two Points into to it's (roughly) equivalent number of Steps SelectionMover.StepCounter.isPositionWalkable - returns true if the supplied iterator is a valid Step SelectionMover.StepCounter.convertForwardStepsBetweenFilters SelectionMover.StepCounter.convertBackwardStepsBetweenFilters - translates between one filtered set of Steps to a different filtered set of Steps. IMPORTANT: this function will only work filter1 only accepts a subset of filter2. countStepsToLineBoundary - convert the distance between the cursor and nearest line boundary into Steps countLinesSteps - convert the distance between the cursor and the same horizontal position X lines up/down into Steps My recommendations (I'm assuming you want to hear these :) ) 1. Standardise SelectionMover on Points and Steps only. Any attempts to move a cursor to a Position that is not also a Step is likely a bug. The only place where we deliberately move in non-Step increments is when trying to put the cursor back into a filtered Step. This same effect could be achieved by calling moveForwardStep(0, filter). 2. Remove or rewrite convert(Forward|Backward)StepsBetweenFilters. The current implementation will not work for arbitrary filter pairs. These should likely be re-written to return the number of filter1-steps when travelling filter2-steps in distance. I would also suggest this takes the same approach as countStepsToPosition and round the cursor back to the Point of the last filter2-step that is smaller-than or equal-to the current cursor Point. Cheers, Philip

3 3

apache odfdom/Simple API
by Tobias Hintze 30 Sep '13

30 Sep '13

Hi, I just stumbled again over: http://incubator.apache.org/odftoolkit Which has ODFDOM and this Simple API, which I did not notice before: http://incubator.apache.org/odftoolkit/simple/document/index.html It comes with the respective javadoc for API: http://incubator.apache.org/odftoolkit/simple/document/javadoc/index.html and a nice cookbook like set of examples: http://incubator.apache.org/odftoolkit/simple/document/cookbook/index.html Perhaps it makes sense to align with this API. set*, apply* et al might map to Operations in our universe, while the getter-functions show the lack of the analogy within WebODF. (While Operations for changing a document are one part. There is a similar need for the opposite (getting data out of a document.)) th -- Tobias Hintze

2 1

Pending pull requests
by Philip Peitsch 30 Sep '13

30 Sep '13

Hi everyone, Just wanted to bring some attention to some of the older pull requests still waiting for (another) review: Improve visual height and vertical alignment of caret - https://github.com/kogmbh/WebODF/pull/6 - 10 days old (3 days on gitorious + 6 days on github) This has been reviewed by Aditya. All feedback addressed, should just need to be merged assuming Aditya is happy with the fixes. Add support to insert inline image - https://github.com/kogmbh/WebODF/pull/7 - 12 days old (5 days on gitorious + 6 days on github) Had two rounds of review so far. All feedback addressed… awaiting another review. Fix image removing issue where draw:frame is removed but draw:image is left behind in the document - https://github.com/kogmbh/WebODF/pull/17 - 5 days old Has not been reviewed by anyone. You guys are understandably busy angling towards the up-coming november 0.5 release. Please let me know if there is anything we can do to help speed up the review & merging of these. I'm willing to swap my own time fixing bugs and features that are a higher priority for you (e.g., investigation into IE10 fixes) in exchange for getting someone's time to review these :). If we had a roadmap of some of these priorities, we could definitely help align our patches a little more towards areas that are of strong interest to your 0.5 release (e.g., lists)? Cheers, Philip

1 0

Move to GitHub
by Tobias Hintze 24 Sep '13

24 Sep '13

Hi! we plan to move from Gitorious to GitHub. I already started by copying Git repository over, and will keep it in sync during the next days. Proposal is to have the next release on GitHub already, so we only need to find a nice revision for tagging v0.4.3. After the move I also propose to move from current Redmine to GitHub issues. This lowers the hesitation-threshold for actually filing bugs. This is because of the integration and because people just know how to file bugs at GitHub. RFC! th -- Tobias Hintze // KO GmbH http://kogmbh.com/legal/

4 5