[piccolo2d-dev] Re: Getting closer to a 1.3.1 release
Issue 191. ...FRACTIONAL_METRICS on Windows... (http://goo.gl/06NiG) ** Summary: I'm proposing we do nothing for 1.3.* releases. And that we plan to invert our current behavior wrt fractional metrics in future/2.0 release. I'm ok with that. The PhET team may have stronger opinions. OK with PhET. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Issue 154 in piccolo2d: Zoom handler doesn't interact well with PSwing nodes
+1 for moving to 1.4. On Mar 20, 3:19 pm, piccol...@googlecode.com wrote: Comment #6 on issue 154 by atdi...@gmail.com: Zoom handler doesn't interact well with PSwing nodeshttp://code.google.com/p/piccolo2d/issues/detail?id=154 In the interest of a 1.3.1 release, I propose we move this to 1.4 milestone so we can give time for discussion of previous comment. I'll wait for votes (or absence of votes), and then move to a 1.4. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: changes to PPath, add PShape and PArea
Mac users are only 14% of PhET users; 83% are Windows. 80% of PhET's Mac users are on Intel, but most are running Mac OS 10.5. Mac OS 10.6 is the first version to install Java 1.6 as the default (and only) Java version. Mac OS 10.5 has both Java 1.5 and 1.6 installed, but Java 1.5 is the default. And we can't expect our users to change their Java configuration, they're not that savvy, and it would create a big support problem. So Java version is not really a PPC issue, and we're going to be supporting Java 1.5 on Mac for awhile. Windows is a little different, since Java isn't tightly integrated with the OS, like it is with Mac OS. But we've seen that our Windows users are slow to upgrade their Java. I don't have Java version numbers handy, but last time I looked I recall that Java 1.5 was still the majority. I think this may be typical of the educational market, since schools typically have policies about who can update software and when, so no one bothers until things break. And some of our international users only have access to older technology. Btw... PhET's user community is quite large. PhET had over 10 million simulations (Java and Flash) run from its website last year, with 34% of those users outside the USA, in 51 languages. And that's been growing ~35-50% per year since 2004. So Piccolo is helping to providing valuable educational tools to many users. On Jul 21, 9:23 am, Michael Heuer heue...@gmail.com wrote: cmal...@pixelzoom.com cmal...@pixelzoom.com wrote: PhET's customers are the educational market, which typically lags behind the technology curve. We only recently changed our minimum system requirement to include Java 1.5. So I suspect that it will be a long time (possibly years) before we change that requirement to Java 1.6, and only once we're confident that 5% of our users are using something earlier than Java 1.6. So requiring Java 1.6 for Piccolo 2.0 would mean that we would be unlikely to upgrade any time soon. Do you have those numbers for your current users? As far as I know Mac OSX on PowerPC is the only platform that doesn't have a 1.6 JDK available. That probably is a large percentage of the educational market though. I also understand that Piccolo 2.0 will contain breaking changes. Since we have many products that use Piccolo, breaking changes will also slow our upgrade. That said... If you think it's the right thing to do, then I think you should go for it, and require Java 1.6 for Piccolo 2.0. But we aware that PhET is unlikely to be an early adopter of Piccolo 2.0. And convincing PhET management that we should be involved in 2.0 development or testing may be a tough sell. I forsee the 1.3 branch having a long lifetime, since in addition to the package name change, there will be several breaking changes in 2.0. We just need to make sure that non-breaking changes on 2.0/trunk are also merged back into the 1.3 branch. michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3
Yes, if 163 were fixed, that would change my vote to +1. 163 is the only know problem with pswing. The other gripes I have with it are internals, and that can certainly wait. On Mar 9, 9:42 am, Michael Heuer heue...@gmail.com wrote: Chris wrote: This release is generally solid, with the exception of the pswing package. Since issue 163 has been reopened, and since I've investigated further, I think that pswing has some new problems that weren't in 1.2 (issue 163 being an example). I can't +1 the release, since my client (PhET) relies heavily on pswing. But I can't -1 the release because I think that fixing pswing and bringing it up to the same standards as the reset of Piccolo2D is going to take considerable time, and I hate to see 1.3 delayed any longer. If issue 163 were fixed, would that change your vote to +1? I wouldn't mind waiting 1.3 until that were the case. If anyone else feels strongly about pswing, then my lack of confidence in its current state may influence your vote. Otherwise, I think PhET should take the lead in fixing improving whatever version of pswing ships with 1.3. PhET uses it heavily, in some complex situations, and contributed it in (more or less) its current state. I would prefer to see PhET using a proper Piccolo2D release rather than maintaining a private fork, let us know what it will take to make that happen. michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3
--- [ ] +1 I support this release [ ] +0 [X] -0 [ ] -1 I oppose this release because... I'm going to abstain from this vote. This release is generally solid, with the exception of the pswing package. Since issue 163 has been reopened, and since I've investigated further, I think that pswing has some new problems that weren't in 1.2 (issue 163 being an example). I can't +1 the release, since my client (PhET) relies heavily on pswing. But I can't -1 the release because I think that fixing pswing and bringing it up to the same standards as the reset of Piccolo2D is going to take considerable time, and I hate to see 1.3 delayed any longer. If anyone else feels strongly about pswing, then my lack of confidence in its current state may influence your vote. Otherwise, I think PhET should take the lead in fixing improving whatever version of pswing ships with 1.3. PhET uses it heavily, in some complex situations, and contributed it in (more or less) its current state. On Mar 2, 8:57 pm, Michael Heuer heue...@gmail.com wrote: This is a vote for releasing Piccolo2D.Java 1.3 based on release candidate 4 (version 1.3-rc4). Since release candidate 3 new issues 163 and 165 have been fixed and verified. 1.3-rc4 is available from the downloads page: http://code.google.com/p/piccolo2d/downloads/list?can=2q=1.3-rc4 --- [ ] +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 Tuesday 09 March 2010. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Issue 166 in piccolo2d: Refactor PNode.moveToBack() and related
I realize this is z-ordering. But if this is supposed to replace the existing z-ordering interface, then raise and lower would be replacing moveToFrontOf(PNode) and moveInBackOf(PNode). So, again, how does raise and lower allow me to put one sibling in front/back of another sibling? Imho, this new interface proposal reduces the functionality of the interface, and (as Allain noted previously) makes make changing the z-order of siblings cumbersome, if not downright difficult. Chris On Feb 27, 1:00 pm, Samuel Robert Reid re...@colorado.edu wrote: raise and lower relative to what? This is regarding the z-ordering of child nodes within a parent node. Sam Reid -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3
My client (PhET) uses PSwing quite heavily. But I'm not going to -1 in order to get the 163 fix, for 3 reasons: (1) The consensus within PhET is that we're comfortable with patching our 1.3 copy to resolve 163. (2) Imho PSwing needs an internal overhaul, to bring the code up to the standards of Piccolo. Poor name choices is my biggest beef, luckily with private stuff. (3) There are additional PSwing issues that need to be resolved. We have not yet reported these, but are tracking them internally. The big 2 issues are focus traversal and memory leaks when PSwings are removed from the scenegraph. Chris On Feb 26, 4:16 pm, Michael Heuer heue...@gmail.com wrote: Michael Heuer wrote: Vote will close at 12:00 GMT Friday 26 February 2010. I would like to extend to vote deadline until Monday 01 March 2010 to allow for feedback on recently fixed issues 163 and 165. The current vote would pass as it stands and the fixes for those issues would not be released until a later version. michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3
I'm re-voting, based on our discussion in issue 161. --- [ ] +1 I support this release [ ] +0 [ ] -0 [ X] -1 I oppose this release because (as described in issue 161) full bounds behavior was changed by fixing issue 155. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: [VOTE] Release Piccolo2D.Java 1.3
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... -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3 failed
All 1.3-rc1 issues that I reported have been resolved. Many thanks! What is the timeline for 1.3-rc2, and are there any other issues still pending that must be resolved? Chris On Feb 1, 4:09 pm, cmal...@pixelzoom.com cmal...@pixelzoom.com wrote: See issue 160 for the endless series of events issue. All problems we've identified are now in the issues database. 158 and 159 are resolved. 160 is open. Chris On Feb 1, 11:03 am, cmal...@pixelzoom.com cmal...@pixelzoom.com wrote: An update on where we're at with the PSwing issues... Issue 158 was resolved by Allain last week, and fixed a couple of our problems. Issue 159 was opened a few minutes ago, and is related to PSwing transform/picking problems. I am still investigating one additional issue, where a PSwing Component is receiving an endless series of events that toggle its visibility on and off. As soon as I isolate, I'll create an issue. That summarizes all of the problems we've encountered with 1.3-rc1. Chris On Jan 28, 12:29 pm, Michael Heuer heue...@gmail.com wrote: The following people voted on release 1.3rc1: Michael Heuer +1 Allain Lalonde +1 Chris Malley -1 The vote failed since it did not receive at least three +1 binding votes and no -1 binding votes. New issues related to PSwing were discovered and are being addressed. Another release candidate (1.3rc2) will be created when these issues are closed and validated. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3 failed
An update on where we're at with the PSwing issues... Issue 158 was resolved by Allain last week, and fixed a couple of our problems. Issue 159 was opened a few minutes ago, and is related to PSwing transform/picking problems. I am still investigating one additional issue, where a PSwing Component is receiving an endless series of events that toggle its visibility on and off. As soon as I isolate, I'll create an issue. That summarizes all of the problems we've encountered with 1.3-rc1. Chris On Jan 28, 12:29 pm, Michael Heuer heue...@gmail.com wrote: The following people voted on release 1.3rc1: Michael Heuer +1 Allain Lalonde +1 Chris Malley -1 The vote failed since it did not receive at least three +1 binding votes and no -1 binding votes. New issues related to PSwing were discovered and are being addressed. Another release candidate (1.3rc2) will be created when these issues are closed and validated. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: r962 committed - Made PSwing.setVisible lazily call its component's setVisible method d...
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-dev] PSwing.readObject ?
Does anyone recall what the purpose of PSwing.readObject is? It's included in 1.3-rc1, but doesn't appear to be used. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: PSwing.readObject ?
Never mind, stupid question, required for serialization. I've clearly been working too long today... -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3
--- [ ] +1 I support this release [ ] +0 [ ] -0 [X] -1 I oppose this release because... PSwing appears to have some new problems, and PhET (my client) relies heavily on PSwing. Specifically: (1) Visibility issues; there are nodes that should be visible and are not, and vice-versa. (2) Bounds issues; computing PSwing offsets for the purposes of layout is resulting in additional whitespace. I've observed problem (1) in 3 applications, problem (2) in 1 application, on both Windows and Mac platforms. I've been trying to isolate the problems in small test applications, but have been unsuccessful so far. I'm going to continue with that effort a little longer, then have a look at PSwing changes. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: New team member introduction
I've built many simulations for the PhET project, and expect to build many more. As Sam Reid mentioned, I'm been a contractor for the PhET project for 5 years. Sam has been almost totally responsible for PSwing; my role has been mostly debugging, particularly on Mac. On Nov 1, 10:45 am, Allain Lalonde allain.lalo...@gmail.com wrote: 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, seewww.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: New team member introduction
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 -~--~~~~--~~--~--~---
