Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Direct instantiation of SWTGraphics in DeferredUpdateManager
Direct instantiation of SWTGraphics in DeferredUpdateManager [message #217632] Fri, 09 June 2006 19:15 Go to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Steven R. Shaw is currently offline Steven R. ShawFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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.
>
>
Re: Direct instantiation of SWTGraphics in DeferredUpdateManager [message #217735 is a reply to message #217689] Mon, 12 June 2006 13:59 Go to previous message
Steven R. Shaw is currently offline Steven R. ShawFriend
Messages: 128
Registered: July 2009
Senior Member
Please submit a bugzilla. We're past api freeze for 3.2 so this is unlikely
to be considered. However, it could be a candidate for 3.2.1.

If you attach a patch to the bugzilla with your desired changes to
DeferredUpdateManager, I believe you are permitted to copy the file locally
for your purposes according to the EPL license. Consult your legal
department to be sure...

Regards,

Steve.

"JasperAssistant" <contact@jasperassistant.com> wrote in message
news:e6j3bm$499$1@utils.eclipse.org...
> 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
Previous Topic:EditPart Creation question
Next Topic:image memory release problem in palette
Goto Forum:
  


Current Time: Wed Nov 30 15:26:08 GMT 2022

Powered by FUDForum. Page generated in 0.02287 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top