Community
Participate
Working Groups
Display HTML in a widget. In Eclipse 2.0 and 2.1, the only supported option for rendering HTML in the workbench is to use OLE to link to IE. This support is Windows only; there is no such option in other operating environments. Even on Windows, this only works for IE and not other browsers. There are already several Eclipse components that could benefit from HTML display functionality in a widget: welcome pages; update manager update site overview; hovers that show Javadoc. The Platform should provide a portable way to display HTML in a widget and support it in all operating environments. [Platform UI] [Themes: User experience; Rich client platform]
Steve Ni asks: 1.When will the widget initially release? I am so eager for it! 2.Will the coming HTML widget have html edit function, like JTextEditor for HTML in Swing? or just for viewer? NE responds: We haven't set a firm date for the HTML widget work. It's something we'd like to get in in the coming months. We have working code based on Mozilla, but we're awaiting clearance from the lawyers to publish it. Initially we're just looking at viewing. If you have other requirements, please add them to this feature request. Also, if you care about this feature request, you should vote for it.
Some sort of rich text editing (preferably HTML) is a huge requirement for one of our projects.
I would love to see DOM support, with functions to access the document (e.g. IDOMDocument.getRoot(), IDOMElement.getChildNodes(), etc.) I've currently implemented something like this with an IE OLE component, and plan to do the same with a GTK Mozilla component for compatability with Linux. If you have any semi-working Mozilla code, I'd be willing to help add DOM functionality.
If the browser components also contains the drag and drop support then it would be great. Then we can think about creating a WYSIWYG editor. I am currently using swing's HTMLEditorKit to create a WYSIWYG editor which is a hell.
I recommend that all people who voted for this bug go and cast their vote for #37724 instead (it is proposed but not committed for 3.0). Once you can run Swing "on top" of SWT, you'll get your HTML renderer and many-many more other things!!!
I disagree with comment #5. Bringing Swing into the picture would just complicate things (not to mention slow them down and lose native l&f of SWT).
I am using swing's htmleditorkit on top of swt and the performance is considerably poor. And also the swing components flicker a lot in swt.
I sure hope this widget supports CSS from the beginning.
*** Bug 37005 has been marked as a duplicate of this bug. ***
A Browser widget has been introduced on Windows (Internet Explorer) and Linux GTK (Mozilla 1.4 GTK2). It is now available in the org.eclipse.swt project. Special thanks to John Ponzo of IBM TJ Watson Research Center for contributing his embedded browser support. The SWT FAQ has been updated. Please report to the following link to get details on the current state, platform support etc. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#whatisbrowser A snippet has been added. As outlined in the SWT FAQ above, the Browser's API is not frozen. The snippet will be updated to reflect any API change. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/snippits/snippet128.html We'll keep you posted on further progress being made on this plan item. You can help us by testing the Browser widget on the platforms currently supported (report to the previous SWT FAQ link). Please open separate PR's to help us tracking down issues you may uncover. Chris
Will it be possible to use Mozilla on windows too?
How do you plan to implement the browser widget under Motif? Also with Mozilla or are you going to emulate it in pure Java?
In response to comment 11: as outlined in http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#browserplatforms, the Browser widget uses IE on Windows. For the curious, I have opened bug 41840 that documents how to try the SWT Browser with Mozilla on Windows from the SWT source. If you want more support for this combination, please vote on bug 41840. In response to comment 12: we will investigate embedding Mozilla GTK into SWT Motif.
For those who want to use a simple HTML view/viewer based on the browser widget, you can download it using the Eclipse Update (Help->Software Updates- >Find and Install) at: http://dev.eclipse.org/viewcvs/index.cgi/platform-update-home/temp/browserSite Alternatively, you can directly download the plugin from: http://dev.eclipse.org/viewcvs/index.cgi/platform-update- home/temp/browserSite/plugins/org.eclipse.ui.examples.browser_1.0.0.jar The source code is included with the plugin.
I'm not sure a widget that simply wraps IE or Mozilla is what the users had in mind. For one thing, you have to have the browser being wrapped installed, and it has to be a compatible version. The widget brings in a rather large code base into the process, with an unknown cost for each instantiation. There will be incompatabilities between the different implementations of the widget. The widget will be necessarily limited in its api because of the different degrees of openness of the underlying controls (for example, somebody asked for a DOM representation of the HTML being viewed, which is unlikely). It's likely that code will have to handle the case when the widget is not available, which limits its usefulness and ubiquity. When I saw the plan item I was assuming that there would be a Java based fully- integrated custom control that was perhaps based on StyledText or GEF's rich text widget. Would it be foolish to hope that the wrapper is just a stop-gap until the Java one can be written?
There are always pros and cons for either approach, just like there were with SWT and Swing. Actually, I did expect to see a wrapper of a real browser and I would be disappointed to get a so-so browser implemented from scratch. Without having looked at the actual implementation, I much prefer the current approach, that gives us the full power of a browser, including CSS, Javascript, and all the other neat browser features.
Could it be done also on Mac using an embedded Safari ? Safari is to be as pervasive on Mac as IE on PC, and is supposed to be easy to embed.
It doesn't have to be from scratch - if for example the Safari/KDE code or the ReqWireless code or the GrandRapids code or any others could be released under CPL (perhaps dual licensed?), one of them could be ported and integrated. Also, I'm reading the original plan item which says a widget is needed that can be used in "welcome pages; update manager update site overview; hovers that show Javadoc". Do these places require full CSS/DHTML with all the legacy compatability baggage that a full blown consumer oriented browser component provides?
At first I was wishing that the browser component was based on Gecko (Mozilla) on all platforms because that seemed simplest. However, after reflecting on it, it seems that the most "SWT-Like" way of doing it is just to wrap the standard browser control on each platform. This provides the best native user experience. The only sense in which I still wish for a Gecko implementation is that I'd really also like to have an HTML editor control, and I suspect that this would be easier if the whole browser infrastructure were based on Gecko. But that wasn't a part of the 3.0 plan either.... So as long as there aren't lingering focus problems and other nits like happened in 1.x and 2.x using the embedded IE Active-X control (ie: the user can't tell that the control isn' just a really good clone of IE or Mozilla), I'm not unhappy with this approach.
Does anyone know the technical requirements and/or the legal status of wrapping the necessary Mozilla/Gecko binaries with an SWT application for distribution? It seems that you could just pack up the mozilla code, put it in a directory in your SWT project, change org.eclipse.swt.internal.mozilla.GRE.mozillaPath to be the new location of the Mozilla binaries, and you'd have a packaged distribution. Are there licensing issues with this approach?
My reading of the "SWT-like" approach is to wrap standard windowing system widgets that are guaranteed to be on a certain platform. For example you don't have to worry about whether the Windows or GTK Button widget has been installed or has the right API. On Windows, you can almost assume *some* version of the IE control is there, but strictly speaking it's not part of the Win32 widgets (it's an ActiveX control) and such a thing is iffy everywhere else at present. So I understand your point but I don't think it's a completely valid analogy. Don't get me wrong; I'm glad to have the wrappers but longer term I'm arguing for a different approach (an integrated hypertext custom widget). I haven't seen the API yet but hopefully it would support using a different approach under the covers in the future with minimal change.
Ultimately, we'd probably like to have both the wrappered system control and a lightweight Java one. There are definitely benefits to both approaches. Right now, I'll be happy with either one or the other.
In message #14 the url for the update site for the html view is slightly incorrect. Here it is again: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-update- home/temp/browserSite
In response to comment 17 - I have opened bug 41887 for the Mac developers interested in Safari.
In the current implementation there is no way we can develop a WYSIWYG editor in SWT. I would like to see something like Grand Rapid browser with support to WYSIWYG.
From what I know of XPCOM, it seems to me that working to extend the support for Mozilla in the area of using Composer would likely be the best solution for developing WYSIWYG editor support as a widget other than developing one from scratch.
My company has created a new HTML editor kit to replace the implementation in JDK 1.4 with one that supports HTML 4.0 and CSS 2. We are currently evaluating our options in regard to open sourcing at least the renderer portion. Is this something we could donate to the Eclipse project and would the project be interested?
That would be great. Everybody's really waiting for a HTML edit option.
The Browser widget is now supported on the Photon platform (v>20030919). Special thanks to Chris McKillop from QNX for contributing this platform implementation (bug 42467). Chris
On Linux, the SWT browser component seems to have a difficult time keeping the browser embedded within the Eclipse workbench. It tends to "break out" into its own top-level window at even the slightest provocation. For example, if I enable "fast view" on a view containing the browser, or put the the widget in a MultiPageEditor it will cause the browser to open in a separate top-level window and/or generate XPCOM errors. I've tried it with RedHat 7.3 and 9, both with Ximian Desktop 2, latest Mozilla, running 3.0M3, nightlies, and integration builds. This behavior is consistent amongst them. It works perfectly for me on windows boxen though. I'd be happy to file this as a separate bug report if that is appropriate, and I'd also be happy to "lay off" in the event you all are well aware of this and don't need yet another person bringing it to your attention.
Tod, yes please open a separate PR with all the steps to reproduce. Thanks Chris
The Browser widget is now supported on Linux Motif (v>20030926). The FAQ items related the Browser widget have been updated: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#browserplatforms Chris
Chris, I've added <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=43878">Bug 43878</a>, describing the problems in my previous comment. My apologies for my delay in doing so.
I like comments #15 about bringing up a large code bas, and #22: "to have both the wrappered system control and a lightweight Java one." For example some day Eclipse might render a Javadoc snippet in HTML into the editor. Bringing up IE is too much. Besides the fact that it takes it's time and and some memory, it's too dangerous. Eclipse.org has no control over the options that a Windows user might have selected in her "Control Panel" nor in new features that might make IR break Eclipse. In usability newsgroups discusions about using the browser (mainly IE) as an application front-end there are numerous postings about how to control it. For example developers can hide the back button but users are still allowed to <alt><left> to move to the former content. The "browser control" is not such in Windows. It's just a thin sloppy wrapper around the whole browser. Not the engine (like Gecko, for example) but the while thing. Also, I've read that MS is freezing MSIE. No more versions after 6. It will be integrated into the OS in the (rather near) future. In short, my two thoughs (one cent each): + it makes sense to have two renderers, the light one and the full one + to bring up MSIE is like to walk into the bear's home
When you think of using Eclipse as Rich Client Platform, there are many uses, where the interface requires lots of boring form entries. Coding forms with widgets even with a gui builder is boring and tiring, and requires a lot of feed back cycles to the end users. Coding forms in HTML/CSS is fast, easy, gives good results and can be done by business departments instead of IT. But we all know the disadvantages of HTML Guis in respect of interactivity and server round trips, leaving as better alternative Rich Clients. But I imagine a combination of the advantages of widgets and HTML as a HTML widget, where form input fields would react like normal widgets. For a form like <form action="" method="get" name="myform"> <input type="text" name="interestrate"/> </form> I would imagine something like myHTMLwidget.setContent(getClass.getRessourceAsStream("interestrates.html"); .. org.eclipse.swt.widgets.Text interestrate = myHTMLwidget.getform("myform").getTextField("interestrate"); interestrate.addModifyListener(myModifyListener); I think these functionality requires reaching deep into the HTML engine, so it would not work with IE, but would require HTML widget written from scratch or the usage of an open source engine like gecko or safari. Being able to use Eclipse as Rich Client Platform with the ability to build a rich gui based on HTML could be an important argument in favour of using Eclipse for business application front ends.
Well, your argument that providing a handy solution for creating forms is a good idea sounds fair. But using html as the solution for that? This seems like complete nonsense to me. Why use an external technology if SWT provides all sorts of options with the current widget set for building a form API?
Firstly, if there is an HTML widget, HTML is no external technology any more. So, why not use the HTML widget to its best? Secondly, everybody and their dog know how to program HTML, some even know, how to make pretty guis ;-) So, why not reuse this knowledge? And I do think, that coding HTML forms is easier than fighting with layouters. As I stated above, with being able to describe forms in HTML makes it possible, that even business people can prototype a gui, which is import for a business software production process.
Concerning programming in HTML, it seems Microsoft had analogue thoughts in filing patent no. 6,662,341 (http://news.zdnet.co.uk/software/developer/0,39020387,39118430,00.htm)
Note in this related article (http://news.com.com/2100-1012_3-5119072.html) that "Microsoft has no current plans to enforce the patent."
Microsoft will change its plans the moment when they can milk money out of the patent, so what kind of security does "no current plans" give? What would really help: Is there prior art? I guess we all would hate it if there was an European and a US version of Eclipse.
The SWT Browser is being introduced in the SWT 3.0 release. The SWT FAQ contains information about this new widget - in particular: What is the SWT Browser widget Describes the mission statement of the Browser widget for the 3.0 release. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#whatisbrowser Which platforms are supported by the SWT Browser? http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#browserplatforms The SWT newsgroup is a good place to get more info. Post 3.0 feature requests can be opened against Platform / SWT.
