Community
Participate
Working Groups
According to #152775/#46549 Instead of HTMLTextPresenter, an implementation with SWT Browser widget should be used. An existing implementation is BrowserInformationControl. Please make it available as API, so that there is an information control for HTML.
*** Bug 226589 has been marked as a duplicate of this bug. ***
Is there any chance to see this implemented (sooner than later)?
(In reply to Vlad Dumitrescu from comment #2) > Is there any chance to see this implemented (sooner than later)? Yes, if a high quality patch would be uploaded to Gerrit. See https://wiki.eclipse.org/Platform_UI/How_to_Contribute.
Ok, I will try to provide a patch. However, since these are API changes, I need guidance for how to handle it. * The simple approach is to move the classes from o.e.jface.internal.text.html to o.e.jface.text.html and make the package available as API. But the internal classes are used even externally, most prominently by JDT - is it ok to force these projects to update their references? * The package contains even a few utility classes, mainly HTMLPrinter. These are not strictly necessary to be made API, but they are useful helpers. Should these classes be made API too? My first reaction is "no", but it's better to ask.
Regarding backwards compatibility: adding API is only requiring changing the minor version, but my guess is that other bundles depend on o.e.jface.text [3.8,4.0), which means that they will get errors if only the new 3.12 is available... I am trying to find an example where classes were promoted to API, to see how it was handled there, but couldn't find any yet.
New Gerrit change created: https://git.eclipse.org/r/88543
I deprecated the existing classes and published copies as API.
New Gerrit change created: https://git.eclipse.org/r/88544
Since the classes become API, must tests be implemented?
(In reply to Vlad Dumitrescu from comment #9) > Since the classes become API, must tests be implemented? Sure, sorry not to mention this earlier. Please check if there are already tests for this (who knows) and if they can / need to be improved. I must confess I haven't looked at the patch itself yet and I'm not familiar with the particular code yet.
As per the request in the Gerrit review, I tried to check how much is the internal API used. It is difficult to import all Eclipse projects, but at least JDT and PDE use it. A search on Github finds ~1000 files mentioning the BrowserInformationControl class name. I'm not sure if all forks of a project, but I'd say it's at least 100 projects. Deprecating the old class is the right way to go, and it should be removed maybe next year.
Writing an API is never as easy as copy some internal code ;-). It needs to be well designed. Take a look at some of the presentations under 'Useful links' on https://wiki.eclipse.org/Eclipse/API_Central Yes, the old classes must be kept. As you correctly noticed, many clients are using it. Best would be if the old ones can inherit or wrap the new ones. That way we only have to apply fixes on the new ones. Since the old classes are used heavily, you also need to put a note into the migration guide. Deletion can happen in the release after Oxygen. I think most of the helper classes are needed. Some are e.g. needed in case the Browser widget is not available and StyledText is used.
Thanks Dani, I know that APIs are not easy, I started with the easiest thing to get the discussion started. I will need a lot of feedback. Do you know when the API freeze for 4.7 is?
(In reply to Vlad Dumitrescu from comment #13) > Thanks Dani, I know that APIs are not easy, I started with the easiest thing > to get the discussion started. I will need a lot of feedback. > > Do you know when the API freeze for 4.7 is? March 10.
(In reply to Dani Megert from comment #12) > Writing an API is never as easy as copy some internal code ;-). It needs to > be well designed. Take a look at some of the presentations under 'Useful > links' on https://wiki.eclipse.org/Eclipse/API_Central The old classes were internal, but their relatively large usage makes them "almost API". I think it would make sense to change what we have as little as possible. Actually, the important parts for BrowserInformationControl are already API via the base classes and implemented interfaces. Extra public API is: - addInputChangeListener: I see no problem here - removeInputChangeListener: no problem here - hasDelayedInputChangeListener: no problem here - notifyDelayedInputChange: does it need to be public? - getInput: - addLocationListener: is a removeLocationListener needed? BrowserInformationControlInput and BrowserInput are new. BrowserInput could be named more generic, as it doesn't have any browser specific content, it just keeps track of the history of the inputs. BrowserInformationControlInput has as API: - getHtml: clients must provide implementation - getLeadingImageWidth
Does anyone have any feedback regarding the API? Is the existing one more or less ok?
(In reply to Dani Megert from comment #12) > Best would be if the old ones can inherit or wrap the new ones. That way we > only have to apply fixes on the new ones. Looks like this isn't working, the last version of the patch just deprecated the old classes. > Deletion can happen in the release after Oxygen. Too late now for Oxygen. See also http://codeandme.blogspot.de/2017/03/fancy-tooltips.html Quote: Even if the BrowserControl becomes public API (which would be nice) we have still a way to go: * all the hover classes still just work for editors and need rework * the nice StyleSheet from JDT does not seem to be part of the package * it is still part of the wrong package: jface.text seems to be an odd dependency for simple views. Why not move to org.eclipse.ui, o.e.swt or o.e.jface ? That would be nicer candidates for a generic Browser Control.
Yes, I know it's too late now, there wasn't enough feedback. There are of course many things that can be done to improve the situation, but I thought to take one small step at a time. This makes it easier to accept, but slower to get into a release. Now that we have a full year to plan, we can consider a bigger change.
By chance Andrey made me aware of this bug. I just finished a feature that allows to use text editor help hovers on any SWt control. A short intro can be found here: http://codeandme.blogspot.co.at/2017/03/fancy-tooltips.html The main parts there were to detangle hover tooltips from editor stuff and to move internal classes (like the BrowserInformationControl) to a more prominent place. Currently my implementation is hosted within the EASE framework. Would it make sense to move it to the platform somewhere? I am asking as jface.text would not seem to be the right place from my point of view. The browser would rather belong to jfact/swt/platform.ui, same counts for the hovers. Eventually having generic classes for Browser and hovers there would allow to keep the jface.text classes and let them inherit from a base implementation. Is there interest that I push a proposal? Where would it go to?
FWIIW, I'm all for a full revamp.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
I'm back on this topic. I think we need to rediscuss a bit the API if we want to make it more official. Here are the API of the BrowserInformationContol that are "added" (ie public or protected and not inherited): * BrowserInformationControl implements IDelayedInputChangeProvider * public static boolean isAvailable(Composite parent) * the constructors all add a "symbolicFontName" parameter * public void addLocationListener(LocationListener listener) * public void addInputChangeListener(IInputChangedListener inputChangeListener) * public void removeInputChangeListener(IInputChangedListener inputChangeListener) * public boolean hasDelayedInputChangeListener() * public void notifyDelayedInputChange(Object newInput) * public BrowserInformationControlInput getInput() Before making it API, I think we need to build a case to support any of this addition as API, with the goal of minimizing the APIs while still offering something that can be used. Then, the older types can be marked as extending the new API types, have their content removed as much as possible and be deprecated, that will allow an easier migration.
