- WebODF - lists.nlnet.nl

Virtual Selection Demo
by Philip Peitsch 05 Jun '13

05 Jun '13

Hi all, Take #1, virtual selection for your delight. Lots of small improvements that could be made over this, but it is enough to demonstrate how the concept may work. Any feedback, don't hesitate to email me :) -- Philip Peitsch Mob: 0439 810 260

1 0

Virtual Selection Demo
by Philip Peitsch 05 Jun '13

05 Jun '13

Hi all, Take #1, virtual selection for your delight. Lots of small improvements that could be made over this, but it is enough to demonstrate how the concept may work. Any feedback, don't hesitate to email me :) -- Philip Peitsch Mob: 0439 810 260

1 0

Paste behaviours
by Philip Peitsch 04 Jun '13

04 Jun '13

Hi all, I've put up an experiment allowing paste support in Firefox & IE10 (& Chrome). I'm don't think it's a good idea to merge this directly into master though, as I'm not yet convinced it covers all the edge cases. However, I don't have any requirement to carry this further forward at this point either so this branch is effectively dead. Perhaps this will save someone some extra work and research when they move to doing this properly though... https://gitorious.org/webodf/webodf/merge_requests/19 Key problems: * Doesn't support multiple pastes when holding ctrl+v. Will only paste once and stop * Doesn't work in Safari 6 (current version on 10.7+). Safari is really painfully strict about only firing paste events if content editable is active BEFORE the key presses are received, making this workaround not function Other than that, it's pretty solid (i.e., I can't prove it is actually broken). For my own purposes, the fact that this implementation can never work in Safari means there is no point pursuing it further, as that is the only browser I need to support :-/ Any questions, feel free to bother me! For those interested, I've attached a sandbox file that I used to come up with this approach. Cheers, Philip

1 0

MR 16: Preserve cursor selection during text insertion
by Philip Peitsch 28 May '13

28 May '13

Hi all, Just letting you know MR 16 is up for review: https://gitorious.org/webodf/webodf/merge_requests/16 It would be nice to write a test to prove this, but I don't really know how to approach it unfortunately. Cheers, Philip

1 0

RR: Fix bug with placing a cursor at the beginning of a nested span element starting a paragraph
by Philip Peitsch 27 May '13

27 May '13

Hi all, Just putting the following merge request up for feedback and review: https://gitorious.org/webodf/webodf/merge_requests/15 Cheers, Philip

1 0

Outstanding merge requests
by Philip Peitsch 23 May '13

23 May '13

Hi, Just wanted to check up when processing of the outstanding merge requests is likely to happen: https://gitorious.org/webodf/webodf/merge_requests/12 https://gitorious.org/webodf/webodf/merge_requests/13 I understand everyone is quite busy and it's easy to miss these. Is there anything I can do to make your life easier for reviewing and integrating these patches (e.g., send an email for every merge request)? Thanks for all your work. Philip

2 1

EditInfo and change tracking
by Philip Peitsch 13 May '13

13 May '13

Hi all, Playing with some more of the interactive editing and tracking and I was hit by a small question... Is there any technical reason that the edit system couldn't be implemented using the standard ODT change tracking mechanisms? ( http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#_… ) Looking at the spec, the change-info provides an author, time and optional comment related to the change. Lining this up visually with the start and endpoints seems simple enough. The primary benefit of this approach is that documents with change tracking active will actually display sensibly in WebODDF... and editing from WebODF will export nicely into other suites. This isn't a high priority item for me, more a technical musing about whether it was specifically considered and avoided :) Thanks again for all your work. -- Philip Peitsch Mob: 0439 810 260

2 1

Status
by Sunil Agrawal 30 Apr '13

30 Apr '13

Hi, I just came across this project and sounds very interesting. What's the status of the project? Is it actively maintained? Is it used by any commercial entity? If yes, some success stories will definitely help in evaluating this project. Thanks, Sunil

2 1

Caret/cursor implementation
by Philip Peitsch 30 Apr '13

30 Apr '13

