PyProgress and colo(u)rs

wxPython Users
1

I finally updated to the latest release to take advantage of some of Andrea’s widgets being bundled. PyProgress is great and I’m replacing the old progress dialog in my code, but it appears to differ from most of the native widgets by requiring a wx.Colo(u)r object for methods such as SetFirstGradientColour. Not a big deal, but a little inconsistent, and I find it very convenient to pass a tuple like (200,200,200) instead. Can this be fixed? (I’m happy to supply a patch myself if that helps.)

thanks,

Nat

2

I finally updated to the latest release to take advantage of some of
Andrea's widgets being bundled. PyProgress is great and I'm replacing
the old progress dialog in my code, but it appears to differ from most
of the native widgets by requiring a wx.Colo(u)r object for methods such
as SetFirstGradientColour. Not a big deal, but a little inconsistent,
and I find it very convenient to pass a tuple like (200,200,200)
instead. Can this be fixed?

Sure.

(I'm happy to supply a patch myself if
that helps.)

Please do. You can check the type of the value passed in and if it's not an instance of wx.Colour then use wx.NamedColour to try to convert it to one.

···

On 11/4/09 12:42 PM, Nathaniel Echols wrote:

--
Robin Dunn
Software Craftsman

3

Doesn’t it need to test for both str and tuple objects? If it’s a tuple, wx.Colour(color) will do what I need, but it’s easy to make it work either way.

Which code should I use as the base for adding the patch, the 2.8.10.1 version or the latest SVN?

···

On Wed, Nov 4, 2009 at 2:02 PM, Robin Dunn robin@alldunn.com wrote:

On 11/4/09 12:42 PM, Nathaniel Echols wrote:

I finally updated to the latest release to take advantage of some of

Andrea’s widgets being bundled. PyProgress is great and I’m replacing

the old progress dialog in my code, but it appears to differ from most

of the native widgets by requiring a wx.Colo(u)r object for methods such

as SetFirstGradientColour. Not a big deal, but a little inconsistent,

and I find it very convenient to pass a tuple like (200,200,200)

instead. Can this be fixed?

Sure.

(I’m happy to supply a patch myself if

that helps.)

Please do. You can check the type of the value passed in and if it’s

not an instance of wx.Colour then use wx.NamedColour to try to convert

it to one.

4

On Wed, Nov 4, 2009 at 2:02 PM, Robin Dunn <robin@alldunn.com

     > (I'm happy to supply a patch myself if
     > that helps.)

    Please do. You can check the type of the value passed in and if it's
    not an instance of wx.Colour then use wx.NamedColour to try to convert
    it to one.

Doesn't it need to test for both str and tuple objects?

Nope. There's a sneaky little implementation detail in wx.NamedColour that has a side effect that makes it work with the tuples too.

  >>> wx.NamedColour('pink')
  wx.Colour(255, 192, 203, 255)
  >>> wx.NamedColour( (11,22,33) )
  wx.Colour(11, 22, 33, 255)
  >>>

Which code should I use as the base for adding the patch, the 2.8.10.1
version or the latest SVN?

SVN.

···

On 11/4/09 1:05 PM, Nathaniel Echols wrote:

--
Robin Dunn
Software Craftsman

5

Hi All,

2009/11/4 Robin Dunn:

 &gt; \(I&#39;m happy to supply a patch myself if
 &gt; that helps\.\)

Please do\.  You can check the type of the value passed in and if it&#39;s
not an instance of wx\.Colour then use wx\.NamedColour to try to convert
it to one\.

Doesn't it need to test for both str and tuple objects?

Nope. There's a sneaky little implementation detail in wx.NamedColour
that has a side effect that makes it work with the tuples too.

>>> wx.NamedColour('pink')
wx.Colour(255, 192, 203, 255)
>>> wx.NamedColour( (11,22,33) )
wx.Colour(11, 22, 33, 255)
>>>

Which code should I use as the base for adding the patch, the 2.8.10.1
version or the latest SVN?

SVN.

No need for a patch, I have applied a fix in SVN.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 11/4/09 1:05 PM, Nathaniel Echols wrote:

On Wed, Nov 4, 2009 at 2:02 PM, Robin Dunn <robin@alldunn.com >