Re: Kix, or the new docs editing surface -> open source? Please...

2,138 views
Skip to first unread message

Nick Santos

unread,
Jul 30, 2012, 5:34:59 PM7/30/12
to closure-lib...@googlegroups.com
If the Docs people wanted to do this, I think the technical barriers
would be very difficult (think O(eng years)). Without going into
technical detail, the stack of components it depends on is deep,
including a substantial server-side component.

Nick

On Sat, Jul 28, 2012 at 3:35 PM, <andrewcar...@gmail.com> wrote:
> As far as I can tell, this is the only decent on-line writing surface out
> there. Does anybody know if there's any plans to include it in the Closure
> project or to otherwise make it open source? If the answer's no, what if I
> say pretty please?
>
> Thanks,
>
> Andrew

Daniel Steigerwald

unread,
Jul 30, 2012, 7:32:02 PM7/30/12
to closure-lib...@googlegroups.com
Actually, the principle of Kix is simple. Compute each letter size,
done. Ok, it is not so easy. For example browsers render various
spaces widths between letters If text align is justified (but
justified text does not fit in web design, so remove justify option is
good workaround).
Caret is blinking div. You also need another hidden div with
contentEditable to allow rich past. The main problem I had with
implementing Kix like editor (I made it several years ago) was that I
had no good library for that task. But that's not true anymore, we
have Closure :) Good luck and dont hesitate to ask me for another
nasty details. Cheers.

Hochhaus, Andrew

unread,
Jul 30, 2012, 8:15:01 PM7/30/12
to closure-lib...@googlegroups.com
On Mon, Jul 30, 2012 at 4:34 PM, Nick Santos <nicks...@google.com> wrote:
> If the Docs people wanted to do this, I think the technical barriers
> would be very difficult (think O(eng years)). Without going into
> technical detail, the stack of components it depends on is deep,
> including a substantial server-side component.

In terms of minimizing dependencies, one partial solution would be to
just not open source any of the server side code. This has been done
in a few other places in closure-library (eg: BrowserChannel,
protobuf, etc) and the community has stepped in to fill the gap with
third_party implementations.

I think part of the complexity you are referring to is the server side
OT component needs to perform the exact same transformations [1] as
the client side code (though I could be misunderstanding why else the
editor would need to be tightly coupled with the server side code). If
it helps getting kix open sourced, I know that I would invest a
significant amount of time into documenting/re-implementing a server
side component. I'm guessing others on this list may be interesting in
doing the same. By using documentation/code examples from how OT works
in Apache Wave we might be able to further minimize the work required.

-Andy

1) https://groups.google.com/d/topic/closure-library-discuss/GhiycGt0ZH4/discussion

Andrew Hughes

unread,
Jul 31, 2012, 11:15:25 AM7/31/12
to closure-lib...@googlegroups.com
I'm not even so much interested in the multi-user, collaborative aspects of docs. And I'm not even talking about google docs as a whole, meaning their server-side drive or storage systems.

I'm mostly just interested in the writing surface itself, and their text layout engine. The writing surface is really the only truly professional feeling on-line writing surface I've used.

The whole operational transformation thing is fascinating, but not exactly what I need. 

Hochhaus, Andrew

unread,
Jul 31, 2012, 11:48:04 AM7/31/12
to closure-lib...@googlegroups.com
On Tue, Jul 31, 2012 at 10:15 AM, Andrew Hughes
<andrewcar...@gmail.com> wrote:
> I'm not even so much interested in the multi-user, collaborative aspects of
> docs. And I'm not even talking about google docs as a whole, meaning their
> server-side drive or storage systems.
>
> I'm mostly just interested in the writing surface itself, and their text
> layout engine. The writing surface is really the only truly professional
> feeling on-line writing surface I've used.
>
> The whole operational transformation thing is fascinating, but not exactly
> what I need.

I fully agree about the high quality feeling of the docs on on-line
writing surface. It would be excellent to have it open sourced even
without any of the OT code.

The reason for my comment was that, it is possible that the writing
surface is relatively tightly coupled with their data model and OT
code. If so, that might mean it isn't an easy task to break off just
the writing surface for open sourcing. My point was that the community
would be very grateful to see a portion of the system open sourced
even if a significant amount of work needed to be done before that
code sourced code could be used.

-Andy

Nick Santos

unread,
Jul 31, 2012, 12:03:18 PM7/31/12
to closure-lib...@googlegroups.com
OT puts some significant constraints on how you define your data
model, and how you build editors. Every modification that the user can
make has to be expressible as a transform, and you have to rigorously
define how that transform interacts with other transforms (e.g.,
undo/redo, merging).

In all the OT editors I've seen, the editor needs to be tightly
coupled to the transforms in order for this to work.

Nick
Reply all
Reply to author
Forward
Message has been deleted
0 new messages