Hi all, I was looking at some of the caret display challenges (e.g., the current caret appears offset compared to the line, position doesn't always expand properly for line heights etc.) and started researching alternative ways of doing things. Additionally, I am trying to avoid modifying the DOM if at all possible as other parts of things I'm working on are using MutationObservers... so less events is better :). Firstly, the current implementation creates a cursor in the document as follows: 1) Find the requested position (e.g., via mouse click or cursor navigation with arrow keys) 2) Insert the cursor node (splitting the text node if necessary) The cursor style position to absolute (to stop the browser from modifying text flow or layout), while the height is set to 1em (to try and mimic the normal line height). Unfortunately, by setting the position to absolute, the browser no longer draws the caret in line with the text vertically, instead choosing to display it at position 0 of the cursor div (quite noticable on some of the documents I'm using). Trying to find a fix for how to get the cursor position correct, I researched how Google Docs does this. I've noticed that Google Docs doesn't insert the caret inline into the text. It has a global caret element, who's position is updated on cursor navigation or clicks. To this end, I made a quick demo showing how the googledocs cursor is achieved. The pro's of this approach: * No modifications of the document structure in order to render the cursor. This will be faster, more memory efficient (due to how text nodes etc. like editing) * Cursor (so far in firefox and chrome at least) renders in a more natural spot, as it is vertically centred, and more easily put between characters (the current implementation also sits a tiny bit too far to the right, though that could be fixed with CSS easily enough I believe) The con's (because nothing is perfect) * Cursor synchronization will always need to be done manually. The existing implementation of placing the cursor inline with the text means the browser can take care of flowing the cursor along as text is edited.With the googledocs approach, each text modification etc. will need to relayout the cursors manually. * Unsure about the speed of this approach * Also unsure about how cross-browser compatible this is... What do people think? Is there any benefit from the Range-based approach vs inserting a cursor node directly in the document? Is it worth me investigating further? Cheers, -- Philip Peitsch Mob: 0439 810 260

1 0

Documenting configuration options
by Philip Peitsch 10 Apr '13

10 Apr '13

Hi, A recent patch I submitted (https://gitorious.org/webodf/webodf/commit/259b203d2198ce457c85994cbda5eaac…, https://gitorious.org/webodf/webodf/commit/b5ebf1452b495d0cd2143e7425e6f57a…) had some difficulties with the documentation of the SessionViewOptions type. I didn't want to enforce a particular class, as these options are basically a dictionary of optional entries that influence how the view is initialised, and is most conveniently passed in using plain old object literals (i.e., { } notation). A few ways that have been attempted: Anonymous types Looks like: /** * @constructor * @param {{editInfoMarkersInitiallyVisible:boolean=true, caretAvatarsInitiallyVisible:boolean=true}} viewOptions * @param {ops.Session} session * @param {gui.CaretFactory} caretFactory */ function SessionView(viewOptions, session, caretFactory) { … } I didn't like these because it meant that the options had to be copied and pasted into every place that passed them around. Anonymous types also don't have any syntax for allowing documentation of members (from what I could tell) Interface type Looks like: /** * @interface */ gui.SessionViewOptions = function() { "use strict"; /** * Set the initial edit information marker visibility * @type {boolean} */ this.editInfoMarkersInitiallyVisible = true; ... }; This was the submitted code. There is no clear way to document pure properties involving primitive types however. All combinations attempted (e.g., this.X, SessionViewOptions.prototype.X) complained in either closure or jslint. Typedef Looks like: /* * @typedef {{editInfoMarkersInitiallyVisible:boolean, * caretAvatarsInitiallyVisible:boolean}} */ gui.SessionViewOptions; This was the chosen approach for now, as at least it allows the SessionViewOptions properties to be defined in only one place. However, it still doesn't allow these individual members to be documented. Also, jslint doesn't really like the non-method, non-assign statement that defines the type name Proposed approach - Struct type Looks like: /** * @constructor * @struct */ gui.SessionViewOptions = function() { "use strict"; /** * Set the initial edit information marker visibility * @type {boolean} */ this.editInfoMarkersInitiallyVisible = true; ... }; This method was discovered after submission of the patch. It allows object literals to be cast to that type (see example at https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-str…) I think this is perhaps the best option so far, and suggest potentially it be adopted as "the standard" way of documenting these configuration objects where they are likely to see re-use or passage between classes. Does anyone else have other thoughts or preferences? Cheers, Philip Peitsch

1 0