Community
Participate
Working Groups
R3.0 I tried to use IBrowserFactory and IBrowser which are public API but I did not find any public factory which would create me a browser. I think the bunch of code is quite useful for others which want to show some link in a browser. Did I miss something? What I currently do for demoing a new feature (allow click on URLs in an editor and then open the browser) is: 1. I create a new LaunchURL 2. I create an anonymous inner subtype of IConfigurationElement (which is against the spec) which returns my URL if asked for attribute "url" 3. I init the launchUrl with this guy 4. I call run(null)
IBrowserFactory and IBrowser are old APIs for extending help system, by providing additional browser adapters over what implemented in help. One is expected to implement these interfaces and contribute to help system, for example on additional platforms. Help system does not expose instances of the browsers that it uses through any public API. Can't you use org.eclipse.swt.browser.Browser? What are you trying to display?
I want to display a URL in a browser (if installed) but I do not want to provide my own browser view which is needed if using the SWT Browser widget. I would have expected to use the browser defined by the user via Help preferences to show my URL.
I do not think help should provide browser components to other. It should rather be the UI. Help has some code for launching external browsers that can be donated to UI if useful.
Now that this ended up in Platform UI land I adapt the summary: what's really needed is API (and preferences) to define with which application I *view* certain content types. Currently I can only configure editors (for files).
Actually comment 4 is a separate PR (see bug 71225). This bug is about providing API to show an URL. NOTE: PDE UI and Update UI already use the internal API from Help UI and JDT UI would be the third customer.
As a workaround I am now using: Program program= Program.findProgram("html"); if (program == null) program= Program.findProgram("htm"); if (program != null) program.execute(fURLString); which currently doesn't fully work due to SWT bug 71228, bug 71231 and bug 71234.
So to summarize, the request is for: 1) API to configure which "view" (or editor?) to use to view certain content types (as defined by Core perhaps) See comment #4 , and bug 71225 - obviously you could then configure for htm and html content types here - need to consider configuring external programs here too. 2) Consider implementing a generic Browser view to replace the duplicated ones we currently have. Help, JDT, PDE? JavaDoc view? Sounds like we could consider beefing up our file association page to be more generic and include views+editors+external programs, AND use Core content types underneath. Adding Doug and Rafael as well as we have had some similar conversations. I think we will need some new dynamic support from Core for this as well so we can add content types
For 1) I explicitly filed bug 71225 and hence this is no longer part of this one. This bug is now only about having API and UI to show URLs (and maybe HTML content). I now use SWT API (see comment 6) to open an external browser. What I was hoping for is that there's a preference like the one from Help UI where the user can define how to view/open an URL (use Eclipse's browser - if we have one, open external browser, define external browser). Either Help UI stuff could be pushed down or being replaced by the beefed up file association page mentioned in comment 7. I'm not sure whether I would replace the Javadoc view with that approach since the Javadoc view offers additional actions which get lost if the users chooses an external browser.
I reopened bug 57908 to handle the issue on user-driven content type additions. Feel free to mark this one as depending on it.
See also bug 73001 .
As funny as it may seem right now, I actually suggest that we keep duplicating for a little while. While we seem to agree that we need this functionality, everybody as a subtle slant on the actual requirements: some need a browser in a view, some in an editor. Some want all the works (the address field, favorites etc.), some want just the rudimentary controls (which is also a valid scenario in cases where the URL is not important). In addition, the support needs to conform to Eclipse high API standards i.e. needs to go through a number of iterations before we freeze it. Since we are about to start building milestone 4, I think we missed the 3.1 boat for this. What can we do in the mean time: 1) For showing a URL on all the platforms (where embedded browser is not working), use Help support (even if it not API). 2) For simple cases, just instantiate SWT browser widget (Forward and Backward icons are shared by the workbench so you don't need to duplicate). Eventually we should all use one common support, but I don't think we have a clear understanding what all the requirements are, and we can only figure them out when we build separate solutions and then try to spec out a common support that will allow us all to move to it without loss of function.
Who needs a browser in a view? Web pages are documents, seems like a classic editor use case. The problem with not pushing down the browser is that it runs the risk of becoming API over in WTP and maybe other places, which would be unfortunate. Can't we just start with something simple (e.g., PlatformUI.showUrl(String url)) and add options to customize it (remove address bar, etc.) later if necessary?
>Who needs a browser in a view? As an example take the Javadoc view.
not all the use cases show classic web pages. Some pages are really UI parts composed using HTML. You don't want to show the URL (as a matter of fact, you may not even have it - you may compose HTML on the fly and feed the browser widget). Essentially we need to pull all out requirements and carefully craft an API that will be flexible and serve as longer than a stop-gap measure would.
Ok, but note that simple cases like Javadoc in a view are already covered by the SWT Browser widget (as per point number 2 in comment #11). They don't need a new API.
making Dejan the owner has he is doing the implementation
see proposal here: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/browser-proposal/index.htm
There is already a Web browser in the WTP project. Are you aware of this browser and are you working with the developers in WTP that work on it?
They are; Tim Deboer is a co-author.
I read the proposal, have some comments: 1. Using this interface how would I do this? "Open a browser on http://www.eclipse.org as an editor. If there is already a browser open on that page, just pop it to the top, otherwise create a new editor window and go to that page" 2. Using this interface how would I do this? "Open an external browser on some url using the default system browser, whatever that is". 3. Using this how would I execute Javascript in the browser or access the Dom? 4. I'm not sure I like the FORCE flag because you're explicitly ignoring something the user told you to do. If the programmer needs a browser embedded somewhere they can always use the Browser widget. 5. I'd like to see more than one implementation of browserSupport. I really don't like extension points that can only have one extension, and I think the community would have fun supplying those. I was thinking the preference page for Installed Web Browsers would list all the extensions for browserSupport rather than some seperate xml file. So the extension point would need a human readable name and description in it. 6. Also I'd like to hear an answer for comment #15.
(In reply to comment #20) > I read the proposal, have some comments: > 1. Using this interface how would I do this? "Open a browser on > http://www.eclipse.org as an editor. If there is already a browser open on that > page, just pop it to the top, otherwise create a new editor window and go to > that page" PlatformUI.getWorkbench().getWorkbenchBrowserSupport().createBrowser (AS_EDITOR, "myId", null, null).openURL("http://www.eclipse.org"); > 2. Using this interface how would I do this? "Open an external browser on some > url using the default system browser, whatever that is". PlatformUI.getWorkbench().getBrowserSupport().createBrowser (AS_EXTERNAL, "myId", null, null).openURL(url); > 3. Using this how would I execute Javascript in the browser or access the Dom? Right now, we don't support this because we cannot guarantee access to the Dom for external browsers. We can give you an API to get directly to the browser widget from IWebBrowser interface, but you must be prepared to handle null if the instance handles external browser. > 4. I'm not sure I like the FORCE flag because you're explicitly ignoring > something the user told you to do. If the programmer needs a browser embedded > somewhere they can always use the Browser widget. FORCE is a controversial flag that we are not sure about - it may not survive particularly if it looses the popular vote. > 5. I'd like to see more than one implementation of browserSupport. I really > don't like extension points that can only have one extension, and I think the > community would have fun supplying those. I was thinking the preference page for > Installed Web Browsers would list all the extensions for browserSupport rather > than some seperate xml file. So the extension point would need a human readable > name and description in it. I respectfully disagree :-). I think this is overkill because it adds another dimension to something that should be fairly straightforward. I don't think users should be required to choose between browser supports (even know about it). Browser support concept is for ISVs - we offer a common interface so that you don't have to worry about implementation details similar to the help system. However (again similar to the help system), I don't see a case for more than one at a time. I can see RCPs wanting to roll their own, but I just cannot see RCPs who cannot make up their minds so they must ask the user to choose for them. One thing we can do is add the 'default' attribute. This will allow us to mark the extention contributed by org.eclipse.ui.browser as default, allowing plug- ins to override it by one that has 'default=false'. This mechanism is used to allow ISVs to override the webapp server. Again, you can only have one webapp sever at a time. > 6. Also I'd like to hear an answer for comment #15. We have added AS_VIEW option to allow ISVs to show URLs as auxiliary information that assists the main work area (as opposed to showing them as editors that covers the work area). We are also providing BrowserViewer that with the JFace-like value add that can be used as any other viewer (we will use the viewer ourselves for AS_VIEW and AS_EDITOR styles). We don't plan to cover all the cases where Browser widget will be used, particularly if a tight control over the browser widget is needed. BrowserViewer will provide fallback support for cases where Browser widget fails to create.
Note that if you don't use FORCE in the first example, and the user configured browser support to use the system browser, 'AS_EDITOR' will be ignored and external browser will open.
(In reply to comment #21) Dejan, for the force flag, I see value add. For example, regardless of what the user set his preferences, SDK Help -> About Eclipse -> license will always want to open an external browser. Plus, if I set the preference that I want the internal browser and Im on a platform that does not support SWT browser, we still will popup the external no?
I think we can do without FORCE to begin with. Here are the situations to me: 0) The user does not know about view or editor style browsers, they just pick their favorite browser from a list (internal, external#1, external#2...) 1) When I am just a plug-in (like help OR help > about) opening an URL in a browser I will obey what the user has asked for, i.e. when I say open in a browser I get the users choice of browser, I don't care whether it is internal or external. Maybe AS_EXTERNAL should be changed to AS_DEFAULT or something 2) when I am a plug-ing developer opening a browser that I know I want in a view or editor I say that is what I want and that is what the API should provide if it can support me, if not it should fall back to the next best thing.
(In reply to comment #24) > I think we can do without FORCE to begin with. Here are the situations to me: > 0) The user does not know about view or editor style browsers, they just pick > their favorite browser from a list (internal, external#1, external#2...) > 1) When I am just a plug-in (like help OR help > about) opening an URL in a > browser I will obey what the user has asked for, i.e. when I say open in a > browser I get the users choice of browser, I don't care whether it is internal > or external. Maybe AS_EXTERNAL should be changed to AS_DEFAULT or something but isnt that bad? Yes, as a user I told you to use the internal browser, but when it males sense, no? The help -> about -> license will be showed to me behind the dialog no? (assuming I chose the internal browser). Is that what we want? AS_EXTERNAL has value add. For instance, I can see a very minimal RCP app that only needs to show an external browser on a tree of docs, and it only needs an external brwoser, ever. My app is very small and I dont even want an editor or view.
Speaking of users choosing browsers, on most platforms the user has already chosen a default external browser yet Eclipse doesn't honor that choice. E.g., on Windows XP Eclipse opens .html files in IE even though Mozilla is the system-wide default. This should be fixed. I find AS_DEFAULT confusing, like it is going to override the user's browser selection. Plus, I agree that the option to force an external (or internal) editor should be there. For one thing, it is in the UI. Open With > External editor. An RCP app shouldn't have to code around your API to do it. I have to say that the proposed API doesn't look like the simplest thing that could possibly work. Sure, a plug-in or application should be able to open a browser in a view. In fact, they already can. The only real value-add is to supply a workbench standard view, with a well-known name, etc., for the purpose. Not sure that is worth the fuss, but ok. Why would a user want to open a browser in an editor unless they can edit in it. You want a tabbed browser view, and since the editor uses tabs you use the editor view? The platform should be moving away from rigid control over the way editors are presented, not piggy-backing on the current, rather unfortunate, behavior.
When we worked on the API, we were trying to make it as simple as possible, but not simpler. For one, it is an evolution of the code in WFT that has already been used on products. In addition, simple is good but very soon you are faced with issues like browser reuse, persistance etc. that you will need to handle. Therefore, we beleive the proposed API is the simplest possible that still handles these problems that you will otherwise need to address yourself. Very simple APIs are great for demos and first steps, but any reasonable Eclipse app soon needs more. It is true that the current API reflects the distinction between editors and views in Eclipse that is becoming controversial. We will keep the API up to date as the architecture evolves but it must work right now, not at some unknown point in the future when the line between editors and views is blurred. Note that AS_VIEW and AS_EDITOR are style hints that may not be honored. The contract already flags them as hints and they can easily be deprecated in the future and replaced with AS_EDITORVIEW becomes a reality.
As shown in the example above, the simplest way to use the support would be: PlatformUI.getWorkbench().getBrowserSupport().createBrowser("myId").openURL (url); I admit that the statement is somewhat long but you can easily create a static method somewhere in your code to do something like: public static void openURL(String url) { PlatformUI.getWorkbench().getBrowserSupport().createBrowser(MY_ID).openURL (url); } Others may choose to cache the browser instance they create and call 'openURL' on it instead. They may also elect to close this instance when they don't need it any more etc etc. It is hard to please all people :-).
There should be a link back to the proposal in this bug: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/browser-proposal/index.htm
Questions in no particular order: - The first two paragraphs in the javadoc for IWorkbenchBrowserSupport seem at odds. If all you can do is open an external browser window, do you really expect to be able to keep a handle on it so that window can be reused? If you can't, does an attempt to reuse the browser object just open a new window anyway? - Your example is different than the javadoc. Is createBrowser() no longer a static method? - A browser is rather unlike an Eclipse editor. E.g., in every embedded browser app I've seen, the native browser controls the context menu. - If the user right-clicks a link in an internal browser and selects Open In New Window, what happens? Does the link open internal or external? Is there a different answer for view vs. editor? - Is it a good idea (IWebBrowser) to throw PartInitException for a normal behavior, i.e., being unable to control the reuse of an external browser window. - Why must browser support implement AbstractWorkbenchBrowserSupport instead of IWorkbenchBrowserSupport? What are you trying to restrict? - I'm pretty sure that browser support will be in a separate plug-in, not tucked away in workbench ui? In the same vein, there won't be any internal typecasting going on in the other workbench users that assume the default implementation? - The piece parts of this feature, the new view, the editor support for URLs, should be in a separate plug-in from that which specifies the implementation for the app. Otherwise, other implementations won't be able to use these pieces (unless they hack the manifest). - What does this mean: "Internal web browser will not be editable because the assumption is that clients who create internal web browsers know best how to configure them"? What isn't editable? (It strikes me as a sort of Father Knows Best, esp. as it is written by the implementors of the default support. ;) - If the ability to FORCE internal/external open is retained (as it should be) the preferences GUI isn't adequate. Even if it is preferred to open internal, shouldn't there still be a way for the user to select which browser will be used if external is forced? - Shouldn't there be a way to select the system-default external browser separate from just naming one? I.e., shouldn't there be a way for Eclipse to just ride along with whatever browser is the system default at the moment without the user having to set some preference in Eclipse? - Given the above, shouldn't the default preferences be Internal Web Browser checked _and_ System Default External Browser checked? Thanks for listening.
I just noticed, those are checkboxes in the preferences dialog, not radio buttons. What happens if the user checks them all?
Bob, there is already a link to the proposal in comment 17. (In reply to comment #30) > Questions in no particular order: If all you can do is open an external browser window, do you really expect > to be able to keep a handle on it so that window can be reused? If you can't, > does an attempt to reuse the browser object just open a new window anyway? Depending on the platform, it may is possible to reuse the external window. > - Your example is different than the javadoc. Is createBrowser() no longer a > static method? createBrowser() is a method on IWorkbenchBrowserSupport interface, not a static method. > - A browser is rather unlike an Eclipse editor. E.g., in every embedded browser > app I've seen, the native browser controls the context menu. > - If the user right-clicks a link in an internal browser and selects Open In New > Window, what happens? Does the link open internal or external? Is there a > different answer for view vs. editor? If 'Open In New Window' is selected in an editor, it will open another editor instance. If opened in the view, it will open in the default external browser. > - Is it a good idea (IWebBrowser) to throw PartInitException for a normal > behavior, i.e., being unable to control the reuse of an external browser window. PartInitException will only be thrown for abnormal behaviour. Inability to reuse will not cause it - we will simply open another browser instance. > - Why must browser support implement AbstractWorkbenchBrowserSupport instead of > IWorkbenchBrowserSupport? What are you trying to restrict? We are trying to make future expansion easier. If we ask the user to implement an interface, adding a method will break all the implementations. Adding a method in the abstract class will not. This is analogous to Help UI. > - I'm pretty sure that browser support will be in a separate plug-in, not tucked > away in workbench ui? In the same vein, there won't be any internal typecasting > going on in the other workbench users that assume the default implementation? Reference implementation will be in a separate plug-in. Minimal implementation will be in workbench ui to support bare-bones RCP. > - The piece parts of this feature, the new view, the editor support for URLs, > should be in a separate plug-in from that which specifies the implementation for > the app. Otherwise, other implementations won't be able to use these pieces > (unless they hack the manifest). They will be (org.eclipse.ui.browser). > - What does this mean: "Internal web browser will not be editable because the > assumption is that clients who create internal web browsers know best how to > configure them"? What isn't editable? (It strikes me as a sort of Father Knows > Best, esp. as it is written by the implementors of the default support. ;) We assume that clients who explicitly request AS_EDITOR or AS_VIEW also know best whether the browser instance should have a nav bar, an address bar, or a status support. This is not unlike special windows opened from web applications that are configured in a special way (window not resizable, no tool bar, no address bar etc.). If the client said that he/she does not want the status line, we don't think that end-users should override it and turn it on from the preferences. > - If the ability to FORCE internal/external open is retained (as it should be) > the preferences GUI isn't adequate. Even if it is preferred to open internal, > shouldn't there still be a way for the user to select which browser will be used > if external is forced? The provided preference UI will be slightly different. There will be a radio button to choose between internal and external browser. External browsers will be listed (as they are now) with the ability to check the preferred external browser. Therefore, even though internal radio is checked, preferred external browser to use will still be defined when AS_EXTERNAL is forced by the client. > - Shouldn't there be a way to select the system-default external browser > separate from just naming one? I.e., shouldn't there be a way for Eclipse to > just ride along with whatever browser is the system default at the moment > without the user having to set some preference in Eclipse? There is no platform-indenendent way to find out what the system-default external browser is. We can try to determine it and select it as the default but we cannot guarantee it. > - Given the above, shouldn't the default preferences be Internal Web Browser > checked _and_ System Default External Browser checked? > Thanks for listening. See above.
(In reply to comment #31) > I just noticed, those are checkboxes in the preferences dialog, not radio > buttons. What happens if the user checks them all? Similar to picking a JRE in Java preferences, only one can be checked at a time. This is really a hack since we don't have radio table widget (as opposed to checkbox table widget).
Along with the current discussion are there any plans to push the SWT Browser out of the SWT base implementation. One thing that might be relevant here is the support for different INTERNAL browsers. For example using Mozilla as the base for Windows. Or pointing to specific version of Mozilla in other platforms. Our initial contribution of SWT Browser was based on a factory model however because of how SWT Widgets are implemented only one type of Browser Widget could be supported per platform.
It is probably better to bring this topic up to the SWT team in a different bugzilla entry (you can add a bug number here for reference). When we say 'internal', what we mean is exclusively SWT Browser widget. We will support different native implementations per platform when SWT does it.
Thanks for clearing those up. A couple of lingering questions: > Bob, there is already a link to the proposal in comment 17. Sure is. I should have searched instead of eyeballing for it. Sorry. >> If all you can do is open an external browser window, do you really expect >>to be able to keep a handle on it so that window can be reused? If you can't, >>does an attempt to reuse the browser object just open a new window anyway? > > Depending on the platform, it may is possible to reuse the external window. Yes. If it isn't, you just open a new window anyway? >>- A browser is rather unlike an Eclipse editor. E.g., in every embedded >> browser app I've seen, the native browser controls the context menu. I didn't ask a question, so of course you didn't answer it. I assume the answer is the native browser controls the context menu? You control the UI _outside_ the browser widget? > We are trying to make future expansion easier. If we ask the user to implement > an interface, adding a method will break all the implementations. Adding a > method in the abstract class will not. This is analogous to Help UI. Ok. I guess I'll wait to see if the implementation is enabling or controlling. ;-} >>- What does this mean: "Internal web browser will not be editable because the >>assumption is that clients who create internal web browsers know best how to >>configure them"? > > ...If the client said that he/she does not want > the status line, we don't think that end-users should override it > and turn it on from the preferences. Ah. Suggestion: "The appearance of the internal web browser will not be user-configurable in preferences." > There is no platform-indenendent way to find out what the system-default > external browser is. We can try to determine it and select it as the default > but we cannot guarantee it. Hmmm. I still think there should be a separate choice for Platform Default External Browser. Gray it out if it's absolutely impossible on the platform. One reason is, on many platform, you can get a different answer for a different, e.g., file: URL. The default may not even be a browser. For files, you probably want to open them as files. Bob
> Similar to picking a JRE in Java preferences, only one can be checked > at a time. This is really a hack since we don't have radio table > widget (as opposed to checkbox table widget). Ouch. Should fix that. ScrolledComposite.
> > Depending on the platform, it may is possible to reuse the external window. > Yes. If it isn't, you just open a new window anyway? Yes. > is the native browser controls the context menu? You control the UI _outside_ > the browser widget? Yes. I think you can turn the pop-up menu off and register your own, but I don't think that would be the right thing to do by default. If you need that kind of control over the browser, you probably want to use BrowserViewer. > Ah. Suggestion: "The appearance of the internal web browser will not be > user-configurable in preferences." Yes :-). > One reason is, on many platform, you can get a different answer > for a different, e.g., file: URL. The default may not even be a browser. For > files, you probably want to open them as files. We will tweak this area further and see what can be done.
Created attachment 19084 [details] Browser support implementation for the workbench plug-in
Created attachment 19086 [details] Eclipse UI patch - extension point and schema declaration
"There is no platform-indenendent way to find out what the system-default external browser is" I don't think you need to know what it is, you just need to invoke it, like a system editor on any arbitrary file, right? If you were in a command shell you'd use the "start foo.html" command. I don't want to have to set the default browser in Windows and set it again in Eclipse. Is there a default id that can be used if I don't want to make up one, and I want to use a shared browser?
Initial code dropped to CVS. We'll be cleaning it up further and responding to feedback, but the basic support is now available.
Quick poll: we want to make sharing one default browser easy for people that just want to show URL with a minimal fuss. We can: 1) Make a shared browser ID public API (DEFAULT_BROWSER_ID) to pass in 'createBrowser' 2) Add an API 'getDefaultBrowser()' 3) Add an API 'showURL(URL)' that creates the shared browser if not created and opens URL on it. All of the options will yield the same result. Which one you think is best?
1. This makes the choice explicit and allows the possibility of someday adding another globally-known id without requiring further API. I'm missing something about 3. Is it just syntactic sugar for something like createBrowser(id).open(URL) (with the deficiency that it allows no choice of browser)? The point is what, shorter lines?
+1 for option 1 ... add a DEFAULT_BROWSER_ID
Dejan, is the requirement the following: "allow clients to quickly/easily show a URL, based on workbench browser preferences, and share the instance" ? if it is, then it might be dangerous, no? if there are two clients that use this api, and the workbench brwoser support is configured to use an editor, you now have two clients fighting in turn to show a url in the editor. no? did I miss somthing? I might have designed my client to use this new openURL() and wanted the content of the editor or view to not be overwritten.
Mazan I suggest that if you did not want it overridden then you should use your own ID and create your own browser. agree?
fair enough, but the apis should document clearly that another client of the support can override the current page by a similar call. I would vote for calling the api "getDefaultBrowser" only because I dont like to think. :-) If Im going to look for a platform api constant, I might as well use my own. (but it wouldnt kill me, so option one is also dowable. Dejan, is the api to show a page still openUrl()? did you intentially call option 3 showUrl()? my 2cents here is that we should use showUrl() as the api name. openUrl has the connatation that I am "opening" an external browser. "showUrl" has the connatation that Im showing at the leisure of the platform. Intro already uses openBrowser as an api to open an external browser.
+1 for 1) Make a shared browser ID public API (DEFAULT_BROWSER_ID) to pass in 'createBrowser'
The usage in update/install is to show license, copyright, or more info for a feature. This usually means launching an exernal browser. All the proposed choices in comment #43 look fine, as long as the above behavior can be achieved.
The mob has spoken - option 1) it is :-). Dorian, Update needs will be supported.
Created attachment 19187 [details] Addition of DEFAULT_BROWSER_ID constant.
constant has been added and committed to HEAD for M6
Is the default browser (DEFAULT_BROWSER_ID) an internal browser, external browser, or what? Can the user control its appearance through preferences or actions (for example turn on/off navigation and status)? Are those settings persistent? Also what was the resolution for using the OS System default browser setting? I still think that's important for opening external browsers (In fact I think it's more important to do that than allow the user to select between external browsers in a preference, at least on Windows).
(In reply to comment #54) > Is the default browser (DEFAULT_BROWSER_ID) an internal browser, external > browser, or what? The constant is there to ensure that if clients want to reuse one browser, they can do so using the shared browser ID. Browser instance created using this ID still behaves as any other instance. This means that whomever was first to create this instance gets to control its style. Others just piggy- back on it. User preferences, persistence etc. are all in effect. If a client does not care, she should use the shared id. Otherwise, it should use its own ID and configure the browser the way she needs. > Also what was the resolution for using the OS System default browser setting? We will be tweaking this behaviour in M7. Since it is not API, we have more runaway to do it right in M7. We wanted to zero on the API for M6.
If that's all it is then I don't see the benefit of DEFAULT_BROWSER_ID being in this API. In fact it will probably come back to haunt you later because it has no meaning except to the client. The client (i.e., whoever is creating the default browser) should provide an API to retrieve the default browser instead. If the client is PlatformUI then something like PlatformUI.getDefaultBrowser(). Or just hide all this browser-support stuff and have something like PlatformUI.showURL(String url) for the simple case as was originally requested. (also note there's a typo in the comment of that last patch)
(In reply to comment #56) > If that's all it is then I don't see the benefit of DEFAULT_BROWSER_ID being in > this API. In fact it will probably come back to haunt you later because it has > no meaning except to the client. In retrospect, I think you are right. I have just ported Update UI to the new API and I realized that I could not say 'use the shared browser but make sure it is external because I am calling you from the wizard dialog'. So I think we should drop the shared constant and instead have the method: IWebBrowser getExternalBrowser(); The contract would be: 1) It will create a shared instance of the external browser. 2) The external browser to use will be subject to the user preferences. 3) The default external browser selected in the preferences will correspond to the system default browser whenever possible 4) If the user changes the external browser preference while the shared external instance is already opened, a new instance will be created and subsequently shared. Hence clients like Update UI would make the following call: PlatformUI.getWorkbench().getBrowserSupport().getExternalBrowser().openURL (url);
Here is the proposed method: /** * Returns a shared instance of the external web browser. Clients * can use it to share one external browser. The external browser that * will be used is subject to browser support implementation. * A suggested implementation is to use the operating system's * default browser. Implementations that offer users a choice of the * web browser should honour the users choice of external browser, with * the initial selection being the system default browser. * * @return the shared instance of the external browser */ IWebBrowser getExternalBrowser();
Created attachment 19197 [details] The patch with getExternalBrowser()
Ok, now that you have getExternalBrowser() I want a method like this: /** * Returns a shared instance of the internal web browser. Clients * can use it to share one default internal browser. The browser that * will be used is subject to browser support implementation. * A suggested implementation is to use a browser that appears in * the editor area with standard navigation controls. * * @return the shared instance of the internal browser */ IWebBrowser getInternalBrowser(); If you double-click on an html file in the Navigator or Package Explorer view it should use this method to open the editor browser on the file unless there's some kind of html editor installed.
Ed, are you not asking that the navigator or package explorer (or the Eclipse SDK) define that the default style for opening files from these views is that of an editor. The implementation does not have to go through a shared default version of the internal browser.
I agree with MVM. The WFT implementation of browser support as additional code that handles IFileEditorInput and register editor as a non-default editor for certain extensions (html, htm etc.). There is a layering issue here because IFileEditorInput is in Eclipse IDE and we wanted org.eclipse.ui.browser to be RCP-friendly.
I was just using Navigator and Package Explorer as examples. I imagine it would also be used by WTP for previewing, for RCP apps that need to view a web page, etc., basically anybody that needed a web page open inside Eclipse and didn't have some special needs for creating a custom browser. Unless there's some reason not to, shouldn't they all share a common look and feel, avoid opening the same web page twice, have similar controls, share a set of preferences, that sort of thing? See bug 73001.
(In reply to comment #62) > I agree with MVM. The WFT implementation of browser support as additional code > that handles IFileEditorInput and register editor as a non-default editor for > certain extensions (html, htm etc.). There is a layering issue here because > IFileEditorInput is in Eclipse IDE and we wanted org.eclipse.ui.browser to be > RCP-friendly. Dejan, are you referring to the workbench ui layer as being RCP friendly? The minimal support from workbench UI is fine. But the browser plugin is not. Did I misunderstand anyone?
> There is a layering issue here because IFileEditorInput is in Eclipse IDE > and we wanted org.eclipse.ui.browser to be RCP-friendly. Big issue! The editorinput should be something like PathEditorInput used in the editor RCP example. If used, PathEditorInput should be API. I believe there's a time problem here.
Plain IEditorInput is not in the IDE. I've used that to store URLs for my own browser editors in RCP apps, actually I think the RCP browser example works that way. The input for the editor wasn't the html itself or a resource, just the URL. But I think I see your point, that you can't have a "browser editor" without an editor input and all that, but doesn't belong in the IWorkbenchBrowserSupport API.
The way to go here would seem to be to define an IURLEditorInput at the workbench level which (analogous to IPathEditorInput) adds one method to return the URL. Then write a default implementation to support the browser.
The reference implementation of IWorkbenchBrowserSupport in org.eclipse.ui.browser is RCP friendly in that it does not make any references to the IDE layer of Eclipse. Note that the proposed support that will appear in M6 has one clear mandate: to allow clients (i.e. plug-ins) to open a URL easily and without worrying about platform and implementation issues. We added the external shared browser instance because external browsers cannot be configured - only shared. With respect to the internal browser, we cannot make a decision for the clients with regards to the style bits (navigation bar, address bar, status, persistent nor not etc.). An application or a family of plug-ins can still achive that by designating one class/API that will be used to open URLs. This API whould use one browserId ensuring sharing. I don't think browser support should perform that task. I checked bug 73001 and I think that it has mostly been satisfied with the current browser support. Note that browser widget is not yet supported on all the os/ws combinations, so applications that critically depend on the ability to show the URL in some way cannot solely relly on the internal browser editor.
I confess I may not have understood what use cases the browser editor is expected to support. I have two questions: 1) I noticed the Web browser editor is not associated to any file names/extensions (or content type). Will it be? 2) If I tried to manually associate the browser editor to *.htm* files, should I be able to get the expected behavior?
(In reply to comment #69) > I confess I may not have understood what use cases the browser editor is > expected to support. I have two questions: > 1) I noticed the Web browser editor is not associated to any file > names/extensions (or content type). Will it be? The main problem we wanted to solve is to provide a central API for showing URLs programmatically from plug-ins irrespective of the support for the Browser widget. In that sense, we didn't put a lot of emphasis on the browser editor. If we associate the editor with any file type, we will be forced to handle IFileEditorInput which we cannot because the support is not in the IDE layer. We will be looking into this next but that was not our main priority. > 2) If I tried to manually associate the browser editor to *.htm* files, should I > be able to get the expected behavior? See above - we cannot correctly handle IFileEditorInput.
Created attachment 19262 [details] Browser JFace Viewer and View that can be bound to editor selection. Hello, I am providing this attachment as an example of both a JFace Viewer wrapper for the SWT Browser widget and A View analogous to the Properties Page View capable of displaying a Pagebook of IBrowserPages. Feel free to use as you see fit.
Closing this defect as fixed and moving browser support into regular maintenance mode. We will handle defects and feature requests as for the rest of platform UI code.
