Community
Participate
Working Groups
Not sure what form this should take, another caret? I talked to Kevin and it is not possible (at least on win32) to host two carets. So a custom one would have to be drawn using a PaintListener. This is quite straightforward but gets more challenging when you need to compare what line they're on and whether they're on a line that you're seeing or not (as everyone's editor sizes may be different).
This bug may boil down to some needed enhancements in platform UI...at least to do fully. Short of that, there may be ways to create awareness of other user without having separate carets...e.g. background/foreground color changes, or other things.
(In reply to comment #1) > Short of that, there may be ways to create awareness of other user without > having separate carets...e.g. background/foreground color changes, or other > things. You mean like highlighting the region the other user is on like what NetBeans does? Yes, I thought about that idea too and I think highlighting the line the other user is on may be easier since Eclipse does highlight the line you yourself are on so I think there may be some APIs (or internal code to copy/paste) to expose such a functionality.
I have pasted the code of a self-contained dual-StyledText window snippet to demonstrate what can be possible with pure SWT code. The highlighting code was taken from o.e.jface.text.CursorLinePainter. The code has not been extensively tested but the ideas are there. Note that only the left hand side will show the highlighting and caret display. If you select two or more lines of text on the right hand side, the left hand side will not react to this. This code will not work if you leave the original "page" as it does not handle the scenario where the left hand side is at the top of the document and the right hand side is scrolled to another part of the document. ------------------------------------- import org.eclipse.swt.SWT; import org.eclipse.swt.custom.*; import org.eclipse.swt.events.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.layout.GridData; import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.widgets.*; public class Main { public static void main(String[] args) { final Display display = new Display(); // red highlighting colour final Color otherColor = new Color(display, new RGB(254, 242, 232)); Shell shell = new Shell(display); shell.setLayout(new GridLayout(2, true)); final StyledText textOne = new StyledText(shell, SWT.MULTI | SWT.V_SCROLL | SWT.H_SCROLL); final StyledText textTwo = new StyledText(shell, SWT.MULTI | SWT.V_SCROLL | SWT.H_SCROLL); textOne.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true)); textTwo.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true)); // primitive way of keeping both documents the same textOne.addModifyListener(new ModifyListener() { public void modifyText(ModifyEvent e) { if (!textTwo.getText().equals(textOne.getText())) { textTwo.setText(textOne.getText()); } } }); textTwo.addModifyListener(new ModifyListener() { public void modifyText(ModifyEvent e) { if (!textOne.getText().equals(textTwo.getText())) { textOne.setText(textTwo.getText()); } } }); textOne.addLineBackgroundListener(new LineBackgroundListener() { public void lineGetBackground(LineBackgroundEvent e) { int offset = e.lineOffset; int otherOffset = textTwo.getCaretOffset(); // if the queried line is a line that the other caret is on, we should highlight it if (textOne.getLineAtOffset(offset) == textOne.getLineAtOffset(otherOffset)) { e.lineBackground = otherColor; } else { e.lineBackground = textOne.getBackground(); } } }); textOne.addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { // draw a static blue caret corresponding to the right hand side Caret caret = textTwo.getCaret(); Rectangle r = caret.getBounds(); e.gc.setForeground(display.getSystemColor(SWT.COLOR_BLUE)); e.gc.drawLine(r.x, r.y, r.x, r.y + r.height); } }); textTwo.addMouseListener(new MouseAdapter() { public void mouseDown(MouseEvent e) { redraw(textOne, textTwo); } }); textTwo.addKeyListener(new KeyAdapter() { public void keyPressed(KeyEvent e) { redraw(textOne, textTwo); } }); textTwo.addTraverseListener(new TraverseListener() { public void keyTraversed(TraverseEvent e) { switch (e.detail) { case SWT.TRAVERSE_ARROW_NEXT : case SWT.TRAVERSE_ARROW_PREVIOUS : case SWT.TRAVERSE_PAGE_NEXT : case SWT.TRAVERSE_PAGE_PREVIOUS : case SWT.TRAVERSE_TAB_NEXT : case SWT.TRAVERSE_TAB_PREVIOUS : redraw(textOne, textTwo); break; } } }); shell.setSize(640, 480); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } otherColor.dispose(); display.dispose(); } private static int lastLine = -1; public static void redraw(StyledText textOne, StyledText textTwo) { int widgetOffset = textTwo.getCaretOffset(); int currentLine = textOne.getLineAtOffset(widgetOffset); // if we never moved off of the previous line, don't bother redrawing if (currentLine == lastLine) { return; } // invoke a redraw on the current line to highlight it Point upperLeft = textOne.getLocationAtOffset(widgetOffset); int width = textOne.getClientArea().width + textOne.getHorizontalPixel(); int height = textOne.getLineHeight(widgetOffset); textOne.redraw(0, upperLeft.y, width, height, false); // we check that the line is actually less than our current line count to ensure that we don't draw to redraw non-existent lines if (lastLine != -1 && lastLine < textOne.getLineCount()) { // redraw the last line so that the highlighting can be removed int lastOffset = textOne.getOffsetAtLine(lastLine); upperLeft = textOne.getLocationAtOffset(lastOffset); height = textOne.getLineHeight(lastOffset); textOne.redraw(0, upperLeft.y, width, height, false); } // set the last line as the current line lastLine = currentLine; } } \
Thanks Remy for the snippet. Will it be possible to hook into the StyledText widget (or other) in existing editors without modifying the existing editor code? (i.e. adding paint listeners, etc). Seems increasingly likely that we can do something in this area soon, so setting target milestone to 2.0.1. I wouldn't expect too much further action on this until after Wed 25th/Ganymede release, since I (Scott) have Ganymede release prep and a Tues presentation to prepare/travel for, and Mustafa is traveling over weekend to US for the same Tues presentation. But, it's not being forgotten in the least. I do, however, think some further actual usage experimentation with this will be needed...to figure out what looks/works. Perhaps with user preferences to determine what happens/is displayed?
Created attachment 105592 [details] A screenshot of embedding some tweaked listeners in action. As you can see from the screenshot, the line selections are being handled properly. It seems to be slightly glitched when the two editors are first opened but that's a minor technicality once the StyledText widget has had a chance to redraw itself (or the glitched regions/lines). (In reply to comment #4) > Thanks Remy for the snippet. Will it be possible to hook into the StyledText > widget (or other) in existing editors without modifying the existing editor > code? (i.e. adding paint listeners, etc). As long as they return the StyledText when getAdapter(Control.class) is called, it should be okay. This should be handled by AbstractTextEditor, so assuming there's nothing funny with the editor, there shouldn't be any problems. > Seems increasingly likely that we can do something in this area soon, so > setting target milestone to 2.0.1. Isn't this more of a feature enhancement than a bug fix? > I do, however, think some further actual usage experimentation with this will > be needed...to figure out what looks/works. Perhaps with user preferences to > determine what happens/is displayed? One could imagine the user could pick what colour the caret/background should be. They should also be able to pick whether to just draw the caret, only highlight the background, or both draw the caret and highlight the background. A minor case to consider is what should the background look like if both cursors are on the same line. Another thing to worry about is what should be done if more users join the session? Handling all these colours will be quite a nightmare. There are probably other preferences to consider, but those are just the ones off the top of my head right now.
Changing target milestone to 2.1
*** Bug 238785 has been marked as a duplicate of this bug. ***
Created attachment 106058 [details] Patch for DocShare, implementation based on Annotations
(In reply to comment #8) > Created an attachment (id=106058) [details] > Patch for DocShare, implementation based on Annotations If the cursor is sometimes not painted, it is caused by this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=227534 With the provided patch for the annotation painting bug, it works fine.
Remy, would you like to apply and evaluate these patch from Stephan (#106058)? If you can't do it, please re-assign to me.
Created attachment 106252 [details] Patch for DocShare, implementation based on Annotations (2) Small changes in synchronization/access of AnnotationModel What the patch does not (yet) do: - It doesn't check, if the document is in synch (necessary?) - i18n/NLS
(In reply to comment #10) > Remy, would you like to apply and evaluate these patch from Stephan (#106058)? I can help review but I'm not sure if I'm in any position to apply anything since I'm not familiar with the DocShare code (in terms of the synchronization strategy, backend bit, etc.).
I did a very small test with Stephan's attachment 106252 [details] and it seems to be working. Mustafa?
I admit I haven't been able to try it yet, but have one question: If based upon annotations, doesn't this mean that java 1.5 is required (rather than 1.4?) for docshare? I don'actually any problems with docshare being dependent upon 1.5, but can this code fail back to doing something reasonable on 1.4?...or does docshare now need to require 1.5 EE?
(In reply to comment #14) > I admit I haven't been able to try it yet, but have one question: If based > upon annotations, doesn't this mean that java 1.5 is required (rather than > 1.4?) for docshare? I don'actually any problems with docshare being dependent > upon 1.5, but can this code fail back to doing something reasonable on > 1.4?...or does docshare now need to require 1.5 EE? Hi Scott, we're talking about Platform/Text annotations, not Java 5 annotations actually. One issue with this patch is that there's only one colour set for the remote cursor/text selection. This means that there is no way to distinguish between the different remote others users once N-way support is implemented.
(In reply to comment #15) > (In reply to comment #14) > > I admit I haven't been able to try it yet, but have one question: If based > > upon annotations, doesn't this mean that java 1.5 is required (rather than > > 1.4?) for docshare? I don'actually any problems with docshare being dependent > > upon 1.5, but can this code fail back to doing something reasonable on > > 1.4?...or does docshare now need to require 1.5 EE? > > Hi Scott, we're talking about Platform/Text annotations, not Java 5 annotations > actually. OK, thanks. Does it seem that this will work on the 3.3 platform also, or 3.4 only? I should just try it and all my questions would be answered...so that's what I'll try to do.
Created attachment 107805 [details] Patch for DocShare, implementation based on Annotations (3) Minor change: replaced map type
Yes, it works on platform 3.3 and 3.4 and java 1.4 and above. Yes patch uses Platform/Text annotations, so you don't need special SWT code to paint the cursor and selection. The user can simply (dis)enable it and change the color in the (text editor) annotation preference page. But (comment #9) !!!: > If the cursor is sometimes not painted, it is caused by this bug: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=227534 > With the provided patch for the annotation painting bug, it works fine. Unfortunately, this bug is not yet fix in Eclipse, so the patch is probably not ready to commit. I applied the patch for #227534 to "my" editors, and then all annotation are painted correctly - and the patch for the indication of cursor/selection of the remote user works for me too.
Checking in on this bug. Now we're working fully on additions/changes to DocShare for ECF 3.0/Eclipse 3.5...does anyone know if the Platform UI bug referred to in comment #18 is fixed? Would we then be able to add this contribution (or a new patch that is from a more recent DocShare...i.e. from ECF HEAD...as we've been making a large number of changes to DocShare to take advantage of the new ECF sync API (org.eclipse.ecf.sync).
Created attachment 126503 [details] Patch for DocShare, implementation based on Annotations (4) Updated to current HEAD It works well in 3.5. It seems there was changed something in the handling of annotation and the cursor is nearly always painted correctly now. In rare situation the cursor annotation is not painted if the remote user sets the cursor using the mouse. But the previous problem that the annotations are not removed properly, did no longer occur during my tests.
(In reply to comment #20) > Created an attachment (id=126503) [details] > Patch for DocShare, implementation based on Annotations (4) > > Updated to current HEAD > > It works well in 3.5. It seems there was changed something in the handling of > annotation and the cursor is nearly always painted correctly now. In rare > situation the cursor annotation is not painted if the remote user sets the > cursor using the mouse. But the previous problem that the annotations are not > removed properly, did no longer occur during my tests. > Thanks much Stephen! We'll test and get this in place as soon as possible. Mustafa would you prefer to do the honors here and apply the patch, test, and commit to HEAD? I can instruct about necessary steps (WRT contributions/IP or mechanics) if desired.
I tested the patch on Mac, and the cursor support is not working properly. Actually it shows a "strange" cursor (very slim), and the current line is not in highlighting, and the latest line never shows the cursor. The implementation shows the selection when the peer highlighting the region, but for example if there is a "blank line" between others, this "blank line" is not considering the highlighting(probably related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=227534). Are you getting the same situation on Windows?
(In reply to comment #22) > I tested the patch on Mac, and the cursor support is not working properly. > Actually it shows a "strange" cursor (very slim) The cursor is as slim as a system default cursor (on windows). There is no bigger dash as annotation. > , and the current line is not in highlighting, The current line of the remote user? This is correct, but you see the indication in the overview ruler. So you can find easily the remote cursor/selection in long documents. > and the latest line never shows the cursor. This is caused by the same bug... > The implementation shows the selection when the peer highlighting the region, > but for example if there is a "blank line" between others, this "blank line" is > not considering the highlighting(probably related to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=227534). Correct (not only in blank lines).
(In reply to comment #23) > (In reply to comment #22) > > I tested the patch on Mac, and the cursor support is not working properly. > > Actually it shows a "strange" cursor (very slim) > The cursor is as slim as a system default cursor (on windows). There is no > bigger dash as annotation. on Mac this cursor is slim than default one, almost imperceptible the cursor. So I need to check why it is happing on Mac. > > > , and the current line is not in highlighting, > The current line of the remote user? exactly >This is correct, but you see the > indication in the overview ruler. So you can find easily the remote > cursor/selection in long documents. > > > and the latest line never shows the cursor. > This is caused by the same bug... ok > > > The implementation shows the selection when the peer highlighting the region, > > but for example if there is a "blank line" between others, this "blank line" is > > not considering the highlighting(probably related to > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=227534). > Correct (not only in blank lines). ok >
The contribution was committed to HEAD. I just added I18N. The code is working fine. Thanks a lot Stephan!!!
Resolving this, as per comment #25 things are working and in place for ECF 3.0. thanks again to Stephan, the contribution is most appreciated! Stephan will you be at EclipseCon 2009? If so please let us know and I'll buy you a beer.
Was a CQ submitted for attachment 126503 [details]?
(In reply to comment #27) > Was a CQ submitted for attachment 126503 [details]? > I don't think so. Please ask Marcelo though (who reviewed, applied and tested the patch) and if size requires a CQ (i.e. not 'small') then please go ahead and submit one...with the Galileo 'rush' bit on. Thanks.
