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