Bugzilla – Full Text Bug Listing
| Summary: | Line numbers do not update on Snow Leopard Cocoa port | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Shaun Crampton <shaun> |
| Component: | SWT | Assignee: | Project Inbox <swt-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Scott Kovatch <skovatch> |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, g.watson, justin, lshanmug, markus.kell.r, mike.jackson, mrm, pedromagnus, shaun, skovatch |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Shaun Crampton
We used to see this in the Carbon version, but never on Cocoa. If you can get steps to reproduce it that would be great. Sorry, it seems to happen at random while I'm editing. I do have a few plugins installed (GWT, ADK come to mind). Not ure if that;s a problem. This looks like the same problem as bug 321887. Hi. I have a similar issue using a MacBook 13". The line numbers doesn't move with the scrolling of any open document (doesn't matter it's extension). But the problem just happen when Eclipse is displayed in a 21" Dell external monitor. In the screen of the Mac the line numbers update OK with scrolling. As soon as Eclipse window is dropped in the external monitor, the line numbers change to start in '1'; no matter what part of the document is seen, the first visible line is marked as line number 1. This is really annoying, luckily the 'go to line' function works fine. I also have this problem with C++ editors in CDT. Both in the Helios Cocoa 64 Bit release and the Indigo RCs. The Carbon builds of Helios do not seem to have this problem. This is on OS X 10.6.8 Intel. Anyone know what the issue was under Carbon? I can usually resize the whole Eclipse window and the Line numbers will update. But as soon as I start scrolling the problem will come back. Thanks. Commented on #321887 but repeating here for those not on the list there! ==== This has been getting up my nose also, seems more than intermittent, and I think I've just found a way to reproduce this at will. 1. Open a java source file, with at least enough lines to not all be visible 2. Page up/down, scroll via mousewheel/touchpad etc and observe the ruler line numbers update correctly 3. Now open a multi-page editor, e.g. Plug-in Manifest editor (via plugin.xml or manifest.mf) 4. Select your java editor and repeat step 2 and you'll see the repaint issues/cheese 5. Close the manifest editor and the ruler now updates correctly once more I can open any number of java source files and the ruler is fine but as soon as I open a manifest editor then it's messed up. Just tried opening a pom editor and a .exsd schema editor - the java ruler is fine with these, so it's not just *any* multi-page editor... Forgot to mention.. the above is on Lion (10.7.1) with Indigo x86_64. Well done! I can confirm this happens for me on SL (10.6). Also, it only happens when the Dependencies, Runtime, and Extension Points tabs are visible when switching to the editor. If the other tabs are visible, the issue does not manifest. (In reply to comment #1) > We used to see this in the Carbon version, but never on Cocoa. (In reply to comment #5) > Anyone know what the issue was under Carbon? I think the Carbon problems were bug 294929. Bug 321887 is indeed a dup of this one. SWT team, please mark as dup one way or the other (I didn't want to interfere with triage). *** This bug has been marked as a duplicate of bug 321887 *** |