Community
Participate
Working Groups
Provide an implementation of the new SWT browser widget for the QNX platform. Stubs: The org.eclipse.swt source from HEAD contains stubs for the Browser widget on Photon. Source folders: Eclipse SWT Browser/photon (org.eclipse.swt.browser.Browser for photon - to be implemented) Eclipse SWT Browser/common (events which must be supported by the Browser widget) 1. report if part of the Browser api and events don't map to the Photon platform 2. for early feedback, you can post a (temporary) simplified version of the Browser which does not support the events. 3. The final implementation can be tested against the following snippet: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/snippits/snippet128.html
Created attachment 6163 [details] Browser Patch This patch has a browser that is fully functional against the current contract.
Browser released in CVS. After review of the patch, you can notice a few modifications: - WebClient is merged into the Browser class - Rely on Display.findWidget instead of own hashtable - Removed unused setWebOption - Use single callback following a scheme similar to Display/Widget/Control - Inlined some code in server initialization - Some checks for back() and forward() 1 question: is the code inside focusIn doing anything? I didn't see a difference when commenting it out.
Some comments on your changes: o The WWW_* stuff has been replaced with Pt_WEB_*. It might not be in your headers but that it what it is called now and the WWW_* counterparts are not even listed. Please change it back. o The setWebOptions() will have to go back since there are a bunch of options that need to be configured with a little more sanity. For instance, you will find in your $HOME dir a bunch of files like globhist.html, etc, etc. Based on server we can either point into an swt specific location or into voyager's locations. Some questions: o Why do you use the Listener() object rather then implimenting the interfaces? I assume that Browser isn't subclass-able so it really shouldn't matter should it? I must be missing something. ;) o Why do you use the .* for importing? (this one is really troubling to me) Everything I have ever read on good java coding practice says you should list them explicitly to avoid polluting the namespace. Some Answers: o The onFocus() code is in place because the Browser isn't really the widget, unlike if we could take over createHandle(). So if someone did a setFocus(true) on a browser instance it would be setting focus to the composite parent rather then the PtWebClient widget.
o Why do you use the Listener() object rather then implimenting the interfaces? I assume that Browser isn't subclass-able so it really shouldn't matter should it? I must be missing something. ;) For consistency with the CTabFolder that I used as a reference for coding the Browser. o Why do you use the .* for importing? (this one is really troubling to me) Everything I have ever read on good java coding practice says you should list them explicitly to avoid polluting the namespace. Consistency with what SWT usually does (see CTabFolder, Button for example). Noted: we need to look at the constants you mentionned
