Add additional constructors to PSWTImage

[GoogleCodeExporter]

Old post to piccolo-dev, referred to in Issue 43.

From: Fabio Zadrozny
Date: Thu Apr 13 10:12:12 EDT 2006

 Sure, thanks... And while we are at it, there is another 'dispose' related
thing I wanted to request... It's not a bug, but a feature-request I find
important... I'm doing an Eclipse plugin, and I manage all the Images and
dispose them carefully (and share it among lot's of objects), so, I've added
the following constructors to PSWTImage, which I think should be in the
'default' distribution, as I think that's pretty common when using SWT
(sharing an image through several objects).

Thanks,

Fabio

CODE: PSWTImage.java--------------------------------------------------------

    public PSWTImage(PSWTCanvas canvas) {
        this(canvas, true);
    }

    public PSWTImage(PSWTCanvas canvas, final boolean disposeImage) {
        super();

        this.canvas         canvas.addDisposeListener(new DisposeListener() {
            public void widgetDisposed(DisposeEvent de) {
                if (image !                    image.dispose();
                }
            }
        });
    }

    public PSWTImage(PSWTCanvas canvas, Image newImage) {
        this(canvas, newImage, true);
    }

    public PSWTImage(PSWTCanvas canvas, Image newImage, boolean
disposeImage) {
        this(canvas, disposeImage);
        setImage(newImage);
    }

    public PSWTImage(PSWTCanvas canvas, String fileName) {
        this(canvas, fileName, true);
    }

    public PSWTImage(PSWTCanvas canvas, String fileName, boolean
disposeImage) {
        this(canvas, disposeImage);
        setImage(fileName);
    }

Original issue reported on code.google.com by heue...@gmail.com on 4 Sep 2009 at 3:09

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 4 Sep 2009 at 3:13

• Added labels: Component-SWT

[GoogleCodeExporter]

Will these constructors be added? Or if there are some problems with them I 
would
like to discuss them and get the issues fixed.
I want to try compiling pydev with piccolo2.java from trunk and identify any 
other
parts done locally in pydev.

Original comment by akurta...@gmail.com on 18 Sep 2009 at 9:37

[GoogleCodeExporter]

Original comment by akurta...@gmail.com on 22 Sep 2009 at 2:54

• Added labels: Milestone-1.3

[GoogleCodeExporter]

There is something missing from this patch.  I can only assume it should be

public PSWTImage(final PSWTCanvas canvas, final boolean disposeImage)
{
  super();
  this.canvas = canvas;
  this.canvas.addDisposeListener(new DisposeListener()
    {
      public void widgetDisposed(final DisposeEvent disposeEvent)
      {
        if (disposeImage && (image != null))
        {
          image.dispose();
        }
      }
    });
}

If this is the case, rather than polluting the API with several additional
constructors with a boolean parameter, I would like to add a new protected 
method

  protected void disposeImage()
  {
    if (image != null)
    {
      image.dispose();
    }
  }

and call that method from the DisposeListener.  This would allow subclasses of
PSWTImage to override the default behaviour if desired.

Original comment by heue...@gmail.com on 9 Oct 2009 at 4:00

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I agree with heuermh. Seems simpler.

Though I'd add a getter and setter for the boolean disposesImage and default 
would be 
true.

Original comment by allain.lalonde on 9 Oct 2009 at 2:36

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 9 Oct 2009 at 7:26

Attachments:

• patch.txt

[GoogleCodeExporter]

Just wanted to say that I'm Ok with any other approach (although if a protected
disposeImage() is provided, it might be nice providing a setter and getter too 
-- it
seems a bit strange having to subclass it just to add that behavior).

Original comment by fabi...@gmail.com on 12 Oct 2009 at 10:34

[GoogleCodeExporter]

Thanks for the input.

This is why I feel that a boolean ctr parameter or a getter/setter pair might 
not be
a good idea; consider the property slowInSlowOut on PInterpolatingActivity

http://www.piccolo2d.org/doc/piccolo2d.java/release-1.2.1/apidocs/edu/umd/cs/pic
colo/activities/PInterpolatingActivity.html#setSlowInSlowOut%28boolean%29

Here a boolean flag was used to discriminate between two different behaviors.  
The
problem arises when you want a third possible behavior, or more (i.e. Issue 
107). 
Now we have a meaningless pair of methods (or constructors, in the earlier 
patch)
that must go through a deprecation cycle before they can go away.

I can't say for sure that we'll ever come up with a third possible 
implementation of
disposeImage(), but we might.

Original comment by heue...@gmail.com on 13 Oct 2009 at 12:48

[GoogleCodeExporter]

Committing patch, review/vote at revision link below.

$ svn commit -m "Issue 124 ; adding new protected method void disposeImage, to 
allow
subclasses to override default behavior" swt
Sending        swt/src/main/java/edu/umd/cs/piccolox/swt/PSWTImage.java
Transmitting file data .
Committed revision 728.

Original comment by heue...@gmail.com on 15 Oct 2009 at 6:19

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by allain.lalonde on 30 Oct 2009 at 3:43

• Changed state: Verified