Phoenix - floatcanvas

0 views
Skip to first unread message

Werner

unread,
Apr 22, 2013, 7:47:10 AM4/22/13
to wxpyth...@googlegroups.com
Hi,

Enclosed is a patch for floatcanvas which gets rid of deprecation
warnings, however I am still having the recursion issue I mentioned in
another thread.

Werner

P.S.
Sorry for duplicates posts, had problems with my emails and didn't see
that the first had gone through


floatcanvas.patch

werner

unread,
Apr 22, 2013, 8:03:15 AM4/22/13
to wxPyth...@googlegroups.com
On 22/04/2013 13:47, Werner wrote:
> Hi,
>
> Enclosed is a patch for floatcanvas which gets rid of deprecation
> warnings, however I am still having the recursion issue I mentioned in
> another thread.
>
That problem can also be recreated using the FloatCanvas demo.

Werner

Robin Dunn

unread,
Apr 23, 2013, 9:57:16 PM4/23/13
to wxPyth...@googlegroups.com
Werner wrote:
> Hi,
>
> Enclosed is a patch for floatcanvas which gets rid of deprecation
> warnings, however I am still having the recursion issue I mentioned in
> another thread.


I don't understand the reason for this code:

> +if 'phoenix' in wx.PlatformInfo:
> + wxBitmap = wx.Bitmap
> +else:
> + wxBitmap = wx.wxBitmap
> +

Did you intend for the else clause to use wx.EmptyBitmap?


There is no need for the if statement here:

> + if 'phoenix' in wx.PlatformInfo:
> + PanelSize = N.array(self.GetClientSize(), N.int32)
> + else:
> + PanelSize = N.array(self.GetClientSizeTuple(), N.int32)

The first clause will work with both Classic and Phoenix since wx.Size
provides the magic methods needed to treat the object as a sequence.


You can just remove the dc.BeginDrawing and dc.EndDrawing calls. I
think they've been empty methods since 2.4 or perhaps earlier.

The block in the patch that changes the use of the event binders as
functions to using them with the Bind method can be changed to use the
Bind method for both Classic and Phoenix. No need to conditionalize it.


Finally, unless Chris feels otherwise I don't think we should worry
about maintaining compatibility with both Classic and Phoenix. The
source has been forked in the repository and there isn't any intention
of distributing the Phoenix wx.lib with Classic builds.

--
Robin Dunn
Software Craftsman
http://wxPython.org

werner

unread,
Apr 24, 2013, 2:27:40 AM4/24/13
to wxPyth...@googlegroups.com
Hi Robin,

