Community
Participate
Working Groups
As I look through the implementations of PaintListeners in Eclipse plugins, I found two different use cases: 1. I want to paint additional decorations to the controls graphic context. I understand that it's not very easy to paint on HTML elements different from Canvas, but I think it would be enough to state this limitation in the method description or remove "gc" from PaintEvent. As most of the implementations I found for this use case just create "nice but ignorable decorations", I would suggest to use the first variant and return a dummy graphics context. 2. I want to run some code after the component was displayed first (because I need the displayed size or similar). I think that should be possible even in RAP. And thats why we need the add/removePaintListener for Control like in SWT.
+1 With paintListener on Control we can also support SWT.Paint. BTW, there is an SWT.Show event if you want to run code when the widget becomes visible (for the first time).
Thanks for approval. As I said, this is how PaintListeners are partly used in different Eclipse plugins I've seen during migration to RAP, not how I'm using them.
I would try to support this for real. The GC client implementation was recently changed so that i *think* this is fixable entirely on the server.
That would be cool!
Since SWT.Paint exists, it's already possible to add an untyped paint listener on any Control, so I think we could as well pull up the add/removePaintListener() methods. However, I'd not start to implement painting on arbitrary widgets in the web client before we have some convincing use cases that make sense for RAP. Even if possible, painting would still behave different than it does in SWT (like not painting on top but below content, not refreshing, etc...), and in most cases it won't be appropriate for the web.
