Community
Participate
Working Groups
Build ID: I20070323-1616 Steps To Reproduce: 1. I extend AbstractDecoratedTextEditor which uses extenders of LineNumberRulerColumn and AnnotationRulerColumn. 2. I retrieve its CompositeRuler and get a hold of its control using getControl(). CompositeRuler uses CompositeRulerCanvas for its control. 3. I addPaintListener() on the returned control in order to customize the painting because I want to draw rectangle borders around parts of the text of the text editor that span the vertical rulers, the text widget of the editor. CompositeRulerCanvas is good enough to hook my listener to the controls of the individual ruler columns of CompositeRuler. 4. When the control of LineNumberRulerColumn (or AnnotationRulerColumn) needs to repaint, my PaintListener gets notified and I draw my border lines as I want them. 5. When LineNumberRulerColumn (or AnnotationRulerColumn) gets its IVerticalRulerColumn#redraw() invoked, it does painting directly on the GC of its control and doesn't forward the redraw request to its control which effectively doesn't cause the registered PaintListeners to get notified that repainting is in place. 6. Eventually, one draws in some cases and then IVerticalRulerColumn#redraw() is called and the customizations of the painting are lost and they are thus not available in other cases. More information: I know that the case in which I want to use AbstractDecoratedTextEditor is specific but this is a class for generic use so I don't think that functionality should be prevented for no obvious reason and I think that it should be as little restrictive as possible in order to have widespread use. When I paint the rectangular borders around the blocks of text of interest to me, I'm not interfering with the functionality of the ruler columns because I'm drawing thin lines that are either at the top or at the bottom of certain lines so the very line information depicted in the vertical ruler columns is more or less unaffected. I noticed the some of the IVerticalRulerColumn implementers just forward the redraw() call to their control (i.e. make it repaint). If this is not acceptable for LineNumberRulerColumn (or AnnotationRulerColumn), could please the redraw() implementations at least fire SWT.Paint? I've patched my versions of LineNumberRulerColumn and AnnotationRulerColumn to fire SWT.Paint in their redraw() and I don't see any problems as a result of it. For example the original LineNumberRulerColumn has the following it its redraw(): GC gc = new GC(fCanvas); doubleBufferPaint(gc); gc.dispose(); I've changed it to the following and it works for me so I'm giving it in order to demonstrate and better explain my idea: GC gc= new GC(fCanvas); try { Event event= new Event(); event.gc= gc; fCanvas.notifyListeners(SWT.Paint, event); } finally { gc.dispose(); } I hope that you'll find my explanations acceptably clear and that you'll agree with my opinion.
No plans to change this. You can create your own subclasses of those ruler columns and then let your editor create your own subclasses.
I've considered extending these classes and while it works for AnnotationRulerColumn because AbstractDecoratedTextEditor uses a deprecated extender that suggests using its super class, I don't think that extending works for LineNumberRulerColumn in this case. AbstractDecoratedTextEditor uses LineNumberChangeRulerColumn which is non-trivial, is defined final and uses classes internal to org.eclipse.jface.text.
Sorry we won't change this. What we could do is allowing to subclass LineNumberChangeRulerColumn as well (i.e. remove 'final'). Try this out and report back whether this would work for you. There's no chance we forward the paint event.
I've already tried subclassing LineNumberChangeRulerColumn (after patching it to make it non-final) and it works for me. If it's not a problem, could you please give a brief explanation why forwarding the redraw request to the Control of the IVerticalRulerColumn is not acceptable? I hope I'm not getting on your nerves by asking for such information because this is not my intention and I just want to make sure that I correctly understand the design decisions of IVerticalRulerColumn and do not make such unacceptable suggestions any more. Thank you in advance for your understanding and help. I'm sorry I'm reopening this bug again but I'm not sure how you want me to "report back" so I want to make sure that you notice my response.
>If it's not a problem, could you please give a brief explanation why forwarding >the redraw request to the Control of the IVerticalRulerColumn is not >acceptable? Main reason is performance and second is keeping the control over "our" rulers that we use. If we allow this and want to do our own painting in the future we'll get bug reports that we broke those that used the pain listener. >I hope I'm not getting on your nerves Don't worry ;-) >I'm sorry I'm reopening this bug again but I'm not sure how you want me to >"report back" so I want to make sure that you notice my response. We get notified if you add comments, so no need to reopen just to notify. But in this case we could change the summary to something like "allow to subclass ruler columns". Agreed?
(In reply to comment #5) > >If it's not a problem, could you please give a brief explanation why forwarding > >the redraw request to the Control of the IVerticalRulerColumn is not > >acceptable? > Main reason is performance and second is keeping the control over "our" rulers > that we use. If we allow this and want to do our own painting in the future > we'll get bug reports that we broke those that used the pain listener. > > >I hope I'm not getting on your nerves > Don't worry ;-) Thank you. > >I'm sorry I'm reopening this bug again but I'm not sure how you want me to > >"report back" so I want to make sure that you notice my response. > We get notified if you add comments, so no need to reopen just to notify. But > in this case we could change the summary to something like "allow to subclass > ruler columns". Agreed? Agreed. Thank you.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
