pythoncard-users

[Pythoncard-users] need opinions on two changes for 0.8

[Kevin A. <al...@se...>]

It looks like the next release of wxPython is very close to being=20
ready. For those of you that want to test it and the version of=20
PythonCard that is in cvs, you can find wxPython 2.5.2 test candidates=20=

at:

http://starship.python.net/crew/robind/wxPython/preview/

2.5.2.4 is the most recent build as of this morning, but there will=20
likely be a 2.5.2.5 or 2.5.2.6 depending on issues people report to the=20=

wxPython-dev mailing list before the final 2.5.2 release.

Once that is available I plan to do a PythonCard 0.8 release, so I=20
would appreciate comments from anyone working from cvs that wants to=20
identify bugs or any other issues they find. PythonCard 0.8 requires=20
wxPython 2.5.2.x as a minimum!

The two issues I want comments on are whether to leave the BitmapCanvas=20=

draw operations as separate x, y and width, height args or to use=20
tuples (x, y) and (width, height). What's in cvs right now are tuple=20
versions, but since wxPython switched back to separate args after the=20
2.5.1.5 outcry, my inclination on odd days is to go ahead and switch=20
back as well since it matches the wxPython arg list and is probably=20
simpler for people to remember. On even days I think using tuples is=20
more consistent since it matches the init args for components, but the=20=

wxPython API uses both forms for a lot of different methods. As a brief=20=

example, here's drawLine as used in the doodle sample with separate=20
args followed by tuple args. If nobody replies I'll go ahead and revert=20=

all the sample, BitmapCanvas, etc. before 0.8 is released.

event.target.drawLine(self.x, self.y, x, y)=00

event.target.drawLine((self.x, self.y), (x, y))=00

The second issue is that for a long time I've been thinking about just=20=

using the wx.lib.dialogs function wrappers for system dialogs instead=20
of the ones in PythonCard.dialog. I wrote most of the code in=20
wx.lib.dialogs last year, so it has the same goal as the current=20
PythonCard dialog code, which is to make all system dialogs function=20
calls. However, the arg lists are changed, mostly for the better, and=20
the result is a class instead of a dict. What I plan to do is leave the=20=

PythonCard.dialog module in place, but just import the appropriate=20
functions from wx.lib.dialogs or provide thin wrappers where PythonCard=20=

still needs some special handling such as the result returned by the=20
fontDialog. This change will impact every sample and tool that uses=20
system dialogs as well as the documentation Dan Shafer wrote, so I=20
don't want to switch if everyone is going to complain and I have to=20
switch all the code back. Again, if there aren't a lot of dissents,=20
I'll make the change later this week. Anyone that is interested in the=20=

changes, should just look at the wx.lib.dialogs.py code in wxPython=20
2.4.2.4 or later.

ka=

Re: [Pythoncard-users] need opinions on two changes for 0.8

[Alex T. <al...@tw...>]

At 10:31 10/08/2004 -0700, Kevin Altis wrote:


>The two issues I want comments on are whether to leave the BitmapCanvas 
>draw operations as separate x, y and width, height args or to use tuples 
>(x, y) and (width, height). What's in cvs right now are tuple versions, 
>but since wxPython switched back to separate args after the 2.5.1.5 
>outcry, my inclination on odd days is to go ahead and switch back as well 
>since it matches the wxPython arg list and is probably simpler for people 
>to remember. On even days I think using tuples is more consistent since it 
>matches the init args for components, but the wxPython API uses both forms 
>for a lot of different methods. As a brief example, here's drawLine as 
>used in the doodle sample with separate args followed by tuple args. If 
>nobody replies I'll go ahead and revert all the sample, BitmapCanvas, etc. 
>before 0.8 is released.
>
>event.target.drawLine(self.x, self.y, x, y)
>
>event.target.drawLine((self.x, self.y), (x, y))

No big deal either way - I'd go with the same as wxPython; the easier it is 
to slip past Pythoncard into wxPython (when necessary) the better.

>The second issue is that for a long time I've been thinking about just 
>using the wx.lib.dialogs function wrappers for system dialogs instead of 
>the ones in PythonCard.dialog. I wrote most of the code in wx.lib.dialogs 
>last year, so it has the same goal as the current PythonCard dialog code, 
>which is to make all system dialogs function calls. However, the arg lists 
>are changed, mostly for the better, and the result is a class instead of a 
>dict. What I plan to do is leave the PythonCard.dialog module in place, 
>but just import the appropriate functions from wx.lib.dialogs or provide 
>thin wrappers where PythonCard still needs some special handling such as 
>the result returned by the fontDialog. This change will impact every 
>sample and tool that uses system dialogs as well as the documentation Dan 
>Shafer wrote, so I don't want to switch if everyone is going to complain 
>and I have to switch all the code back. Again, if there aren't a lot of 
>dissents, I'll make the change later this week. Anyone that is interested 
>in the changes, should just look at the wx.lib.dialogs.py code in wxPython 
>2.4.2.4 or later.

