|Kix, or the new docs editing surface -> open source? Please...||andrewcar...@gmail.com||7/28/12 12:35 PM|
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?
|Re: Kix, or the new docs editing surface -> open source? Please...||Nick Santos||7/30/12 2:34 PM|
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.
|Re: Kix, or the new docs editing surface -> open source? Please...||Daniel Steigerwald||7/30/12 4:32 PM|
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
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.
|Re: Kix, or the new docs editing surface -> open source? Please...||Andy Hochhaus||7/30/12 5:15 PM|
On Mon, Jul 30, 2012 at 4:34 PM, Nick Santos <nicks...@google.com> wrote: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
I think part of the complexity you are referring to is the server side
OT component needs to perform the exact same transformations  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.
|Re: Kix, or the new docs editing surface -> open source? Please...||Andrew Hughes||7/31/12 8:15 AM|
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.
|Re: Kix, or the new docs editing surface -> open source? Please...||Andy Hochhaus||7/31/12 8:48 AM|
On Tue, Jul 31, 2012 at 10:15 AM, Andrew HughesI 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.
|Re: Kix, or the new docs editing surface -> open source? Please...||Nick Santos||7/31/12 9:03 AM|
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.,
In all the OT editors I've seen, the editor needs to be tightly
coupled to the transforms in order for this to work.
|unk...@googlegroups.com||11/11/12 2:46 PM||<This message has been deleted.>|