Community
Participate
Working Groups
Ubuntu 14.04, GTK 2 and GTK 3.10.8. Works fine on Windows 7. Snippet243 doesn't work on GTK because Text#insert(String) modifies the topIndex Steps: - launch Snippet243 - enter text: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - press ArrowUp until the line "4" becomes the top visible line - modify line "6" to "66" => expected: right text field should show line "4" on top => was: line "66" on top After bug 487467, get/setTopIndex(..) seem to work fine, but reseting the topIndex to the modified line on insert(..) is not OK.
This is a regression from bug 487467 that was actually fixed morning. It will land in RC3. *** This bug has been marked as a duplicate of bug 487467 ***
No, still happens with master: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=83f68458d1ae8ca986e87c6cf49dcb5c4bf9ba65 Looks like a regression from bug 466314. The changes from gtk_text_view_scroll_mark_onscreen() to gtk_text_view_scroll_to_mark(..., true, 0, 0) were wrong, since they unconditionally set the topIndex to the line that contains the mark.
I stand corrected: will investigate.
(In reply to Markus Keller from comment #2) > Looks like a regression from bug 466314. So I'm not actually sure this is the case. If I go back past the commit for this fix, the same behavior is exhibited. I.e. doing: > Steps: > - launch Snippet243 > - enter text: > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > 11 > 12 > 13 > 14 > 15 > - press ArrowUp until the line "4" becomes the top visible line > - modify line "6" to "66" > => expected: right text field should show line "4" on top > => was: line "66" on top Yields the bug: 66 ends up on top as well in the second text box. This doesn't happen on GTK2, though. I have a suspicion that this has something to do with row validation in GTK3.
This issue is reproducible on Mars, as well as Mars.1/2.
Eric, are you planning to work on this for 4.6.1? I'm changing the target to 4.6.2, please reset if necessary.
(In reply to Arun Thondapu from comment #6) > Eric, are you planning to work on this for 4.6.1? I'm changing the target to > 4.6.2, please reset if necessary. Correct -- in fact, this is still an issue for 4.7 so I'm going to set that as the milestone. This bug has been reproducible for awhile, back to Mars.
Move out of 4.7.
Update: I am seeing this bug on GTK2 as well now. Not sure what has changed in the last year or so but GTK2 is affected as well. On GTK3 I am also seeing the following behaviour: inserting the 6 causes the bug to happen. Inserting another 6 causes second viewer to scroll up to the four. Typing another 6 causes the viewer to scroll down to the 6. This alternates with every additional 6 inserted.
In Snippet243 there is a SWT.Verify handler that calls three methods: -set/getTopIndex -setSelection(int, int) -insert() insert() is responsible for this bug. Everything else seems to be working as intended. insert() is calling gtk_text_view_scroll_to_mark() for non SWT.SINGLE Text widgets. On GTK the way this works is that the GtkTextMark is scrolled to and placed at the top of the viewer. This is what is resetting the topIndex (what I said in comment 4 was incorrect). Now technically the Text.insert() API says nothing about scrolling at all: merely that the text at the selection should change. Intuitively it seems that inserting text at the selection merits the viewer being scrolled. For example: if a user manually selected text, scrolled the viewer so that the selection is not visible and then typed something, the viewer would scroll back to the newly inserted text automatically. Furthermore in bug 197785, there is behaviour on other platforms WRT scrolling that is not API: for example 197785#c1 states that Win32 scrolls at the end of the setSelection() call. To me this is also intuitive, just as the case I mentioned before with Text.insert(). On GTK we now have this behaviour as well. This does not technically break the topIndex API, as set/getTopIndex are still functioning as expected. I don't really see a clear way to fix this bug. GTK offers no way to check if a GtkTextMark is visible in the viewer, which would make fixing this bug easier. I tried some different approaches to get this to work but nothing works 100% without some unexpected consequences. I also thinking reverting the fix for bug 466314 is a bad idea, since that bug seems more sinister than this one. Maybe we could modify the Javadocs for set/getTopIndex? Something like "On some platforms, the topIndex is modified by selecting/deleting/inserting text"? Thoughts?
Making the modified line / selection visible if it was scrolled out of view is fine. But always scrolling the modified line to the top of the text widget is not OK.
(In reply to Markus Keller from comment #11) > Making the modified line / selection visible if it was scrolled out of view > is fine. But always scrolling the modified line to the top of the text > widget is not OK. That's a fair point. I have submitted a patch for this bug with a different approach, ready for you to review.
Gerrit change https://git.eclipse.org/r/100405 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6e81aaed66307e9b6e37e31d91f2740f53add5b4
(In reply to Eclipse Genie from comment #13) > Gerrit change https://git.eclipse.org/r/100405 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=6e81aaed66307e9b6e37e31d91f2740f53add5b4 Patch is in master now. Thanks Markus for bringing attention to this issue.
