Bugzilla – Full Text Bug Listing
| Summary: | Regression: [StyledText] control-left and control-right almost useless | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tobias Bading <tbading> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arunkumar.thondapu, daniel_megert, eclipse.felipe, remy.suen, Silenio_Quarti, tbading |
| Version: | 3.7.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
|
Description
Tobias Bading
I don't quite understand what's broken. Can you give a concrete example what happens? > The editor for a simple txt file works fine on the other hand. I almost can't believe that, because disabling the option for the Java editor should result in the same behavior. > The XML editor shows these symptoms as well, independent > of the preference setting. That's expected since that preference is for the Java editor and not the XML editor. > I don't quite understand what's broken. Can you give a concrete example what happens? If "Smart caret positioning in Java names (overrides platform behavior)" is inactive, (shift-)control-(left|right) is broken. Standard "platform behavior" on Linux (as well as Windoze) for control-left would be to move the caret to the previous word. If the caret is before the first word of a line, the caret should move to the last word of the previous line. This doesn't happen. Instead, the caret doesn't move at all (most of the time). Sometimes, the caret moves to the previous line, but is then stuck a few control-lefts further at the beginning of that line. Try putting interface test { int testTest (); void testTest2 (); char testTest3 (); }; into a Java editor and the caret into the word testTest2. I am unable to move beyond "void testTest2" using only control-left and control-right. The caret becomes stuck either directly before "void", or after "testTest2". > > The editor for a simple txt file works fine on the other hand. > I almost can't believe that, because disabling the option for the Java editor should result in the same behavior. Yep, you're right. I just tried this again with my own example and the caret doesn't change lines as well. So the text editor is affected as well. After having experimented a bit more, I have to say this bug is quite erratic in behavior. If you strip the example down to interface test int testTest void testTest2 char testTest3 everything works fine. Looks like the caret doesn't want to hopp over non-alpha charaters ;-). And it doesn't seem to like indented lines very much either :-(. > > The XML editor shows these symptoms as well, independent of the preference setting. > That's expected since that preference is for the Java editor and not the XML editor. Umm... yes and no. Since there is no "Smart caret positioning" option for XML files, I would expect the XML editor's caret to show platform behaviour. At least on my machine it doesn't. It is stuck in the same way. A quick check of Helios and Galileo on the same machine shows that this bug seems to be an Indigo-exclusive. What you see is the platform/OS behavior - at least for some of the text libraries on it. I can move the bug to SWT for comment but I guess that's just how it works on your OS. (In reply to comment #3) > What you see is the platform/OS behavior - at least for some of the text > libraries on it. Has anything been changed in this respect between Helios and Indigo? Are other text libraries being used in Indigo? > I can move the bug to SWT for comment but I guess that's just how it works on > your OS. Sorry, but please don't "guess" if you don't know GNU/Linux and/or GNOME. This is a *new bug* in Indigo. Galileo & Helios work just fine on the same machine with smart caret positioning turned off. I already tried a fresh workspace in Indigo to make sure this isn't caused by some freak accident that happened to my workspace. Tomorrow I'll check another Indigo package. I'm currently using the "Eclipse IDE for Java EE Developers" package. > Sorry, but please don't "guess" if you don't know GNU/Linux and/or GNOME. Well, it's just my guess - you don't have to like it. It's like you guessing I don't know GNU or whatever. >Has anything been changed in this respect between Helios and Indigo? Are other >text libraries being used in Indigo? > Galileo & Helios work just fine on the same machine > with smart caret positioning turned off. The SWT team will be able to comment on that. I just tried the Eclipse IDE for Java Developers under a new user account. Same results. You can leave the current line using just control-left/right when "Smart caret positioning in Java names (overrides platform behavior)" is on, but not when it's off. And that is definitely *not* "platform behavior". Different applications might have different ideas about what a word is, but they all agree that (shift-)control-left/right should be able to leave the current line. I'm talking about a <textarea> in Firefox here for example, or Thunderbird, or Evolution, or .... Tobias, if you find time, please try the following SWT snippet: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet163.java This will allow to test the behavior on just the widget i.e. without editor code being involved. (In reply to comment #7) > Tobias, if you find time, please try the following SWT snippet: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet163.java > > This will allow to test the behavior on just the widget i.e. without editor > code being involved. If I put interface test { int testTest (); void testTest2 (); char testTest3 (); }; into the StyledText, I get exactly the same result like in Indigo's Java or XML editor: Using just control-left/right won't allow me to leave a line :-(. But the stripped down example interface test int testTest void testTest2 char testTest3 works just fine. That little SWT caret seems to be afraid of parentheses, semicolons and the like. ;-) The same snippet compiled and run under Helios works just fine, no matter what text you put into the StyledText. Can you check the .metadata/.log for any exceptions? (In reply to comment #9) > Can you check the .metadata/.log for any exceptions? Nope, sorry, nothing. I also debugged the snipped with a breakpoint on all Throwables and subclasses, caught and uncaught, also nothing when trying to control-left/right around. Another test: eclipse-jee-juno-M5-linux-gtk-x86_64.tar.gz works fine, both the eclipse Java and XML editors as well as the SWT test snippet. (A little side note though: control-left/right-ing with keyboard auto-repeat in Juno's Java editor is nothing for the faint of heart. The editor highlights stuff *immediately* without any delay. It's quite a light show. ;-) Works for me with running latest on Fedora 15 32bits. Arun, can you try this on your machine ? (In reply to comment #12) > Works for me with running latest on Fedora 15 32bits. > > Arun, can you try this on your machine ? Works for me too on Ubuntu 11.04 with Eclipse Juno but yet to test with Indigo. (In reply to comment #13) > > Works for me too on Ubuntu 11.04 with Eclipse Juno but yet to test with Indigo. I just tested with Indigo SR1 on Ubuntu 11.04 and I experience the same problem as reported in the bug. I'm not sure what has changed in StyledText between Indigo and Juno. (In reply to comment #14) > I just tested with Indigo SR1 on Ubuntu 11.04 and I experience the same problem > as reported in the bug. I'm not sure what has changed in StyledText between > Indigo and Juno. we need to find out, can you please investigate this problem ? what version of pango/gtk is ubuntu 11.04 running ? (In reply to comment #15) > > we need to find out, can you please investigate this problem ? Yes, I'm trying to understand the changes in TextLayout that went exclusively into 3.8/4.2 to see how the regression doesn't exist in Juno. However, since we will not be able to fix this in 3.7.x now and it doesn't seem to occur in 3.8, I'm wondering how to go about it? > what version of pango/gtk is ubuntu 11.04 running ? GTK version is 2.24.4 and Pango version is 1.28.4. Mostly out of curiosity, I checked the running SWT snippet (from comment #7) using pmap when started from Indigo and Helios. They mostly use the same shared libraries (on my Ubuntu Lucid machine), including /usr/lib/libpango-1.0.so.0.2800.0 /usr/lib/libpangocairo-1.0.so.0.2800.0 /usr/lib/libpangoft2-1.0.so.0.2800.0 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so /usr/lib/libgtk-x11-2.0.so.0.2000.1 Some of the (expected) differences are Indigo: ~/.swt/lib/linux/x86_64/libswt-atk-gtk-3738.so ~/.swt/lib/linux/x86_64/libswt-gtk-3738.so ~/.swt/lib/linux/x86_64/libswt-pi-gtk-3738.so Helios: /tmp/swtlib-64/libswt-atk-gtk-3655.so /tmp/swtlib-64/libswt-gtk-3655.so /tmp/swtlib-64/libswt-pi-gtk-3655.so Nothing suspicious here as far as I can tell. Please let me know if there's anything I can do to help. (In reply to comment #16) > [...] However, since we will not be able to fix this in 3.7.x now and it doesn't seem to occur in 3.8, I'm wondering how to go about it? A fix in 3.7.2 if possible would be greatly appreciated, because I'll be using Indigo for a few years I guess. :-) (Follow-up to my own comment #18) > A fix in 3.7.2 if possible would be greatly appreciated, because I'll be using > Indigo for a few years I guess. :-) LOL. I just saw the "Indigo 3.7 SR2 Endgame Plan" (http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_7_2.php). So much for that idea... Is this working with our latest code ? this must be a duplicate of Bug 350362. personally I think this is a serious bug, are we shipping 3.7.2 broken ? *** This bug has been marked as a duplicate of bug 350362 *** (In reply to comment #20) > Is this working with our latest code ? I haven't tested with the 3.7.2 RC build yet but I'd assume the bug exists because there are no changes that went into 3.7.2 in TextLayout. Will confirm and update again. > > this must be a duplicate of Bug 350362. That is right, this is the fix that seems to resolve the problem in 3.8/4.2. (In reply to comment #20) > personally I think this is a serious bug, are we shipping 3.7.2 broken ? I have tested with the latest 3.7.2 build (M20120208-0800) and can confirm that this bug is reproducible. |