Sounds good to me,
Sam Reid
On 10/18/2010 3:33 PM, cmal...@pixelzoom.com wrote:
+1
On Oct 17, 8:56 pm, Michael Heuer wrote:
I would like to invite Aaron Dixon to join the Piccolo2D project as a
committer. He is already listed in the parent/pom.xml as a
contributor.
He has been active on t
> 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
So far, I have tested 3 of my Piccolo applications, and found only 1
problem in one of the 3 applications. My problem is exhibited with the
release candidate 1.3 rc1, but not with our previously used snapshot
r390 (circa 9/9/2008), and it also appears to be related to PSwing; a
panel with 2 ra
Piccolo Team,
My team and I write piccolo applications that need to support many
languages, and the default fonts specified in PText and PHTMLView often
need to be replaced (or glyphs can appear as empty boxes). We are
currently overriding these fonts on a case-by-case basis, but I wanted
to d
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 at http://phet.colorado.edu/, and he's provided several key bug
reports and patches for Piccolo. He also has an excellent sense of user
inter
e does not already exist.
How does this perform when compared to JLabel via PSwing?
Font, HTML, and HTMLColor should all be bound properties; in other
words, they should fire property change events.
michael
On Mon, Jul 27, 2009 at 7:20 PM, Samuel Robert Reid wrote:
I agree this should b
I agree this should become part of the extras package; it's
indispensable to my team's projects. Regarding the performance, it is
orders of magnitude slower than using a PText, so in some situations
where I would have preferred HTMLNodes, I've made due with PTexts
instead (where there are man
GPL itself says output from a GPL program is not covered:
http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
Sam Reid
Michael Heuer wrote:
allain wrote:
My reasons for wanting to do this are:
- Obviously Code Coverage Metrics are good but this one is IDE
agnostic.
- It has a Hu
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(".*\\.", "
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 su
e any functional or nonfunctional
reasons we should leave the current PSwing implementation of buffering
enabled? I'm not sure of all the impacts this might have on client
code.
Sam Reid
Samuel Robert Reid wrote:
For the knob icon/Mac issue, you can use the test included in the li
buffering).
Let me know what you think,
Sam Reid
Michael Heuer wrote:
Samuel Robert Reid wrote:
My group and I have found that the buffering in PSwing.paint can cause
rendering problems, such as the slider knob doesn't render on OS X 10.5
(if there are ticks or labels on the sl
Piccolo Team,
My group and I have found that the buffering in PSwing.paint can cause
rendering problems, such as the slider knob doesn't render on OS X 10.5
(if there are ticks or labels on the slider). Also, I don't see the
advantage of buffering in PSwing.paint, since the intermediate buffe
>> are there any plans for an OpenGL implementation of the Java Piccolo2D?
Why not just enable the opengl pipeline in the java implementation?
Sam Reid
Jörg Selbach wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everyone,
>
> are there any plans for an OpenGL implementation of
14 matches
Mail list logo