Any chance you could provide a simple "what the code looks like before and 
after" example to make it easier to have an opinion on this one ?

Thanks
-- Alex Tweedly.

Re: [Pythoncard-users] need opinions on two changes for 0.8

[Kevin A. <al...@se...>]

On Aug 12, 2004, at 5:39 AM, Alex Tweedly wrote:

> At 10:31 10/08/2004 -0700, Kevin Altis wrote:
>
>
>> The two issues I want comments on are whether to leave the 
>> BitmapCanvas draw operations as separate x, y and width, height args 
>> or to use tuples (x, y) and (width, height). What's in cvs right now 
>> are tuple versions, but since wxPython switched back to separate args 
>> after the 2.5.1.5 outcry, my inclination on odd days is to go ahead 
>> and switch back as well since it matches the wxPython arg list and is 
>> probably simpler for people to remember. On even days I think using 
>> tuples is more consistent since it matches the init args for 
>> components, but the wxPython API uses both forms for a lot of 
>> different methods. As a brief example, here's drawLine as used in the 
>> doodle sample with separate args followed by tuple args. If nobody 
>> replies I'll go ahead and revert all the sample, BitmapCanvas, etc. 
>> before 0.8 is released.
>>
>> event.target.drawLine(self.x, self.y, x, y)
>>
>> event.target.drawLine((self.x, self.y), (x, y))
>
> No big deal either way - I'd go with the same as wxPython; the easier 
> it is to slip past Pythoncard into wxPython (when necessary) the 
> better.

I'm flip flopping again, so I'm going to hold off on this change and 
ponder it while the dialog changes below get a little more testing.

>> The second issue is that for a long time I've been thinking about 
>> just using the wx.lib.dialogs function wrappers for system dialogs 
>> instead of the ones in PythonCard.dialog. I wrote most of the code in 
>> wx.lib.dialogs last year, so it has the same goal as the current 
>> PythonCard dialog code, which is to make all system dialogs function 
>> calls. However, the arg lists are changed, mostly for the better, and 
>> the result is a class instead of a dict. What I plan to do is leave 
>> the PythonCard.dialog module in place, but just import the 
>> appropriate functions from wx.lib.dialogs or provide thin wrappers 
>> where PythonCard still needs some special handling such as the result 
>> returned by the fontDialog. This change will impact every sample and 
>> tool that uses system dialogs as well as the documentation Dan Shafer 
>> wrote, so I don't want to switch if everyone is going to complain and 
>> I have to switch all the code back. Again, if there aren't a lot of 
>> dissents, I'll make the change later this week. Anyone that is 
>> interested in the changes, should just look at the wx.lib.dialogs.py 
>> code in wxPython 2.4.2.4 or later.
>
> Any chance you could provide a simple "what the code looks like before 
> and after" example to make it easier to have an opinion on this one ?
>

Too late, I just did a massive check-in. I won't be surprised if I made 
a typo here and there, but after doing extensive searches of the 
sources I'm pretty sure I obliterated all traces of the old dictionary 
style access. The only system dialog that needed more than an alias was 
fontDialog, so dialog.py has been dramatically simplified. I also 
updated samples and tools using CustomDialog to use the 
dialog.DialogResults class.

Anyone working from cvs, could always save a copy of their current 
PythonCard package and sub-dirs for comparison. However, as a simple 
example, here's a common usage of the openFileDialog from the 
codeEditor in the old and new forms.

OLD:
         result = dialog.openFileDialog(None, 
self.resource.strings.openFile, '', '', wildcard)
         if result['accepted']:
             path = result['paths'][0]

NEW:
         result = dialog.openFileDialog(None, 
self.resource.strings.openFile, '', '', wildcard)
         if result.accepted:
             path = result.paths[0]

The result is an instance of the DialogResults class now, so "dot 
notation" is used to access an attribute rather than accessing a 
dictionary key in the old form. Another change is that if you were 
using constants such as dialog.ICON_INFORMATION you now have to use the 
equivelant wx constants which typically just requires substituting wx 
for dialog (e.g. wx.ICON_INFORMATION).

Since all of the samples and tools were updated to the new form there 
are plenty of examples, just use findfiles to search for dialog\. or 
result\.accepted, dialog\.messageDialog, etc.

ka