On 24/04/2013 03:57, Robin Dunn wrote:
> Werner wrote:
>> Hi,
>>
>> Enclosed is a patch for floatcanvas which gets rid of deprecation
>> warnings, however I am still having the recursion issue I mentioned in
>> another thread.
>
>
> I don't understand the reason for this code:
>
>> +if 'phoenix' in wx.PlatformInfo:
>> + wxBitmap = wx.Bitmap
>> +else:
>> + wxBitmap = wx.wxBitmap
>> +
>
> Did you intend for the else clause to use wx.EmptyBitmap?
>
That was the intention, but obviously never tested with classic:-[ ,
have to be more careful, sorry.

...
>
> Finally, unless Chris feels otherwise I don't think we should worry
> about maintaining compatibility with both Classic and Phoenix. The
> source has been forked in the repository and there isn't any intention
> of distributing the Phoenix wx.lib with Classic builds.
Attached a new patch to get rid of deprecation warnings with out the
check for Phoenix - if Chris wants to keep it compatible I will redo it.

I left the print statements in "_MouseEvent" and when I run the FC demo
I get this:

<wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
Coords
<wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
_NativeEvent
<wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
_NativeEvent
<wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>

and so on....

I don't get what is happening here.

Werner

floatcanvas 2.patch

Robin Dunn

unread,
Apr 25, 2013, 8:18:40 PM4/25/13
to wxPyth...@googlegroups.com
werner wrote:
> I left the print statements in "_MouseEvent" and when I run the FC demo
> I get this:
>
> <wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
> Coords
> <wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
> _NativeEvent
> <wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
> _NativeEvent
> <wx.lib.floatcanvas.FloatCanvas._MouseEvent object at 0x02E80A98>
>
> and so on....
>
> I don't get what is happening here.

Well, part of the problem was that your print statements in __getattr__
were causing __getattr_ to be called. But that was only a small part of
the problem.

The main thing is that wx.PyEvent and wx.PyCommandEvent now have their
own __getattr__, __setattr__ and __delattr__ methods, and they are not
actually storing the attributes directly in the class instance but in a
separate dictionary. So when any evt.Foo was used it would not find the
value in the instance, so it would call __getattr__look for it in
self._NativeEvent, which would also not be found in the instance and so
that would result in a call to __getattr__.

I'm changing FC's _MouseEvent.__getattr__ to look like this instead:

def __getattr__(self, name):
d = self._getAttrDict()
if name in d:
return d[name]
return getattr(self._NativeEvent, name)

And I'll add something to the MigrationGuide about this too.

I'm also adding the FloatCanvas demo modules to
Phoenix/samples/floatcanvas. You may want to run through those and see
what else might still need tweaked in the floatcanvas modules.

werner

unread,
Apr 26, 2013, 2:26:03 AM4/26/13
to wxPyth...@googlegroups.com
Hi Robin,

On 26/04/2013 02:18, Robin Dunn wrote:

...
> I'm also adding the FloatCanvas demo modules to
> Phoenix/samples/floatcanvas. You may want to run through those and
> see what else might still need tweaked in the floatcanvas modules.
Will go through them when the next snapshot is available and thanks for
the explanation.

Werner

Chris Barker - NOAA Federal

unread,
Apr 29, 2013, 3:18:44 PM4/29/13
to wxPyth...@googlegroups.com
Werner,

Thanks so much for working on this -- Im not sure when I'd get the time.

Note that Robin is pointing out various things that are really cruft from the early days of FC -- I never systematically modernized it, so it's great to do that now -- even for "classic" wx.

More comments later if needed..I'm catching up on email after a vacation.

Finally, unless Chris feels otherwise I don't think we should worry about maintaining compatibility with both Classic and Phoenix.  The source has been forked in the repository and there isn't any intention of distributing the Phoenix wx.lib with Classic builds.

hmm -- at first thought I agree -- but it looks like this is a godo chance to clean up some stuff in both versions, and I'm not sure what I (or others) will want to do if/when we improve FloatCanvas while both Classic and Poenix are active.

So if it's fairly easy to keep one code base, that would be great. If it gets to be too messy, then fork away.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

werner

unread,
Apr 30, 2013, 3:30:45 AM4/30/13
to wxPyth...@googlegroups.com
Chris,


On 29/04/2013 21:18, Chris Barker - NOAA Federal wrote:
Werner,

Thanks so much for working on this -- Im not sure when I'd get the time.
Thank you for having done FloatCanvas ;-)

Note that Robin is pointing out various things that are really cruft from the early days of FC -- I never systematically modernized it, so it's great to do that now -- even for "classic" wx.

More comments later if needed..I'm catching up on email after a vacation.

Finally, unless Chris feels otherwise I don't think we should worry about maintaining compatibility with both Classic and Phoenix.  The source has been forked in the repository and there isn't any intention of distributing the Phoenix wx.lib with Classic builds.

hmm -- at first thought I agree -- but it looks like this is a godo chance to clean up some stuff in both versions, and I'm not sure what I (or others) will want to do if/when we improve FloatCanvas while both Classic and Poenix are active.

So if it's fairly easy to keep one code base, that would be great. If it gets to be too messy, then fork away.
The patch I submitted was assuming a fork - I guess this only becomes an issue if new functionality is done which should go into classic and Phoenix.

Werner

Robin Dunn

unread,
May 1, 2013, 8:20:32 PM5/1/13
to wxPyth...@googlegroups.com
I suppose that back-porting to Classic could be even easier than the
port to Phoenix was...
Reply all
Reply to author
Forward
0 new messages