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-announ…
Tom
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Neil Kandalgaonkar (| <neilk(a)wikimedia.org>