Thanks for the heads-up -- it was interesting, but it doesn't seem like a useful strategy for us. I kind of doubt it's all that useful for GTK, actually.

This would be equivalent to having every person who is editing a wiki page VNC'ing into some GTK application. I haven't done the math but that seems like *way* more server resources.

Not to mention the latency of roundtripping every keystroke before you can see it displayed on the screen. That can't work for mobile or low bandwidth situations.

And it only works in Firefox.

And, generally, I've found that solutions that use an app framework that isn't the browser seem like tempting usability wins but often become usability failures. There are a million subtle ways in which this just won't be the web, and it will drive people nuts. You can forget about user scripts. Or your browser extension that does spellcheck in Linear B or whatever.

Also, even if this was the perfect solution otherwise, we'd still have to write a GTK application to parse and edit wikitext, and I am not sure we have the expertise to do that well.

I think we should stick close to the HTTP paradigm -- otherwise we're going to have to build completely different infrastructure and team...

On 10/15/11 2:30 PM, Thomas Gries wrote:

I just want to inform you about an LibreOffice Conference Announcements dated October 14, 2011

"During the LibreOffice Conference, The Document Foundation has announced: LibreOffice Online Prototype: .. LibreOffice Online is based on GTK+ framework and HTML5′s canvas, and has been developed by SUSE’s Michael Meeks, built on GTK+ broadway from RedHat’s Alex Laarson."

Source: http://blog.documentfoundation.org/2011/10/14/libreoffice-conference-announc...

Tom

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l