Andreas Hartmann wrote:
Richard Frovarp schrieb:
Andreas Hartmann wrote:
What exactly is wrong with Kupu? Tables seems to work. I see that
the code used for image insertion makes it not show up on the
editor's view.
Here's a quite extensive list:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46934
Would updating to Kupu 1.3.5 vs our current 1.2 make things better?
Maybe updating would make sense, but I'd suggest that we postpone
this to a later release. Release early, release often.
-- Andreas
Is there even an underline anymore in XHTML? The problem with Kupu is
all the integration code is in their svn. It would appear that Gregor
at one point had commit access. I do think that we can fix some of
the Kupu stuff easily, but it will break BXE. It would be really nice
to ship with one GUI editor that worked across browsers. I don't know
that Kupu is that one.
Is there anything else out there that works and is license compatible?
I'm afraid that virtually all editors concentrate on (X)HTML and have
no support for arbitrary XML.
Most organizations I'm in contact with have sooner or later slimmed
down their palette of available editors to one WYSIWYG editor for the
daily business and the source editor for delicate surgery. This
reflects our situation – multiple editor integrations are potentially
conflicting and require a lot of maintenance work and work-around code.
I'd suggest that we concentrate on a really thorough and fool-proof
Firedocs integration. I think this is the most promising editor
platform at the moment, it has a good usability and is extensible. And
we should present the AtomPub-based protocol currently used by
Firedocs to other editor communities, maybe someone will be interested.
I hope it is correct to say that IE support is only required by large
organizations with strict IT guidelines. If they seriously consider
investing in a CMS, they should be prepared to spend some money on a
decent editor. Q42 provides a demo version of Xopus that can only be
invoked from localhost, we could integrate it as a teaser and
proof-of-concept for those organizations. WDYT?
-- Andreas
Yeah, but Firedocs is on platform as well, just like BXE. It does
satisfy the needs of people like us, but not necessarily our target
customers.
Why force users to use a browser they are not familiar with? IE support
would be required for many environments without strict guidelines. IE
support was a requirement for both EduTech (Lenya) and NDSU (Typo3). At
both organizations, IT isn't strict. It's about letting users choose the
browser they like and supporting it. FF and IE are the two big ones.
Both TinyMCE and FCKEditor support Chrome, Safari 3, and Opera 9 as
well. At the time of initial deployment for EduTech, FCK didn't support
Safari. This required the OS X schools to install FF, which was kind of
a big deal.
Granted, as you said, an org will settle on one browser. However, if all
we ship with are FF browsers, it looks like we don't support anything
other than the techy FF crowd, which may give it an appearance of harder
to use than it is.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@lenya.apache.org
For additional commands, e-mail: user-h...@lenya.apache.org
