Community
Participate
Working Groups
1. Open a type hierarchy 2. Double click on a class which is not currently open 3. The editor opens first scrolled to the top of the file -- watch for the *** from the javadoc comment 4. Witness the editor scroll down to the class definition This is a really rapid flash on Windows, and the effect is more visible on Linux-GTK.
code is in OpenActionUtil.open(Object,boolean) moving to jdt-ui.
Actually, there is little we can do here. The current API only allows use to open the editor and then reveal the element. What would be needed is additional API to do this in one call. Alternatively we couldn't reveal the element but I think that would be a real disadvantage. Moving back to text to consider the additional API.
I'm pretty sure that wrapping the whole thing in a setRedraw() would hide the flash.
(In reply to comment #3) > I'm pretty sure that wrapping the whole thing in a setRedraw() would hide the > flash. Yes - but the editor is opened by IDE.openEditor and already there when we set the selection. Fixing this bug would require new API with Platform-UI to allow to open an editor on an initial selection.
Ok. I think the problem has been there since 2.1 so it isn't a regression.
The only thing we could do (besides adding new API, see bug ) is to create a temporary marker, use IDE.openEditor(..., IMarker,...) and delete the marker afterwards but since creating a marker isn't for free I'm reluctant of doing so. In addition we can no longer use JavaEditor.setSelection(IJavaElement) which does some optimization for the Java outline page. Moving to Platform UI to consider adding the new API: IDE.openEditor(...,ISelection,...)
AFAICS, the code in IDE.openEditor(... IMarker) does not (and cannot) perform anything more as long as there is no editor API from our side that allows to set an initial selection.
I see another solution that could work without additional API: - the text editors extract the selection from the editor input via IEditorInput.getAdapter(ISelection.class) [or some other interface] and handle the initial setting of - we create our own IFileEditorInput that implements provides the adapter and allows to set the initial selection upon creation. It would help if the restriction on FileEditorInput saying that it is not intended to be subclassed is removed. Otherwise we have to copy the code instead of just subclassing the existing class. I'm taking the bug back to investigate this further.
To make it happen for 3.1 we need to subclass FileEditorInput because if we provide our own implementation (i.e. copy the code) clients that currently use/cast to FileEditorInput (instead of IFileEditorInput) would be broken (there were similar places even inside the Eclipse SDK - see corresponding bug reports) and it's a bit late in the game to do such a change now. Michael, Platform UI already subclasses FileEditorInput (I know this is done inside the same plug-in but it's against the spec nevertheless ;-) In addition there exist already other subclasses (one in JDT UI and one in PDE UI).
nick can you comment on comment #9
I'm fine with allowing subclassing of FileEditorInput, but if what we're doing is a workaround anyway, I don't see the API change as essential for 3.1. The right answer would be to allow an initial selection to be passed to openEditor, in addition to the input. Also note that subclasses of FileEditorInput should be careful to handle persistence properly. They'll likely need to specify a different factory if maintaining extra state besides the IFile.
I'm fine with an internal blessing and move to the correct solution for 3.2.
I've filed bug 96019 and bug 96021 for the persistence problems.
If the subclass's selection is just going to be used when the editor is first opened, the selection should not be persisted. Or if it is, it should probably not be honoured when the editor is restored, since it's likely that the user changed the selection. It's probably less surprising to have the editor restored at the top then at the selection when it was first opened. Ideally the editor's current selection would be persisted too, but editors unfortunately do not support saveState(IMemento) like views do (there's a PR for this already).
I only see this as a hack to fix the flash for 3.1. No plans to provide persistency code for 3.1.
A hack fix at this time is good for me so long as it doesn't involve API or something that can't easily be fixed the right way after 3.1.
I've a version ready which fixes the vertical scrolling. The problem now is that it upon opening it shifts the styled text widget to the right which I do not really understand and which looks quite ugly. Maybe someone from the SWT team (Steve ;-) could take a look at this. I can provide my current state either as patch or a plug-in export (to big to attach) It might be related with the layoutting of the text viewer and looks as if the ruler width is applied at a later point to the viewer and hence the text widget shifted to the right. Moving target milestone to RC2 to investigate this further. If we can pin down the horizontal shiftting we have a really good improvement here. The current changes to not require additional API.
Attach the patch or release the code with a flag or property we can use to turn it on and we will look at it. Does it scroll on all platforms?
It's no longer a "flash" but rather just shifting it to the right. What I think is happening is that before the styled text widget with the rulers on the left and right was created with caret a position 0 just afterwards we've set the selection inside a setRedraw(false/true). This caused the vertical flash plus the scroll bar jumping. Now we set the selection during viewer creation and there's no setRedraw(false/true) involved on our side. Even if I surround the whole creation code (i.e. before setting the contents to the text widget) with setRedraw(false/true) I see the thext inside the widget being moved. Patches coming...
Created attachment 21918 [details] Patch to be applied to org.eclipse.ui.workbench.texteditor
Created attachment 21919 [details] Patch to be applied org.eclipse.jdt.ui
I am able to make it happen on Windows when selecting files in the hierarchy view. It does not happen in the packages view. In that view, it doesn't scroll to show the class. Is different code running? FH and SN to look into what is happening.
>packages view Package Explorer?
Yes.
Bug in StyledText, a capture it in Bug 97366
I also see it using the Package Explorer.
Ok, defer this for 3.1. It's too dangerous to change right now.
Setting to REMIND until the blocking bug is fixed.
*** Bug 96782 has been marked as a duplicate of this bug. ***
Steve, OK to close this as this happens in SWT which decided not to fix this?
Sure.
.
WONTFIX, see bug 96782.
