Community
Participate
Working Groups
One thing clearly missing from SWT is a WYSIWYG HTML Editor. The need for HTML editing is very common, you just need to take a look at how many of these editors are available for other technologies. A quick search of the internet shows that I am not alone this need. This request is not new and has been been discussed earlier on BugID's 54426, 98904 but has never been implemented. I realise that writing a HTML WYSIWYG widget in an enourmous task but why not start small and add HTML support to the existing StyledText widget for the existing styles eg: Bold, Italic etc. The StyledText widget supports an RTFWriter but it really needs a HTMLReader/HTMLWriter. Even better scrap the reader/writer concept and add an extensible StyleConverter and provide default RTF and HTML implementations. The converter would need to be extensible so people can add support for styles as they need them. Also people could add custom converters (eg: custom XML). Developers could then use examples such as this http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/SWTTextEditorDemo.htm to write an editor that supports HTML and RTF. Let's bring SWT in to world of Web2.0 and support HTML editing.
*** Bug 98904 has been marked as a duplicate of this bug. ***
Why not use the Browser to render HTML? Browsers can also be flipped into HTLM editor mode. We should consider this instead of implemeting an HTML renderer for StyledText.
(In reply to comment #2) I don't know of any way of making the SWT Browser "flip into editor mode". I know that on windows SWT embeds the WebBrowser COM control which does not have any editting capabilities. I know of a couple of OpenSource projects that have attempted to resolve this problem by embedding the Windows DHTMLEDIT COM control but this is very platform specific.
Grant, you had code around that turned on HTML editor mode, at least for Mozillam, right?
> Grant, you had code around that turned on HTML editor mode yes, see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet267.java
(In reply to comment #5) Thanks Grant, this offers a great workaround. I cannot use this unfortunately since I cannot be sure that my users will have Mozilla installed on their desktop. I would still very much like to see a fully integrated WYSIWYG HTML editor in SWT.
Grant, is it true that all the browsers we support have a WYSIWYG mode?
IE has a WYSISYG mode, though I don't think there's currently a way for a Browser client to turn it on. I don't know about Safari. > I cannot be sure that my users will have Mozilla installed on their > desktop If this is the only problem with this approach then you can ship the xulrunner plug-in with your app and point the Browser at it by setting the org.eclipse.swt.browser.XULRunnerPath system property. Not everyone wants to do this since the plug-in will grow your app by 6M (on win32) to 17M (on OSX), but it seemed work mentioning. If you want to pursue this there's lots of xulrunner-related info at http://www.eclipse.org/swt/faq.php .
I suspect we are getting off track. There are several different workarounds to this missing feature. I found 3 projects on sourceforge and at least one commercial solution. My intent with this is to request that the Eclipse SWT team consider a formal multi-platform api to support HTML WYSIWYG, since I firmly believe that HTML editing will (if not already) be an important part of any widget library.
I think the WTP project already has html editors. http://www.eclipse.org/webtools/
(In reply to comment #10) > I think the WTP project already has html editors. > http://www.eclipse.org/webtools/ Yes I think you are correct. The Web Tools Project does have a HTML editor plug-in which is great for users of Eclipse but of little use to SWT developers.
I'd rather not see an already huge StyledText API grow to encompass HTML editing. This seems like a perfect reason to migrate your app from swt to rcp, and reap the benefits of WTP's work.
(In reply to comment #12) I don't think this will complicate the StyleText api. I would imagine that it's a separate classes perhaps called StyledTextHTMLWriter/HTMLReader similar to the existing RTFWriter, except not an inner class, perhaps optionally used in place of RTFWriter for clipboard transfers. I was dissapointed to see that this was not included in the SWT 3.5 StyledText enhancements. Lots of people are trying to solve this problem. Here are a few links; http://www.richclient2.eu/richhtml4eclipse/ This idea is to embed a html WYSIWYG editor using the browser. Great idea but doesn't work on some platforms, in partiuclar Ubuntu. http://www.dugaldmorrow.com/index.php?option=com_content&task=blogcategory&id=24&Itemid=44 This product is almost exactly what I am proposing. It has a few missing features (eg: justification) and is not open source so we can't add them. http://sourceforge.net/projects/swt-composer/ http://sourceforge.net/projects/swteditor/ A couple of other open source projects that attempt different ways to solve this problem.
(In reply to comment #13) > I don't think this will complicate the StyleText api. I would imagine that > it's a separate classes perhaps called StyledTextHTMLWriter/HTMLReader similar > to the existing RTFWriter, except not an inner class, perhaps optionally used > in place of RTFWriter for clipboard transfers. StyledText doesn't support tables, HTML without tables won't be very interesting. Adding table support to StyledText would be a major effort.
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
the TextEditor example demonstrates ways to enhance/use StyledText in such a way that even embedded pictures are possible. That could be a way to add tables as well - although it would be much nicer if this was possible through a plugin architecture in StyledText proper rather than in a wrapper class. However, such attempts are often rendered void as long as major parts of StyledText remain (package-)private, and thus cannot be used/overridden by user code. I for my part was considering to add advanced RTF styling capabilities. But since I cannot get at the RTFWriter during copy/paste (and the default RTFWiter is very weak), I am stuck right here.
HTML support for StyledText is in the plan for 3.7, sorry. Can you use the Browser widget + some free html editor for the web ? StyledText's RTFWriter can only implement RTF styling capabilities that are available in StyledText. I don't understand how you can add an advanced RTF styling without extending StyledText first.
(In reply to comment #17) > HTML support for StyledText is in the plan for 3.7, sorry. I meant to say, it is *not* in the plan. Sorry.
(In reply to comment #18) > (In reply to comment #17) > > HTML support for StyledText is in the plan for 3.7, sorry. > > I meant to say, it is *not* in the plan. Sorry. So, who should I contact to discuss contributing an HTML editor and CSS query engine? These components have been used for some time in my JDocEditor plugin. The editor extends StyledText directly to add markup recognition inline. Included CSS markup is evaluated against standard stylesheets.
> So, who should I contact to discuss contributing an HTML editor and CSS query > engine? http://www.eclipse.org/nebula/
(In reply to comment #19) > The editor extends StyledText directly to add markup recognition inline. Extending StyledText as it currently exists is bound to lead to severe restrictions IMO. E.g, you wont be able to override Copy/Paste behavior, since the related code is private. And the default implementation for copy/paste of styled text is based on a very limited set of RTF attributes
(In reply to comment #21) > (In reply to comment #19) > > The editor extends StyledText directly to add markup recognition inline. > > Extending StyledText as it currently exists is bound to lead to severe > restrictions IMO. E.g, you wont be able to override Copy/Paste behavior, since > the related code is private. And the default implementation for copy/paste of > styled text is based on a very limited set of RTF attributes Yes, StyledText does impose limitations. The most significant is: no internal DIVs. As is, a single StyledHtml instance is essentially a WYSIWYG text area. DIVs might be possible by embedding one or more StyledHtmls in another - have not tried yet. Copy/paste of HTML marked up text works quite well. The copy/paste handlers could be adapted to support RTF->HTML and HTML->RTF conversion. To be clear, StyledHtml embeds zero-width, non-breaking spaces into the StyledText contents. They are used as pointers into a table of unreduced HTML markup tags extracted from the HTML-in. So, all stylesheet and HTML markup is preserved and interpreted on-the-fly using CSSQuery to determine the StyledText presentation. HTML-out preserves the HTML-in markup subject to edits made. Is this an adequate/appropriate approach to adding HTML support to be worth contributing? Thanks...
