Re: [piccolo2d-dev] [piccolo2d] r1067 committed - JS: Adding moveToFront and moveToBack to PNode
No strong dislike either way.
It doesn't actually make it much clearer and seems like it's a rename for
its own sake.
I'll follow the convention that p2d.java goes with no matter my opinion, but
for now I'm just making it match.
On 1 September 2010 15:48, Michael Heuer heue...@gmail.com wrote:
Shoot, you don't like the new method names suggested in Issue 166? ;)
michael
On Wed, Sep 1, 2010 at 2:46 PM, piccol...@googlecode.com wrote:
Revision: 1067
Author: allain.lalonde
Date: Wed Sep 1 12:45:28 2010
Log: JS: Adding moveToFront and moveToBack to PNode
http://code.google.com/p/piccolo2d/source/detail?r=1067
Modified:
/piccolo2d.js/trunk/piccolo2d.js
/piccolo2d.js/trunk/test.html
===
--- /piccolo2d.js/trunk/piccolo2d.jsWed Sep 1 12:01:18 2010
+++ /piccolo2d.js/trunk/piccolo2d.jsWed Sep 1 12:45:28 2010
@@ -509,6 +509,32 @@
getScale: function() {
return this.transform.getScale();
+},
+
+moveToFront: function() {
+if (this.parent this.parent.children.length 1) {
+this.parent.children =
this.parent.children.remove(this);
+this.parent.children.push(this);
+
+this.invalidatePaint();
+}
+return this;
+},
+
+moveToBack: function() {
+if (this.parent this.parent.children.length 1) {
+var newSiblings = [this];
+for (var i=0, n = this.parent.children.length; in; i++)
{
+if (this.parent.children[i] != this) {
+ newSiblings.push(this.parent.children[i]);
+}
+}
+
+this.parent.children = newSiblings;
+
+this.invalidatePaint();
+}
+return this;
}
});
@@ -743,10 +769,10 @@
function dispatchEvent(type, event, pickedNodes) {
var currentNode, listener;
-for (var nodeIndex = 0; nodeIndex pickedNodes.length;
nodeIndex += 1) {
+for (var nodeIndex = 0, pickedNodeCount =
pickedNodes.length; nodeIndex pickedNodeCount; nodeIndex += 1) {
currentNode = pickedNodes[nodeIndex];
while (currentNode) {
-for (var i = 0; i
currentNode.listeners.length; i
+= 1) {
+for (var i = 0, listenerCount =
currentNode.listeners.length; i listenerCount; i += 1) {
listener = currentNode.listeners[i];
if (listener[type]) {
listener[type]({
===
--- /piccolo2d.js/trunk/test.html Wed Sep 1 12:01:18 2010
+++ /piccolo2d.js/trunk/test.html Wed Sep 1 12:45:28 2010
@@ -465,6 +465,36 @@
testNode.getFullBounds();
ok(layoutChildrenCalled, layoutChildren was not called);
});
+
+test(Move to front places child node at end of its parent's
children, function() {
+var a = new PNode();
+var b = new PNode();
+var parent = new PNode();
+parent.addChild(a);
+parent.addChild(b);
+a.moveToFront();
+same(parent.children[1], a);
+});
+
+test(Move to back places child node at front of its parent's
children, function() {
+var a = new PNode();
+var b = new PNode();
+var parent = new PNode();
+parent.addChild(a);
+parent.addChild(b);
+b.moveToBack();
+same(parent.children[0], b);
+});
+
+test(Move to front does nothing if child has no parent,
function() {
+var a = new PNode();
+a.moveToFront();
+});
+
+test(Move to back does nothing if child has no parent,
function()
{
+var a = new PNode();
+a.moveToBack();
+});
}
function testPRoot() {
--
Piccolo2D Developers Group:
http://groups.google.com/group/piccolo2d-dev?hl=en
--
Piccolo2D Developers Group:
http://groups.google.com/group/piccolo2d-dev?hl=en
--
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Porting Piccolo to Canvas
Hi Lucas, I'm glad someone else has some interest in pushing piccolo2d in that direction. You may want to take a look at the source code in the repo there's an entire branch dedicated to doing pretty much what you're talking about: http://code.google.com/p/piccolo2d/source/browse#svn/piccolo2d.js/trunk You may also want to see it in action at http://www.machete.ca/piccolo2d.js/ I'd love to collaborate on pushing it forward. Let me know, Allain Lalonde On May 4, 3:32 pm, lucasjordan lucasjor...@gmail.com wrote: I seem to have started down a possibly foolish path and I wanted to get some feedback. I have started porting Piccolo to the new HTML5 Canvas API. Mind you I am only a few hours into this, but here are my thoughts up to this point. After reviewing the Canvas API I noticed that it is rather similar to Graphics2D, which makes sense since it is solving a similar problem; writing raster graphics. I have not had the chance to do a feature by feature comparison, so there is probably something missing which will bit me down the road. After looking at the implementation of a number of the PNode subclasses, it looked to me like a number of them could use Canvas to accomplish at least a similar visual effect. Things like PImage and PPath looks like they should work and hopefully PText will work as well. I suspect PHtmlView will never work, but maybe that's ok. Basically I am using GWT to take as much of the Java Code from Piccolo2D and use the project gwt-canvas to provide the Graphics2D type functionality. Since Piccolo depends so heavily on java.awt and java.awt.geom and the awt packages are not supported in GWT I am including a copy of those source files in the GWT project. For example, Piccolo depends on java.awt.Rectangle, so I copy the existing Rectangle class to a java.gwt.Rectangle and simply change the import statement in the Piccolo code. Copying the awt classes looks like it is going to work in general but there are few problems which have shown themselves. First, most of the geometry type classes (Rectangle2D, Point2D, etc) only depend on them selves and java.lang.Math, so this makes them viable classes to be used with GWT, but some of them depends on internal sun.java.bla.bla.* classes, which I don't currently have the source code for. The second problem as I have not had a chance to review the legal issue in reusing Oracle's code in this way. I has occurred to me I might have better luck taking the code from Apache's project harmony, but again I have not gotten that far. For that matter I am not sure about altering the Piccolo2D code either. It is my intention to make all of the work I am going here as free as possible, so if someone has some experience with this, helping me make sure that everyone's licenses are being properly honored, please let me know. Another concern of mine is that Piccolo does a lot more than just draw a scene, it also provides node picking and other input events, I am not sure how well that is going to work. A HTML5 Canvas element is able to receive mouse and keyboard events, I just don't know if those will be descriptive enough work with the existing Piccolo APIs. Another issue is that JavaScript (which GWT code ultimately becomes) does not support a double precision floating point values. GWT allows you to use Java doubles in your code, but behind the scene they are actually using two single precision float values to store the data and they do some magic to manage those values for you. It is stated in the GWT docs that this includes some overhead. So, since I am basically copying all of the awt classes, I could just turn every double into a float and then do the same to the piccolo code I have not started doing this, but this is another topic I would like some feedback on. So those are basically my technical concerns up to this point. But you might be asking, why are you doing this? and basically it comes down creating a cross platform scene graph API. I have worked with Piccolo in the past and know that it is a solid scene graph API. I have also worked a lot with JavaFX and know that that brings an excellent scene graph API as well, plus it has properties and value binding, it is a real pleasure to work with. But both of these APIs are dependent on the presence of a modern JVM and frankly I don't see a real JVM showing up on the devices I want to develop for. But on all of the devices I want to developer for there is HTML5 compliant browser, this includes, all desktop computers, Apple's i products, set top boxes, Android and any other future google device, and many more. I considered SVG, which also has pretty good cross platform support, but there are limitations, especially coming from the Microsoft side of things which claim they will not be including the animation features. Anyway, thanks for reading all this, I would love to get a reality check here :) -Lucas
Re: [piccolo2d-dev] [VOTE] Release Piccolo2D.Java 1.3
yay On 18 February 2010 01:44, Michael Heuer heue...@gmail.com wrote: This is a vote for releasing Piccolo2D.Java 1.3 based on release candidate 3 (version 1.3-rc3). Since release candidate 2 the fix for issue 155 was rolled back and a new issue 161 has been fixed and verified. 1.3-rc3 is available from the downloads page: http://code.google.com/p/piccolo2d/downloads/list?can=2q=1.3-rc3 --- [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Votes from Piccolo2D project committers are binding, however votes from other contributors and users are welcomed. The vote must receive at least three +1 binding votes and no -1 binding votes. Vote will close at 12:00 GMT Friday 26 February 2010. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] [VOTE] Release Piccolo2D.Java 1.3
On 5 February 2010 02:34, Michael Heuer heue...@gmail.com wrote: This is a vote for releasing Piccolo2D.Java 1.3 based on release candidate 1 (version 1.3-rc2). 1.3-rc2 is available from the downloads page: http://code.google.com/p/piccolo2d/downloads/list?can=2q=1.3-rc2 --- [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Votes from Piccolo2D project committers are binding, however votes from other contributors and users are welcomed. The vote must receive at least three +1 binding votes and no -1 binding votes. Vote will close at 12:00 GMT Saturday 13 February 2010. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] Re: r962 committed - Made PSwing.setVisible lazily call its component's setVisible method d...
Reason for adding the component listener in PSwing's constructor was that during the creation of unit tests for it, a bizarre situation became obviously possible. Invisible PSwing node and visible JComponent or Visible PSwing and invisible JComponent. Rather than try to parse out the behaviour in those gray areas, I figured the best bet would be to make hiding/showing one, hide/show the other. I figured that some optimizations could be done at the JComponent level if it were aware that it were invisible (like unloading an image from memory, etc). If it's causing more problems than it's fixing I'm 100% for removing it. Try commenting out the ComponentListener registration in the constructor and see if the problem goes away. Thoughts? On 1 February 2010 16:24, cmal...@pixelzoom.com cmal...@pixelzoom.comwrote: I can't seem to reproduce this in a simple example. But in one of our applications, I see an endless series of calls to the ComponentListener that is added in PSwing's constructor. The calls alternate between componentShown and componentHidden. And there is nothing in the application code that appears to be triggering this, it keeps feeding back through PSwing.setVisible. So rather than continue to chase my tail on this, I'd like to discuss the motivation for adding this ComponentListener. What purpose is it serving? It seems unnecessary. And undesirable - should client code be able to call setVisible on a Component? And both this ComponentListener and the override of PSwing.setVisibile seem a little dangerous, given how the entire Swing approach works by parenting JComponents to PSwingCanvas.ChildWrapper. Also note that an additional ComponentListener is added in PSwing.initializeComponent, could this be creating problems, depending on the call order? It seems like there is component initialization going on in the constructor that should really be in initializeComponent. Thoughts anyone?... Chris On Jan 28, 3:46 pm, cmal...@pixelzoom.com cmal...@pixelzoom.com wrote: Thanks for being so responsive Allain! Unfortunately this change did not correct the problem. And it's actually unnecessary, since JComponent.setVisible is already a no-op if the visibility isn't changing. To clarify... I'm not seeing a stack overflow, but a continuous toggling between visible and invisible. And I'm still trying to reproduce the problem in a simple example. Chris On Jan 28, 8:05 am, piccol...@googlecode.com wrote: Revision: 962 Author: allain.lalonde Date: Thu Jan 28 07:04:37 2010 Log: Made PSwing.setVisible lazily call its component's setVisible method depending on its current visibility. This should stop the stack overflow being experienced by Chris Malley. Since I have been unable to reproduce it, I can't test it. http://code.google.com/p/piccolo2d/source/detail?r=962 [snip] -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] motivation for ComponentListener in PSwing constructor?
Test demonstrating the need for the callback is: PSwingTest.testHidingComponentHidesPSwing I believe the callback was introduced as an optimization (though it's been a while since the change). I will investigate further. On 27 January 2010 22:36, cmal...@pixelzoom.com cmal...@pixelzoom.comwrote: Looking at PSwing in 1.3-rc1 ... The constructor adds a ComponentAdapter that changes the visibility of the PSwing node as the Component is shown/hidden. Does anyone recall the motivation for adding this? Looking at the PSwing.setVisible override, this ComponentAdapter seems unnecessary, perhaps even a bit dangerous. If someone calls setVisible directly on the Component, will this change the visibility of the node? (The specifics of exactly when componentShow and componentHidden are called has always eluded me.) One of my applications is experiencing an endless circularity related to this. The calls look like: setVisible true componentHidden setVisible false componentShown setVisible true // ... etc forever I'm still trying to track this down, and it may be a client-code issue. But it wasn't an issue with earlier versions of PSwing, and demonstrates (I think) the potential danger of this ComponentAdapter. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] Re: r922 committed - Initial Piccolo2d port to Javascript....
Thanks Ben. Funny. Would it be too geeky to say no? I just did it to see how it might turn out and to see what other people would build with it. Hear hear for open source. 2010/1/12 Ben Bederson beder...@gmail.com Wow! That is amazing. Very cool! Do you have a specific project in mind that you are building this out for? - Ben On Jan 10, 7:31 pm, allain allain.lalo...@gmail.com wrote: As for now, no documentation exists. It is the first checkin on that branch after all :). Since there's no fancy JavaScript going on, I don't see why you couldn't invoke it directly from GWT. I haven't really considered packaging it for GWT, but now that you say it, it makes perfect sense. It has not yet been optimized at all, so if you do plan on making use of it, you may want to take that into account. Good luck, Allain On Jan 10, 7:20 pm, Ben Suter ben.su...@gmail.com wrote: Hi Allain, I'm glad someone has tackled this - it's been a few years since I used (the Java version of) Piccolo, but back then I was curious how long until it would be ported to JS. I've embedded Piccolo ZUI's in the browser as applets, but would love to go the plugin-free route. I checked out your examples. Do you have any documentation on how to get started using your library? In particular, do you think it would work well with GWT / do you think you might package it as a library for GWT? Thanks, Ben. On Jan 4, 12:16 pm, piccol...@googlecode.com wrote: Revision: 922 Author: allain.lalonde Date: Mon Jan 4 10:15:57 2010 Log: Initial Piccolo2d port to Javascript. It makes use of the canvas tag, which limits it to Chrome, Safari and Firefox for the time being, but there exist wrappers for IE (excanvas) and there's talk about supporting the HTML5 canvas tag in the next version. It currently supports the core functionality: - scene construction - activities.html - events (mouseup, mousedown, click, mousemove) I have tried (by using some John Resig code) to retain the basic feel of Piccolo2d even though JavaScript doesn't quite support object inheritance in the way most OO languages do. If you want to see it in action, take a look at http://www.machete.ca/piccolo2d.js/andbrowseto the examples.css There are still definitely some things missing so far, but I think this is a good start. http://code.google.com/p/piccolo2d/source/detail?r=922 Added: /piccolo2d.js /piccolo2d.js/branches /piccolo2d.js/tags /piccolo2d.js/trunk /piccolo2d.js/trunk/examples /piccolo2d.js/trunk/examples/activities.html /piccolo2d.js/trunk/examples/calendar.html /piccolo2d.js/trunk/examples/events.html /piccolo2d.js/trunk/examples/examples.css /piccolo2d.js/trunk/examples/hierarchy.html /piccolo2d.js/trunk/examples/sticky-nodes.html /piccolo2d.js/trunk/extends.js /piccolo2d.js/trunk/lib /piccolo2d.js/trunk/lib/javascript-1.6.js /piccolo2d.js/trunk/lib/jquery-1.3.2.min.js /piccolo2d.js/trunk/lib/qunit.css /piccolo2d.js/trunk/lib/qunit.js /piccolo2d.js/trunk/license-piccolo.txt /piccolo2d.js/trunk/piccolo2d.js /piccolo2d.js/trunk/test.html === --- /dev/null +++ /piccolo2d.js/trunk/examples/activities.htmlMon Jan 4 10:15:57 2010 @@ -0,0 +1,97 @@ +!-- +Copyright (c) 2008-2009, Piccolo2D project,http://piccolo2d.org +Copyright (c) 1998-2008, University of Maryland +All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are permitted provided +that the following conditions are met: + +Redistributions of source code must retain the above copyright notice, this list of conditions +and the following disclaimer. + +Redistributions in binary form must reproduce the above copyright notice, this list of conditions +and the following disclaimer in the documentation and/or other materials provided with the +distribution. + +None of the name of the University of Maryland, the name of the Piccolo2D project, or the names of its +contributors may be used to endorse or promote products derived from this software without specific +prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A +PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR +ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS
[piccolo2d-dev] Re: r922 committed - Initial Piccolo2d port to Javascript....
As for now, no documentation exists. It is the first checkin on that branch after all :). Since there's no fancy JavaScript going on, I don't see why you couldn't invoke it directly from GWT. I haven't really considered packaging it for GWT, but now that you say it, it makes perfect sense. It has not yet been optimized at all, so if you do plan on making use of it, you may want to take that into account. Good luck, Allain On Jan 10, 7:20 pm, Ben Suter ben.su...@gmail.com wrote: Hi Allain, I'm glad someone has tackled this - it's been a few years since I used (the Java version of) Piccolo, but back then I was curious how long until it would be ported to JS. I've embedded Piccolo ZUI's in the browser as applets, but would love to go the plugin-free route. I checked out your examples. Do you have any documentation on how to get started using your library? In particular, do you think it would work well with GWT / do you think you might package it as a library for GWT? Thanks, Ben. On Jan 4, 12:16 pm, piccol...@googlecode.com wrote: Revision: 922 Author: allain.lalonde Date: Mon Jan 4 10:15:57 2010 Log: Initial Piccolo2d port to Javascript. It makes use of the canvas tag, which limits it to Chrome, Safari and Firefox for the time being, but there exist wrappers for IE (excanvas) and there's talk about supporting the HTML5 canvas tag in the next version. It currently supports the core functionality: - scene construction - activities.html - events (mouseup, mousedown, click, mousemove) I have tried (by using some John Resig code) to retain the basic feel of Piccolo2d even though JavaScript doesn't quite support object inheritance in the way most OO languages do. If you want to see it in action, take a look at http://www.machete.ca/piccolo2d.js/andbrowse to the examples.css There are still definitely some things missing so far, but I think this is a good start. http://code.google.com/p/piccolo2d/source/detail?r=922 Added: /piccolo2d.js /piccolo2d.js/branches /piccolo2d.js/tags /piccolo2d.js/trunk /piccolo2d.js/trunk/examples /piccolo2d.js/trunk/examples/activities.html /piccolo2d.js/trunk/examples/calendar.html /piccolo2d.js/trunk/examples/events.html /piccolo2d.js/trunk/examples/examples.css /piccolo2d.js/trunk/examples/hierarchy.html /piccolo2d.js/trunk/examples/sticky-nodes.html /piccolo2d.js/trunk/extends.js /piccolo2d.js/trunk/lib /piccolo2d.js/trunk/lib/javascript-1.6.js /piccolo2d.js/trunk/lib/jquery-1.3.2.min.js /piccolo2d.js/trunk/lib/qunit.css /piccolo2d.js/trunk/lib/qunit.js /piccolo2d.js/trunk/license-piccolo.txt /piccolo2d.js/trunk/piccolo2d.js /piccolo2d.js/trunk/test.html === --- /dev/null +++ /piccolo2d.js/trunk/examples/activities.html Mon Jan 4 10:15:57 2010 @@ -0,0 +1,97 @@ +!-- +Copyright (c) 2008-2009, Piccolo2D project,http://piccolo2d.org +Copyright (c) 1998-2008, University of Maryland +All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are permitted provided +that the following conditions are met: + +Redistributions of source code must retain the above copyright notice, this list of conditions +and the following disclaimer. + +Redistributions in binary form must reproduce the above copyright notice, this list of conditions +and the following disclaimer in the documentation and/or other materials provided with the +distribution. + +None of the name of the University of Maryland, the name of the Piccolo2D project, or the names of its +contributors may be used to endorse or promote products derived from this software without specific +prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A +PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR +ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR +TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF +ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +-- +html + head + titleActivities Example - Piccolo2d.js/title + link rel=stylesheet href=examples.css / + /head + body + canvas id=canvas width=400 height=400 + pNo Canvas Support in this browser./p + /canvas + script type=text/javascript src=../lib/javascript-1.6.js/script
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
Right. This is the default behaviour for repaint() on a Node. it will group
all the repaint requests together that occur within a UI Cycle.
2009/11/3 Nigel nigel.tamp...@f2s.com
I agree, my interpretation is that calling invalidatePaint should
result in a repaint sometime soon after.
This differs from Piccolos current (wrong?) behaviour whereby calling
invalidatePaint does not result in a repaint (unless some other event
triggers the repaint).
My gut feel is that there's a timer missing somewhere.
It seems the invalidatePaint() message propagates up the node
hierarchy to the PLayer, but is then ignored by the camera, whereas I
think the camera should notice the invalidatePaint and if after a
reasonable time delay (say 1/10th second) should trigger a repaint if
a repaint hasn't already occurred anyway.
This would allow Piccolo to combine multiple paints into fewer paints,
especially effective when large numbers of overlapping nodes all need
to be redrawn at about the same time.
Nigel
On Nov 3, 6:03 am, Michael Heuer heue...@gmail.com wrote:
I think this is supposed to be analogous to the AWT
Component.invalidate() method
http://java.sun.com/javase/6/docs/api/java/awt/Container.html#invalid...
A client might call invalidatePaint() a lot of times before an actual
repaint happens.
michael
Allain Lalonde wrote:
It would seem that indeed, this behavior is intended, though I can't
see
why?
invalidatePaint() is used to flag nodes as needing a repaint, but the
method
that is primarily responsible for making use of that flag is
validateFullPaint() which is only gets called from
PRoot.processInputs().
It seems that calling repaint does the same thing, but is correctly
handled
by Swing since it you follow the execution path ultimately, it ends up
callingin 'component.repaint(...);'.
Can someone shed some light on why this is the way it's written?
It would seem to me that a call to repaint() is needed at the end of
invalidatePaint() so that the need for repainting bubbles up to the
underlying Component.
2009/11/2 Allain Lalonde allain.lalo...@gmail.com
Good eye, invalidate paint just flags the node as needing to be
repainted. This gets picked up on the next ui cycle. I don't believe
that it will automatically bubble up the stack, though i will need to
re-read the code to confirm this. I will examine your code when i get
home to see if i can repelicate your issue.
Thank you for bringing this up.
On 02/11/2009, Nigel nigel.tamp...@f2s.com wrote:
The comment in PNode.java reads
// When you do create you own nodes the only method that you
will
// normally need to call is invalidatePaint. This method marks
the
// nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are
occurring
(such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the
node
being repainted some time later - am I doing something wrong or is
Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks
are
updated from another thread. The 2 clocks on the left are redrawn
via
a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new
GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
Great :) No need to change anything.
2009/11/3 nls...@googlemail.com
The problem seems to be caused by updating the scene graph by a thread
other than the Swing event dispatch thread. This is not allowed, a
solution is explained in the Piccolo2D Patterns.
A consequence of updates by wrong threads is that PRoot discards the
update and repaint process (it checks if the right thread invoked the
update). Subsequent invalidatePaints possibly dont reach the root.
Am Dienstag 03 November 2009 02:36:21 schrieb Nigel:
The comment in PNode.java reads
// When you do create you own nodes the only method that you
will // normally need to call is invalidatePaint. This method marks
the // nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are
occurring (such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the
node being repainted some time later - am I doing something wrong
or is Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks
are updated from another thread. The 2 clocks on the left are
redrawn via a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public void paint(PPaintContext aPaintContext) {
Graphics2D g2 =
(Graphics2D)aPaintContext.getGraphics().create();
// create - as we mess with the transform
g2.setPaint(Color.BLACK);
//draw the face
g2.draw( new Ellipse2D.Double( getX(), getY(), getWidth(),
getHeight () ));
//draw the second hand
g2.translate(getX()+getWidth()/2,getY()+getHeight()/2); //
translate hand so 0,0 is centre of bounds
g2.scale(getWidth()/2,getHeight()/2); // scale the needle
g2.rotate ( Math.toRadians((tseconds*6)/10f+180) );
g2.fill(secondHand);
}
public static void main(String args[]) {
// top left clock - uses repaint
final ClockNode clockNode1 = new ClockNode(true);
clockNode1.setBounds(0,0,200,200);
// top right clock - uses invalidatePaint
final ClockNode clockNode2 = new ClockNode(false);
clockNode2.setBounds(210,0,200,200);
// lower left clock - uses repaint
final ClockNode clockNode3 = new ClockNode(true);
clockNode3.setBounds(0,210,200,200);
// lower right clock - uses invalidatePaint
final ClockNode clockNode4 = new ClockNode(false);
clockNode4.setBounds(210,210,200,200);
PFrame pFrame = new PFrame() {
public void initialize() {
getCanvas().getLayer().addChild(clockNode1);
getCanvas().getLayer().addChild(clockNode2);
getCanvas().getLayer().addChild(clockNode3);
getCanvas().getLayer().addChild(clockNode4);
setSize(500,500);
}
};
// tick clocks 1 and 2 in the event dispatch thread
new javax.swing.Timer(100, new
java.awt.event.ActionListener() {
public void actionPerformed
(java.awt.event.ActionEvent evt) {
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
Good eye, invalidate paint just flags the node as needing to be
repainted. This gets picked up on the next ui cycle. I don't believe
that it will automatically bubble up the stack, though i will need to
re-read the code to confirm this. I will examine your code when i get
home to see if i can repelicate your issue.
Thank you for bringing this up.
On 02/11/2009, Nigel nigel.tamp...@f2s.com wrote:
The comment in PNode.java reads
// When you do create you own nodes the only method that you will
// normally need to call is invalidatePaint. This method marks the
// nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are occurring
(such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the node
being repainted some time later - am I doing something wrong or is
Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks are
updated from another thread. The 2 clocks on the left are redrawn via
a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public void paint(PPaintContext aPaintContext) {
Graphics2D g2 =
(Graphics2D)aPaintContext.getGraphics().create(); //
create - as we mess with the transform
g2.setPaint(Color.BLACK);
//draw the face
g2.draw( new Ellipse2D.Double( getX(), getY(), getWidth(),
getHeight
() ));
//draw the second hand
g2.translate(getX()+getWidth()/2,getY()+getHeight()/2); //
translate
hand so 0,0 is centre of bounds
g2.scale(getWidth()/2,getHeight()/2); // scale the needle
g2.rotate ( Math.toRadians((tseconds*6)/10f+180) );
g2.fill(secondHand);
}
public static void main(String args[]) {
// top left clock - uses repaint
final ClockNode clockNode1 = new ClockNode(true);
clockNode1.setBounds(0,0,200,200);
// top right clock - uses invalidatePaint
final ClockNode clockNode2 = new ClockNode(false);
clockNode2.setBounds(210,0,200,200);
// lower left clock - uses repaint
final ClockNode clockNode3 = new ClockNode(true);
clockNode3.setBounds(0,210,200,200);
// lower right clock - uses invalidatePaint
final ClockNode clockNode4 = new ClockNode(false);
clockNode4.setBounds(210,210,200,200);
PFrame pFrame = new PFrame() {
public void initialize() {
getCanvas().getLayer().addChild(clockNode1);
getCanvas().getLayer().addChild(clockNode2);
getCanvas().getLayer().addChild(clockNode3);
getCanvas().getLayer().addChild(clockNode4);
setSize(500,500);
}
};
// tick clocks 1 and 2 in the event dispatch thread
new javax.swing.Timer(100, new java.awt.event.ActionListener() {
public void actionPerformed
(java.awt.event.ActionEvent evt) {
clockNode1.tick();
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
It would seem that indeed, this behavior is intended, though I can't see
why?
invalidatePaint() is used to flag nodes as needing a repaint, but the method
that is primarily responsible for making use of that flag is
validateFullPaint() which is only gets called from PRoot.processInputs().
It seems that calling repaint does the same thing, but is correctly handled
by Swing since it you follow the execution path ultimately, it ends up
callingin 'component.repaint(...);'.
Can someone shed some light on why this is the way it's written?
It would seem to me that a call to repaint() is needed at the end of
invalidatePaint() so that the need for repainting bubbles up to the
underlying Component.
2009/11/2 Allain Lalonde allain.lalo...@gmail.com
Good eye, invalidate paint just flags the node as needing to be
repainted. This gets picked up on the next ui cycle. I don't believe
that it will automatically bubble up the stack, though i will need to
re-read the code to confirm this. I will examine your code when i get
home to see if i can repelicate your issue.
Thank you for bringing this up.
On 02/11/2009, Nigel nigel.tamp...@f2s.com wrote:
The comment in PNode.java reads
// When you do create you own nodes the only method that you will
// normally need to call is invalidatePaint. This method marks the
// nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are occurring
(such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the node
being repainted some time later - am I doing something wrong or is
Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks are
updated from another thread. The 2 clocks on the left are redrawn via
a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public void paint(PPaintContext aPaintContext) {
Graphics2D g2 =
(Graphics2D)aPaintContext.getGraphics().create(); //
create - as we mess with the transform
g2.setPaint(Color.BLACK);
//draw the face
g2.draw( new Ellipse2D.Double( getX(), getY(), getWidth(),
getHeight
() ));
//draw the second hand
g2.translate(getX()+getWidth()/2,getY()+getHeight()/2); //
translate
hand so 0,0 is centre of bounds
g2.scale(getWidth()/2,getHeight()/2); // scale the needle
g2.rotate ( Math.toRadians((tseconds*6)/10f+180) );
g2.fill(secondHand);
}
public static void main(String args[]) {
// top left clock - uses repaint
final ClockNode clockNode1 = new ClockNode(true);
clockNode1.setBounds(0,0,200,200);
// top right clock - uses invalidatePaint
final ClockNode clockNode2 = new ClockNode(false);
clockNode2.setBounds(210,0,200,200);
// lower left clock - uses repaint
final ClockNode clockNode3 = new ClockNode(true);
clockNode3.setBounds(0,210,200,200);
// lower right clock - uses invalidatePaint
final ClockNode clockNode4 = new ClockNode(false);
clockNode4.setBounds(210,210,200,200);
PFrame pFrame = new PFrame() {
public void initialize
[piccolo2d-dev] Re: New team member introduction
Hey Chris! Glad to have you aboard! What kinds of things are you planning to build or have already built with piccolo? If you're responsible for any of the pswing improvements, then I tip my hat to you sir. Look forward to working with you, Allain Lalonde Sent from my iPod On Oct 30, 2009, at 8:21 PM, cmal...@pixelzoom.com cmal...@pixelzoom.com wrote: Thanks Sam, glad to be aboard, looking for to more Piccolo use and contribution. If anyone is interested in my background, see www.pixelzoom.com. My company is named PixelZoom, after the overloaded and misunderstood OpenGL function, which is how I often feel ;-) Chris On Oct 30, 6:13 pm, Samuel Robert Reid re...@colorado.edu wrote: I'd like to introduce our newest team member, Chris Malley. I've been working with him for over 5 years now on piccolo-based science eduction projects athttp://phet.colorado.edu/, and he's provided several key bug reports and patches for Piccolo. He also has an excellent sense of user interface design, and a great understanding of Piccolo's API and implementation. So welcome aboard, Chris! Sam Reid --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: TooltipExample.java event.getPickedNode()
Thank you very much for pointing that out. It has now been fixed in the trunk. http://code.google.com/p/piccolo2d/source/detail?r=813 2009/10/23 Nigel nigel.tamp...@f2s.com I notice that the following line in TooltipExample.java final PNode n = event.getInputManager().getMouseOver().getPickedNode (); Could be rewritten simply as: final PNode n = event.getPickedNode(); --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Handle Strangeness
The following unit test passes but I'm pretty sure it shouldn't. Can
someone explain to me the rationale behind this?
This particular test is for the SWT module, but looking at the code in
the core for handles, it's the same there.
Shouldn't the locator change to match the handle's new parent? Maybe
not in the general case, but when the parent and the node pointed to
in the locator are the same, shouldn't it then?
public void testChangingParentDoesNotChangeLocatorNode() {
if (hasHead()) {
PNode node = new PNode();
PLocator locator = PBoundsLocator.createEastLocator(node);
PSWTHandle handle = new PSWTHandle(locator);
node.addChild(handle);
node.setBounds(0, 0, 100, 100);
handle.relocateHandle();
PNode newParent = new PNode();
newParent.setBounds(50, 50, 100, 100);
final double originalX = handle.getX();
handle.setParent(newParent);
final double newX = handle.getX();
assertEquals(newX, originalX, Double.MIN_VALUE);
}
}
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] Re: .Net version: tasks for 1.3?
That's great! In regards to the solution files, I think that's fine as long as there's a no fuss way of building it that won't scare away novice developers. If it's does, then we might want to keep around the VS.NET 2003 project and then just letting the IDE upgrade it on first open. As for the Direct3D stuff, since Piccolo2d.java doesn't do any hardware acceleration by default, I don't see it as critical to the .NET stuff. Allain 2009/8/15 Mark mtt...@gmail.com Update: As a test I built piccolo, piccolox, and piccolo features with nant and mono on win xp and everything seems to work (with zero code changes (!)). So now I'll start working on the nant build for everything. I also plan to test on Ubuntu. I have a some questions though: 1) should we keep the visual studio solution and project files? They seem to be VS 2003 or VS 2005 and VS 2008 will convert them to VS 2008 (which I have) format making them unusable to previous versions. I think it's an unnecessary burden to be tied to 'the latest and greatest' VS. Besides maintaining a nant build and an IDE build is extra work. 2) I don't plan on supporting the Direct3D stuff, I'm okay with dropping support for that. -Mark On Aug 12, 11:13 am, Michael Heuer heue...@gmail.com wrote: Mark wrote: Regarding issue 115: http://code.google.com/p/piccolo2d/issues/detail?id=115 What task are needed to for the .Net version and the Piccolo 2D 1.3 release? There were a few bugs reported for the 1.2 release, so those would need fixed. All the milestones in the issue tracker for 1.3 are for the Java version. My interest: I have a project coming up later this year in which I plan to use Piccolo.Net and I would like to see it stay current with the other versions. So I'm willing to make some time to keep it current. Most important in my mind is http://code.google.com/p/piccolo2d/issues/detail?id=60 The Piccolo2D devs can't work on the .Net version if we can't build it. None of the.Net issues have been assigned a version since we are unable to evaluate them. After that, the general tasks would be: Update the copyright/license headers Create a build process that can be automated (with NAnt, I suppose) Start creating a unit test suite (NUnit) Add build tools for calculating source code metrics, if available Evaluate issues fixed in Piccolo2D.Java since 1.2 to see if they are applicable to .Net versions Document a release process for .Net artifacts If there isn't much to fix in the .Net codebase other than the build stuff, we could release a version 1.2.1 fairly quickly. michael --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: [piccolo2d] r628 commited - FingBugs Hunting.
Yes they should be protected, should you do it? No. Not until 2.0 at least since client code that calls it directly would break. If you want to do it anyway, I'm all for it, but since we're not marking constants as final till 2.0, this one seems like a no go till then either. On Jul 30, 4:31 pm, Michael Heuer heue...@gmail.com wrote: snip /piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/pswing/PSwin g.java /** * The cutoff at which the Swing component is rendered greek */ - private final double renderCutoff = 0.3; + private static final double GREEK_SCALE_CUT_OFF = 0.3d; Similar values in PText are called greekThreshold and DEFAULT_GREEK_THRESHOLD. PText also has get/setGreekThreshold. private JComponent component = null; private double minFontSize = Double.MAX_VALUE; - private Stroke defaultStroke = new BasicStroke(); + private transient Stroke defaultStroke = new BasicStroke(); private Font defaultFont = new Font(Serif, Font.PLAIN, 12); Should these defaults be static and final? Strange that PSwing overrides protected void paint(PPaintContext) with public void paint(PPaintContext). I recommend refactoring to public void paint(PPaintContext) -- protected void paint(PPaintContext) public void paintAsGreek(Graphics2D) -- protected void paintGreek(PPaintContext) public void paint(Graphics2D) -- protected void paintComponent(PPaintContext) Subclasses might want access to the entire paint context for paintGreek and paintComponent, not just the graphics. I wonder how much work this change would be though. . . michael --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Issue 110 in piccolo2d: Syntactical code clean
err replace good development process with strict development process On Jul 28, 9:45 am, allain allain.lalo...@gmail.com wrote: final on parameters protects us from writing to them from within methods. FindBugs and PMD (I think) both flag this behaviour as problematic and catch many others in the process. If, and it's a big one, we target reducing the # of warnings being flagged by these tools, bugs introduced by not having final get caught anyway (along with countless others). I think adding final in a context where FindBugs failures breaks the build is unnecessary. That said, adding final to parameters doesn't hinder anything, it just adds verbosity for something that FindBugs and PMD would both disallow anyway. Not dead set against it, and the code will end up higher quality in the end no matter, I'm just stating my dislike for blanket covering a codebase with final when it's not necessary with a good development process. Just my 2 cents. On Jul 28, 8:42 am, codesite-nore...@google.com wrote: Comment #3 on issue 110 by samrreid: Syntactical code cleanhttp://code.google.com/p/piccolo2d/issues/detail?id=110 I presume that (3) doesn't entail making any classes or non-private methods final (none should be). What reasons has allain.lalonde given for not using 'final' where possible? They don't appear in this thread. I agree that final parameters and variables (and fields where possible) are safer than the mutable form, and that it is worth the increase in verbosity. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at:http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] HTMLNode
The code here: http://groups.google.com/group/piccolo2d-users/browse_thread/thread/25835a96a5d921e7/6cf577a995557268?q=HTMLNode+piccolo#6cf577a995557268 Should definitely be considered for inclusion in Extras. For rendering styled text, it's far better (or at least simpler) then trying to hack something together with PStyledText and it's very fast since the guys at sun seem to have optimized the heck out of the HTMLView stuff. (I'll attest to having over a thousand HTML nodes on screen without even a hiccup). Thoughts? --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: [piccolo2d commit] r520 - Unit tests
accidental, I was trying to figure out a way of unit testing the generated path, but failed. Forgot to change it back. 2009/7/20 Michael Heuer heue...@gmail.com On Sun, Jul 19, 2009 at 6:58 PM, codesite-nore...@google.com wrote: Author: allain.lalonde Date: Sun Jul 19 16:56:41 2009 New Revision: 520 piccolo2d.java/trunk/core/src/main/java/edu/umd/cs/piccolo/nodes/PPath.java (original) +++ piccolo2d.java/trunk/core/src/main/java/edu/umd/cs/piccolo/nodes/PPath.java Sun Jul 19 16:56:41 2009 @@ -102,7 +102,7 @@ private static final BasicStroke DEFAULT_STROKE = new BasicStroke(1.0f); private static final Color DEFAULT_STROKE_PAINT = Color.black; -private transient GeneralPath path; +protected transient GeneralPath path; What is the motivation for making this a protected field? michael --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Issue 83 in piccolo2d: PSwing are fuzzy when scale!=1, due to buffering of the PSwing
Thanks, does text jump when zooming? On mac? On 7/18/09, codesite-nore...@google.com codesite-nore...@google.com wrote: Comment #16 on issue 83 by mr0...@mro.name: PSwing are fuzzy when scale!=1, due to buffering of the PSwing http://code.google.com/p/piccolo2d/issues/detail?id=83 great, I added a pCanvas.getCamera().scale(0.98f); at line 171 - the result looks great to me. Shots attached. Attachments: PSwingExample1-scale-100.png 85.6 KB PSwingExample1-scale-098.png 100 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Sent from my mobile device --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Issue 101 in piccolo2d: Eliminate printStackTrace
Agreed On 7/18/09, codesite-nore...@google.com codesite-nore...@google.com wrote: Comment #5 on issue 101 by mr0...@mro.name: Eliminate printStackTrace http://code.google.com/p/piccolo2d/issues/detail?id=101 I vote against a generic, non-abstract PPiccoloException - if required we should use fine-grained ones with clear semantic meaning (as discussed with the NonInvertible topic). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Sent from my mobile device --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: r484 - no log message
Sorry, this change was just a refactoring of the examples project to conform to the naming rules in place. On Jul 17, 9:40 am, codesite-nore...@google.com wrote: Author: allain.lalonde Date: Fri Jul 17 06:39:05 2009 New Revision: 484 Added: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/ - copied from r483, /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/pswingexamp les/ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt / - copied from r483, /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/swtexamples / Removed: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/pswingexampl es/ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/swtexamples/ Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample1.java piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample2.java piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBasicExample.java piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBenchTest.java piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTHelloWorld.java Log: Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample1.java === === --- /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/pswingexamp les/PSwingExample1.java (original) +++ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample1.java Fri Jul 17 06:39:05 2009 @@ -26,7 +26,7 @@ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -package edu.umd.cs.piccolo.pswingexamples; +package edu.umd.cs.piccolo.examples.pswing; import java.awt.Color; import java.awt.Dimension; Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample2.java === === --- /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/pswingexamp les/PSwingExample2.java (original) +++ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/psw ing/PSwingExample2.java Fri Jul 17 06:39:05 2009 @@ -26,7 +26,7 @@ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -package edu.umd.cs.piccolo.pswingexamples; +package edu.umd.cs.piccolo.examples.pswing; import java.awt.BorderLayout; import java.awt.Color; Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBasicExample.java === === --- /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/swtexamples /SWTBasicExample.java (original) +++ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBasicExample.java Fri Jul 17 06:39:05 2009 @@ -26,7 +26,7 @@ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -package edu.umd.cs.piccolo.swtexamples; +package edu.umd.cs.piccolo.examples.swt; import java.awt.Color; Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBenchTest.java === === --- /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/swtexamples /SWTBenchTest.java (original) +++ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTBenchTest.java Fri Jul 17 06:39:05 2009 @@ -26,7 +26,7 @@ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -package edu.umd.cs.piccolo.swtexamples; +package edu.umd.cs.piccolo.examples.swt; import java.util.Random; import java.io.*; Modified: piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTHelloWorld.java === === --- /piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/swtexamples /SWTHelloWorld.java (original) +++ piccolo2d.java/trunk/examples/src/main/java/edu/umd/cs/piccolo/examples/swt /SWTHelloWorld.java Fri Jul 17 06:39:05 2009 @@ -26,7 +26,7 @@ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
[piccolo2d-dev] Re: Should we disallow NonInvertible Transforms in PAffineTransform?
Thought of another reason for doing this. Failing early would make it easier to hunt down bugs at the source, as opposed to later when walking the scene graph. 2009/7/17 allain allain.lalo...@gmail.com It'd be easy enough to make it check for this at construction time and then throw an Exception. It's such a prerequisite for walking the coordinate systems, that it should be disallowed. Anyone agree? --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Any objections to me adding Cobertura coverage report to the Maven Build?
I do mean such a thing. I'm not used to having the parent's pom file split into a subdirecty. My bad. Thanks. On Jul 16, 5:54 am, Marcus Rohrmoser mr0...@mro.name wrote: now it's me who can't follow. Cobertura? You don't mean such a thing:http://files.getdropbox.com/u/965005/piccolo2d.java/site-stage/piccol... - do You? That's part of the mvn build ever since. M --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: What's with all the paramStrings?
super.toString().replaceAll(.*\\., ) is used to strip away package names from the default toString implementation. 2009/7/15 Samuel Robert Reid re...@colorado.edu I don't see any advantage of the way toString is factored into a paramString part, and I've never used paramString directly in any of my piccolo2d client code, so I'd be okay with this getting refactored . Also, what's the reason for the: String result = super.toString().replaceAll(.*\\., ); in the first line of the PNode.toString? Sam Reid allain wrote: Most of the comments on them sound exactly like what toString is designed for. toString() should only ever be used for providing a better debug output on an object. --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] What's up with new PBounds(Point2D, double, double)
Here's the definition:
public PBounds(Point2D aCenterPoint, double insetX, double insetY)
{
this(aCenterPoint.getX(), aCenterPoint.getY(), 0, 0);
inset(insetX, insetY);
}
The only place it's called from from within the framework is:
public PPickPath pick(double x, double y, double halo) {
PBounds b = new PBounds(new Point2D.Double(x, y), -halo, -
halo);
...
What the hell is that?
If you pass it, what I consider pretty reasonable values of new PBounds
(new Point2D.Double(), 10, 10);
I'd expect to get a square with -10, -10 as its top left and a width/
height of 20, what you get instead is a square located at 10, 10 with
a width/height of -20.
Uh... maybe this should be written to guarantee a positive width,
height, which would remove the requirement to negate the insets every
time you want to use this constructor.
Thoughts?
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] isEmpty in PBounds
Is it just me or does isEmpty seem to act more like a dirty flag than as a statement about a bounds emptiness? --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Hudson server in my basement
I've setup a hudson server in my basement that performs a build anytime a check in occurs. It's having some troubles, but I'll gladly give admin rights to any developers who'd like to configure it (I'm not having much luck I think) Just create an account and email me your username, I'll bump your account up to admin. Hopefully someone can configure it to build properly. http://allain.homelinux.org:2121/ --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Issue 83 in piccolo2d: PSwing are fuzzy when scale!=1, due to buffering of the PSwing
I don't have access to a mac but would someone with access to it
please try replacing PSwing's paint method with the following and
telling me if it works?
public void paint(Graphics2D g2) {
if (component.getBounds().isEmpty()) {
// The component has not been initialized yet.
return;
}
PSwingRepaintManager manager = (PSwingRepaintManager)
RepaintManager.currentManager(component);
manager.lockRepaint(component);
RenderingHints oldHints = g2.getRenderingHints();
g2.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS,
RenderingHints.VALUE_FRACTIONALMETRICS_OFF);
component.paint(g2);
g2.setRenderingHints(oldHints);
manager.unlockRepaint(component);
}
Thank you.
On Jul 14, 1:24 am, codesite-nore...@google.com wrote:
Comment #5 on issue 83 by samrreid: PSwing are fuzzy when scale!=1, due to
buffering of the PSwinghttp://code.google.com/p/piccolo2d/issues/detail?id=83
My team and I tried removing buffering from PSwing; however, it caused a
problem that
some swing components (buttons, labels, etc) rendered with a '...' on Mac.
That is,
instead of a button reading Press Me, on a Mac, some unbuffered PSwings
would read
something like Press M So we have re-enabled buffering in PSwing in
our local
copy and recommend not disabling buffering until this problem is resolved.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences
at:http://code.google.com/hosting/settings
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] Hello everyone
Hi. My name is Allain Lalonde and I have a programming problem. I like to do it. A lot. The kind of programming I like to do it test centric. I get squeamish if the coverage by quality tests gets too low. Though I have been known to wing it. What I'm hoping to contribute toward: - Unit Testing, in fact in the long term I'd basically like to be given control of the tests, since it's something I'm pretty good at doing - Generics Support (a biggie for me since other than mainframe and mobile apps, I don't trust libraries that aren't at least 1.5... bad mojo) - Clean up of the serialization code (including clone) - Usability of the PStyledText stuff (It's a little hard to use, to say the least). I'm open to criticism, and will try not to step on anyone's toes. If you don't like what I'm doing, safe to assume it's because I don't know better, not malice. I've basically been operating a 1 person shop and in that environment Checkin is all about backing the code up, not much else. So, if you need merging/branching, etc, I'm probably not the best person to be helping out with that stuff. Anyway, Piccolo is a great library, and I'll do whatever I can to make it better. My dream would be to have a complete zoomable interface to my computer... period. And I think contributing here is my best bet at getting it the way I want it. Minority report anyone? Can't wait to work with you all, Allain Lalonde (Ottawa, Ontario, Canada) --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: Issue 12 in piccolo2d: Generics Support
Woohoo! Thanks a bunch. I'll use the confidence prudently. :) On Jul 12, 6:11 pm, Stephen Chin s...@browsecode.org wrote: Sounds like a good plan to me. The only projects I know of today that are stuck on 1.4 support are running on modified versions of Java for mainframes. By the way, I hope no one objects, but I have added Allain as a project committer... :-) Cheers, --Steve On 7/10/2009 12:52 PM, Samuel Robert Reid wrote: One effective way to obtain a vote would be to: 1. branch now (leaving generics in HEAD and 1.4 as an old branch) 2. publish a new version of piccolo with generics and 1.5 dependencies 3. see how many people complain If there is an overwhelming response that we need to keep up significant support for 1.4, we can always focus our efforts on the branch, or just revert HEAD to the 1.4 branch. Sam Reid allain wrote: If this is the direction the project wants to go in, I'd more than gladly make the changes to the rest of the code base. Just want to know that it won't be wasted effort. When will we have a result for this vote? On Jul 8, 4:04 pm,codesite-nore...@google.com wrote: Comment #11 on issue 12 by willismorse: Generics Supporthttp://code.google.com/p/piccolo2d/issues/detail?id=12 I vote for adding generics. We're almost ready to drop support for 1.5 in our products; 1.4 has been off our radar for a couple years now. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at:http://code.google.com/hosting/settings smime.p7s 4KViewDownload --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
