Closed GoogleCodeExporter closed 9 years ago
Original comment by heue...@gmail.com
on 4 Sep 2009 at 3:13
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
Original comment by akurta...@gmail.com
on 22 Sep 2009 at 2:54
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
[deleted comment]
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
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
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
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
Original comment by allain.lalonde
on 30 Oct 2009 at 3:43
Original issue reported on code.google.com by
heue...@gmail.com
on 4 Sep 2009 at 3:09