Community
Participate
Working Groups
Should be able to open links in IRC chat using the internal or even external browser if we want to roll that way
Opening a link in an external browser shouldn't be a problem since Scott checked in a BrowserHelper class in the org.eclipse.ecf.ui plug-in two months ago. Admittedly, looking at the code, it seems kind of weird to have it in a class, but anyway, that's besides the point. Examining the underlying implementation, the passed in style bits are currently ignored, so ORing in a IWorkbenchBrowserSupport.AS_EDITOR bit isn't going to cut it for internal browser. From poking around, the browser-embedded-as-an-editor and the WebBrowserView view part are internal classes, so touching them will be going against Eclipse API contract guidelines.
Hi Remy, (In reply to comment #1) > Opening a link in an external browser shouldn't be a problem since Scott > checked in a BrowserHelper class in the org.eclipse.ecf.ui plug-in two months > ago. Admittedly, looking at the code, it seems kind of weird to have it in a > class, but anyway, that's besides the point. True enough. I was experimenting. I think it would probably be best just to use the IWorkbenchBrowserSupport directly rather than using the BrowserHelper class. But I did reorganize things a little so that the BrowserHelper instance can be reused (like the IWebBrowser underneath). Checked in 9/30/2006. > > Examining the underlying implementation, the passed in style bits are currently > ignored, so ORing in a IWorkbenchBrowserSupport.AS_EDITOR bit isn't going to > cut it for internal browser. From poking around, the > browser-embedded-as-an-editor and the WebBrowserView view part are internal > classes, so touching them will be going against Eclipse API contract > guidelines. Hmmm. Wonder if this changes/is added in 3.3M? Why is it necessary that it be an editor?
(In reply to comment #2 > Hmmm. Wonder if this changes/is added in 3.3M? I hope so, unless there is some specific UI guidelines that prevents it from being public? Although that sounds unlikely since I can think of many plug-in devs that may want to open up the internal browser. Maybe it has to do with the fact that it is a singleton view right now and opening a link will override the last link and force the user to use the back button? > Why is it necessary that it be an editor? Well, it's certainly not a requirement, I personally would want it in the editor view, but some might want it to open up as a ViewPart. But since both the editor and the view implementation is internal at the moment, we're stuck either way.
Okay, my claims from comment #1 about ignored style bits are actually incorrect. If you pass in AS_VIEW or AS_EDITOR it actually does work (because the returned implementation was actually not the implementation I was looking at due to extension points). However, if a user has his preferences set to 'Use external Web browser' under General -> Web Browsers, it's going to be ignored. There are no ways to force the opening of the internal browser like there is to force the opening of an external browser (with AS_EXTERNAL). So I think what we need to do here is to add a preference for selecting whether the link should be opened with the browser view, editor, or the external one along with a note indicating that if their browser preferences are set to use the external one, the selected radio button on the ECF IRC preference page will be ignored. I have opened up bug #166019 requesting the addition of some kind of AS_VIEW_FORCE and AS_EDITOR_FORCE style bit.
The preference page isn't in place but the link detection code is there for 'http://', 'https://', and 'www.'.
Preference page added to CVS HEAD in org.eclipse.ecf.ui. Marking as FIXED.
