| Direct instantiation of SWTGraphics in DeferredUpdateManager [message #217632] |
Fri, 09 June 2006 19:15  |
Eclipse User |
|
|
|
Originally posted by: contact.jasperassistant.com
Hi,
I've just downloaded the latest integration build for Eclipse 3.2 and
I've encountered a disturbing problem. The plug-in that I am developing
uses Java2D to perform the drawing. To enable the Draw2D use Java2D
transparently, I am implementing the Graphics interface and plugging it
in through an implementation of GraphicsSource and a modified (through
subclassing) version of LightweightSystem. Our own code is depending on
our specific implementation of Graphics interface to be able to use more
advanced features of Java2D.
The above construction works just fine in previous stable versions of
GEF/Draw2D for Eclipse 3.1. However with the latest versions it breaks
due to the following code in DeferredUpdateManager:
void paint(GC gc) {
SWTGraphics graphics = new SWTGraphics(gc);
if (!updating) {
/**
* If a paint occurs not as part of an update, we should notify that
the region
* is being painted. Otherwise, notification already occurs in
repairDamage().
*/
HashMap map = new HashMap();
Rectangle rect = graphics.getClip(new Rectangle());
map.put(root, rect);
firePainting(rect, map);
}
root.paint(graphics);
graphics.dispose();
}
The above code creates directly an instance of SWTGraphics without using
the GraphicsSource indirection and thus breaks the abstraction. Would it
be possible to fix so that an alternative Graphics implementation could
be used?
Thank you,
Peter.
|
|
|
| Re: Direct instantiation of SWTGraphics in DeferredUpdateManager [message #217647 is a reply to message #217632] |
Sun, 11 June 2006 01:37  |
 Steven R. Shaw
Messages: 128
Registered: July 2009 |
Senior Member |
|
|
This was introduced for enhancement 118309.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=118309).
Since you're overriding LightweightSystem anyway, you have a hook to
override the public method LightweightSystem#paint routine to call your own
routine that overrides the Graphics rendering behavior instead of the
package protected DeferredUpdateManager.paint routine which has the
dependency to SWTGraphics.
Regards,
Steve.
"JasperAssistant" <contact@jasperassistant.com> wrote in message
news:e6chan$3ac$1@utils.eclipse.org...
> Hi,
>
> I've just downloaded the latest integration build for Eclipse 3.2 and
> I've encountered a disturbing problem. The plug-in that I am developing
> uses Java2D to perform the drawing. To enable the Draw2D use Java2D
> transparently, I am implementing the Graphics interface and plugging it
> in through an implementation of GraphicsSource and a modified (through
> subclassing) version of LightweightSystem. Our own code is depending on
> our specific implementation of Graphics interface to be able to use more
> advanced features of Java2D.
>
> The above construction works just fine in previous stable versions of
> GEF/Draw2D for Eclipse 3.1. However with the latest versions it breaks
> due to the following code in DeferredUpdateManager:
>
> void paint(GC gc) {
> SWTGraphics graphics = new SWTGraphics(gc);
> if (!updating) {
> /**
> * If a paint occurs not as part of an update, we should notify that
> the region
> * is being painted. Otherwise, notification already occurs in
> repairDamage().
> */
> HashMap map = new HashMap();
> Rectangle rect = graphics.getClip(new Rectangle());
> map.put(root, rect);
> firePainting(rect, map);
> }
> root.paint(graphics);
> graphics.dispose();
> }
>
> The above code creates directly an instance of SWTGraphics without using
> the GraphicsSource indirection and thus breaks the abstraction. Would it
> be possible to fix so that an alternative Graphics implementation could
> be used?
>
>
> Thank you,
>
> Peter.
|
|
|
| Re: Direct instantiation of SWTGraphics in DeferredUpdateManager [message #217689 is a reply to message #217647] |
Mon, 12 June 2006 07:00 |
| Eclipse User |
|
|
|
Originally posted by: contact.jasperassistant.com
Hi Steve,
Thank you for your reply. No, overriding the paint method does not work
as one does not have access to all the internal state fields that are
required there (updating, root). It would be much easier if a factory
method could be provided for creating the Graphics instance, with a
signature like this:
protected Graphics createGraphics(GC gc) {
return new SWTGraphics(gc);
}
Otherwise the only solution that exists is to reimplement completely the
DeferredUpdateManager which I would like to avoid.
Thank you,
Peter.
Steven Shaw a écrit :
> This was introduced for enhancement 118309.
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=118309).
>
> Since you're overriding LightweightSystem anyway, you have a hook to
> override the public method LightweightSystem#paint routine to call your own
> routine that overrides the Graphics rendering behavior instead of the
> package protected DeferredUpdateManager.paint routine which has the
> dependency to SWTGraphics.
>
> Regards,
>
> Steve.
>
> "JasperAssistant" <contact@jasperassistant.com> wrote in message
> news:e6chan$3ac$1@utils.eclipse.org...
>> Hi,
>>
>> I've just downloaded the latest integration build for Eclipse 3.2 and
>> I've encountered a disturbing problem. The plug-in that I am developing
>> uses Java2D to perform the drawing. To enable the Draw2D use Java2D
>> transparently, I am implementing the Graphics interface and plugging it
>> in through an implementation of GraphicsSource and a modified (through
>> subclassing) version of LightweightSystem. Our own code is depending on
>> our specific implementation of Graphics interface to be able to use more
>> advanced features of Java2D.
>>
>> The above construction works just fine in previous stable versions of
>> GEF/Draw2D for Eclipse 3.1. However with the latest versions it breaks
>> due to the following code in DeferredUpdateManager:
>>
>> void paint(GC gc) {
>> SWTGraphics graphics = new SWTGraphics(gc);
>> if (!updating) {
>> /**
>> * If a paint occurs not as part of an update, we should notify that
>> the region
>> * is being painted. Otherwise, notification already occurs in
>> repairDamage().
>> */
>> HashMap map = new HashMap();
>> Rectangle rect = graphics.getClip(new Rectangle());
>> map.put(root, rect);
>> firePainting(rect, map);
>> }
>> root.paint(graphics);
>> graphics.dispose();
>> }
>>
>> The above code creates directly an instance of SWTGraphics without using
>> the GraphicsSource indirection and thus breaks the abstraction. Would it
>> be possible to fix so that an alternative Graphics implementation could
>> be used?
>>
>>
>> Thank you,
>>
>> Peter.
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02849 seconds
] 
Search
Help
Register
Login
Home
