April 2013 - WebODF - lists.nlnet.nl

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