pythoncard-devel Mailing List for PythonCard (Page 8)

Alex Tweedly <al...@tw...> wrote on 08/19/2005 06:33:52 PM:
> bra...@om... wrote: 
> 
> > I ran across a bug in the Multi-resource editor. When you 
> > drag-select a rectangle around a group of widgets, it normally 
> > works fine...unless the mouse cursor bumps the edge of the 
> > window. I was able to duplicate the bug consistently against 
> > the top, left, right and bottom of the window. Testing was done 
> > on Windows XP, wxPython 2.6.0, and CVS PythonCard. 
> > What did you see ? What did it do that was wrong ?
> 
> What it's supposed to do is "suspend" the marquee-drawing at the 
> point where your cursor leaves the window; if you re-enter the 
> window with the mouse button still depressed, it should carry on 
> with the marqueeing as before.
Yes, this is the behavior; I'm sorry I wasn't more clear.
My expectation from using similar tools in other apps is that if
you release the mouse while outside the window, the marquee should
disappear and the widgets inside would be selected. This failed to
happen, so I perceived it as a bug.
Brad Allen
IT Desktop Support
Omnicom Management Services
Dallas, TX
http://www.omsdal.com 

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 18/08/2005

I ran across a bug in the Multi-resource editor. When you
drag-select a rectangle around a group of widgets, it normally
works fine...unless the mouse cursor bumps the edge of the
window. I was able to duplicate the bug consistently against
the top, left, right and bottom of the window. Testing was done
on Windows XP, wxPython 2.6.0, and CVS PythonCard.
Brad Allen
IT Desktop Support
Omnicom Management Services
Dallas, TX
http://www.omsdal.com

It's a bit awkward to use wxselect with PythonCard because there is
no single configuration file for this. This is because PythonCard can be
invoked from a variety of different starting places.
How about creating a wxinitialize module that would be called at
the top of every PythonCard module before the import wx statement?
It would utilize a simple wxConfig file designed to be easy to edit
by end users.
wxInitialize.py would look very simple, something like this:
------------------------------------- wxInitialize.py 
--------------------------
from wxConfig import wxSelectValue
try:
	import wxversion
	wxversion.select(wxSelectValue)
except Exception, thisErr:
	print thisErr
import wx
print 'wx.PlatformInfo:', wx.PlatformInfo
print 'wx.VERSION:', wx.VERSION
#we could also add assert statement for minimum wx version
--------------------------------------------
The config file would look something like this:
--------------------------- wxConfig.py 
----------------------------------------
wxSelectValue=['2.6-ansi']
--------------------------------------------

In the resource editor font dialog (both resource editors), there is a 
color selector.
However, it doesn't seem to do anything. If I want to change the color of 
a StaticText,
I must change the foregroundColor attribute. Is this a bug or a 
misunderstanding?
Thanks.

On Wed, 2005年07月27日 at 18:42 -0500, bra...@om... wrote:
> Problem Description: 
> When I enclose widgets with a StaticBox, within the region of the
> StaticBox, 
> I can't click buttons, Choice widgets, TextField widgets, etc. This
> happens 
> regardless of the widget order. Widgets outside the region of the 
> StaticBox are unaffected. However, I can tab into TextField widgets to
> type text.
> 
Just to muddy the waters further, I see this same problem in the
resource editor on Linux/GTK, but it doesn't happen when I'm actually
running an application. 
I haven't reported it in the past as it only seems to happen in the
resource editor and as such has never been a big problem for me.
--
Phil Edwards
Brighton, UK

Kevin Altis wrote:
> On Jul 27, 2005, at 7:03 AM, Alex Tweedly wrote:
>
> Excellent. Remember when adding binary files to use
>
> cvs add -kb filename
>
> so the file doesn't get mangled.
>
I'll remember that, but haven't got that far yet.
I did a "cvs add <file>" for each of the seven source files.
Then I did a "cvs ci <file>" for each of them (I did two of them in a 
single ci, and got a warning message about "<file> lost" so I did the 
rest of them singly.)
That all looked as though it had done OK, and it even generated 
reasonable looking notifications.
But when I did a "cvs diff" to check they had gone in OK, I got errors like
cvs diff: cannot find revision control file for <file>
for each of them. And cannot do a checkout on them - gets "cvs server: 
cannot find module <file>"
Any ideas ? Did I miss out some step ?
Help !
(I'll not add the image files until I know what's going on - so the 
check-in is incomplete ....)
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005

Kevin Altis wrote:
> Instead, what I expect would be better is to rename your copy of 
> resourceEditor.py, rename resourceOutput.py, and the propertyEditor.py 
> and propertyEditor.rsrc.py files. Then change the imports in your 
> files to use the newly renamed files as well as update the places 
> those modules are referenced in the code. Since PythonCard code files 
> avoid import * like the plague I don't think there will be any spots 
> of ambiguity.
>
> I used findfiles to search for references to the resourceOutput module 
> in the resourceEditor directory, I only see five lines, all in 
> resourceEditor.py, so that is easily updated in your new files without 
> any chance of conflicts. In the case of the propertyEditor module 
> there are only two lines impacted in resourceEditor.py, and if you 
> keep the same style import, then you only have to change the import 
> line to use the newly renamed propertyEditor.py module. Since it 
> doesn't appear there are any circular import references in 
> resourceOutput.py or propertyEditor.py, that should solve the problem 
> with a minimal of fuss. Obviously, you'll need to update your 
> propertyEditor.py module to use the newly renamed resourceOutput.py 
> module too. I suggest using the same prefix for the new 
> resourceEditor.py as well as your updated modules so that it is clear 
> that they go together.
>
> Let me know if that works.
Yep - that works well. Obvious, given hindsight and an expert to tell me 
what to do :-)
Thanks Kevin.
I've actually added 7 files, rather than the 6 previously listed; it 
seems less confusing to duplicate the resourceEditor.rsrc.py to match 
the name of the new editor. So my local copy the resourceEditor now has 
7 new files, all prefixed "multi"
 multiresourceEditor.py
 multiresourceEditor.rsrc.py
 modules/multipropertyEditor.py
 modules/multipropertyEditor.rsrc.py
 modules/multiComponents.py
 modules/multiComponents.rsrc.py
 modules/multiresourceOutput.py
I also added a quick and easy way to switch the tricky name mangling 
scheme on or off, so that if we do decide to take it out, it should be 
straight-forward (and if I want to turn it back on in my local copy, 
that'll be easy too :-)
Near the top of multipropertyEditor.py there is now a line
DO_TRICKY_NAME_DERIVATIONS = True
Changing this to be False will hide the check box, and always allow the 
name and label/text to vary independently.
I'll give it another couple of hours testing, then commit these files 
(and all the images needed in the images directory) into CVS.
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005

On Jul 27, 2005, at 7:03 AM, Alex Tweedly wrote:
>
> I'll give it another couple of hours testing, then commit these files 
> (and all the images needed in the images directory) into CVS.
>
Excellent. Remember when adding binary files to use
cvs add -kb filename
so the file doesn't get mangled.
ka

On Jul 26, 2005, at 3:45 PM, Alex Tweedly wrote:
> Kevin Altis wrote:
>
>> On Jul 26, 2005, at 2:59 PM, Alex Tweedly wrote:
>>
>>> Kevin Altis wrote:
>>>
>>>>
>>>> So, again my suggestion is that your resourceEditor be added to 
>>>> tools as its own directory and files.
>>>>
>>> Cool, I'll do that.
>>> (btw - it's only 4 files that have changed plus two new ones added - 
>>> but they amount to 3400 out of a total of just over 4000 lines, so I 
>>> don't think there's noticeable saving from keeping the unchanged 
>>> files in common).
>>>
>>> I'll see if there's any feedback on the self-adjusting layout, and 
>>> expect to do the commit this week (pending any other opinions in 
>>> response to this)
>>>
>>
>> Hmm, if it is only four files, then it might be better to just do 
>> some module name changes if that is possible. This would be similar 
>> to how codeEditorR was done, which would give you the option of 
>> subclassing if that makes sense. What are the four files and what 
>> dependencies do they have that would cause problems?
>>
> It changes
> resourceEditor.py
> modules/resourceOutput.py
> modules/propertyEditor.py
> modules/propertyEditor.rsrc.py
> and adds
> modules/multiComponents.py
> modules/multiComponents.rsrc.py
>
> The two that matter - resourceEditor.py and propertyEditor.py are both 
> fairly extensively changed. I can't see how it could be done by 
> subclassing - but I'll go look at the codeEditoR some more in case I'm 
> over-estimating the problems.
>
Subclassing was just one option, but given how extensive the changes 
are that you've described, probably a bad one and not necessary for 
your initial checkin.
Instead, what I expect would be better is to rename your copy of 
resourceEditor.py, rename resourceOutput.py, and the propertyEditor.py 
and propertyEditor.rsrc.py files. Then change the imports in your files 
to use the newly renamed files as well as update the places those 
modules are referenced in the code. Since PythonCard code files avoid 
import * like the plague I don't think there will be any spots of 
ambiguity.
I used findfiles to search for references to the resourceOutput module 
in the resourceEditor directory, I only see five lines, all in 
resourceEditor.py, so that is easily updated in your new files without 
any chance of conflicts. In the case of the propertyEditor module there 
are only two lines impacted in resourceEditor.py, and if you keep the 
same style import, then you only have to change the import line to use 
the newly renamed propertyEditor.py module. Since it doesn't appear 
there are any circular import references in resourceOutput.py or 
propertyEditor.py, that should solve the problem with a minimal of 
fuss. Obviously, you'll need to update your propertyEditor.py module to 
use the newly renamed resourceOutput.py module too. I suggest using the 
same prefix for the new resourceEditor.py as well as your updated 
modules so that it is clear that they go together.
Let me know if that works.
ka

Kevin Altis wrote:
> On Jul 26, 2005, at 2:59 PM, Alex Tweedly wrote:
>
>> Kevin Altis wrote:
>>
>>>
>>> So, again my suggestion is that your resourceEditor be added to 
>>> tools as its own directory and files.
>>>
>> Cool, I'll do that.
>> (btw - it's only 4 files that have changed plus two new ones added - 
>> but they amount to 3400 out of a total of just over 4000 lines, so I 
>> don't think there's noticeable saving from keeping the unchanged 
>> files in common).
>>
>> I'll see if there's any feedback on the self-adjusting layout, and 
>> expect to do the commit this week (pending any other opinions in 
>> response to this)
>>
>
> Hmm, if it is only four files, then it might be better to just do some 
> module name changes if that is possible. This would be similar to how 
> codeEditorR was done, which would give you the option of subclassing 
> if that makes sense. What are the four files and what dependencies do 
> they have that would cause problems?
>
It changes
 resourceEditor.py
 modules/resourceOutput.py
 modules/propertyEditor.py
 modules/propertyEditor.rsrc.py
and adds
 modules/multiComponents.py
 modules/multiComponents.rsrc.py
The two that matter - resourceEditor.py and propertyEditor.py are both 
fairly extensively changed. I can't see how it could be done by 
subclassing - but I'll go look at the codeEditoR some more in case I'm 
over-estimating the problems.
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005

On Jul 26, 2005, at 2:59 PM, Alex Tweedly wrote:
> Kevin Altis wrote:
>>
>> So, again my suggestion is that your resourceEditor be added to tools 
>> as its own directory and files.
>>
> Cool, I'll do that.
> (btw - it's only 4 files that have changed plus two new ones added - 
> but they amount to 3400 out of a total of just over 4000 lines, so I 
> don't think there's noticeable saving from keeping the unchanged files 
> in common).
>
> I'll see if there's any feedback on the self-adjusting layout, and 
> expect to do the commit this week (pending any other opinions in 
> response to this)
>
Hmm, if it is only four files, then it might be better to just do some 
module name changes if that is possible. This would be similar to how 
codeEditorR was done, which would give you the option of subclassing if 
that makes sense. What are the four files and what dependencies do they 
have that would cause problems?
ka

Kevin Altis wrote:
> I will be able to test on Panther after OSCON. I'm currently in a 
> holding pattern on my Mac so that I don't break anything prior to my 
> presentation next week. I backed out wxPython 2.6.x as well on the Mac 
> since it appears there might be some wxSTC issues, which I'll look 
> into further after OSCON.
>
Thanks.
>> Other changes.
>>
>> The one new feature that didn't feel quite right to me was the 
>> implementation of the name-derivation scheme. I really liked the idea 
>> - that you could modify only the name and the label (or text, or 
>> textarea) would adjust accordingly, or vice versa - but the 
>> implementation seemed clumsy. It was clumsy because :
>> - two check boxes needed - ugh.
>> - needed an update to widget.py, so harder to run in parallel
>> - backwards compatibility required that the default for the two new 
>> properties be "true", while the resourceEditor required that the 
>> initial value for new components be "false" - so almost all resource 
>> files would specify values for these properties.
>
>
> I don't have much experience with this implementation, but it seems to 
> "tricky" for the average user and while it could be a clever time 
> saver for your own tool where you know what to expect all the time, I 
> expect it would just cause problems for an infrequent user. This 
> widget.py change is probably a show-stopper.
Yeah, it seemed ok at first, and did save some time, but I found I 
didn't much like it. And I really disliked the widget.py change, so I 
was glad to see the end of that approach.
>> I've come up with a new scheme, which I like much better, but which 
>> needs to be tried out by others. (Where this description says 
>> "label", it could equally be "text" or "textarea").
>>
>> The name and label are tied together; editing either one will make 
>> the corresponding adjustment to the other. If you want them to be 
>> different, you check the "Allow Different" checkbox before making the 
>> change. This checkbox is a control for the operation of the editor - 
>> it is not a property of the component, and is not stored in the 
>> resource file.
>>
>> When a component is selected, the name and label are compared - if 
>> they are already different, then "Allow Different" flag is set - 
>> otherwise it will be false. (And in particular, this means that 
>> when pre-existing resource files are read in, they operate exactly as 
>> before, and unless/until a component is edited, it is not affected in 
>> any way).
>>
>> So - if you are editing a component where they currently match, and 
>> you click on "Allow Different" but then go off and select another 
>> component without changing either name or label, then when you come 
>> back to this original component, the flag will no longer be set. That 
>> might be a surprise the first couple of times it happens - but in 
>> fact, most likely in real use you would clock on the checkbox and 
>> immediately change one of them.
>
>
> My comments above apply here too, but feel free to try it out as long 
> as it isn't going to require framework changes.
It certainly won't involve framework changes.
It's simpler than the other scheme, but it might be a bit tricky; I 
don't find it to be, but we'll need to find out what others think once 
it's available for use. If it does turn out to be tricky for occasional 
users, then we'll take it out - but I'll definitely then propose some 
way to keep it either as an option / preference choice, or at least keep 
one-way derivation from name to label/text. I take advantage of that all 
the time in Revolution, and it is a major time-saver.
>> Font property.
>>
>> I have found the field containing a textual description of the font 
>> to be pretty useless. The text name is so long that to get to the 
>> relevant part of the info, you need to click and side-scroll - and 
>> even then it's pretty unreadable. Any time I want to check on the 
>> font info, I find it easier to just click on the font button, and see 
>> in the pop-up dialog what I need.
>>
>> And it was almost impossible to fit the button on the same horizontal 
>> line as the field - so I have (temporarily) just removed the field, 
>> and now it looks much better without (for me) any disadvantage in how 
>> I use it. If anyone objects, it can be put back easily - esp 
>> non-Windows users who may have more useful font names.
>> So please let me know what you think about the font button / field.
>
>
> I've not been that happy with the Font property for some of the 
> reasons you've specified but also because typically this property 
> isn't changed and due to how defaults work, the resulting font used on 
> the different platforms or even on the same platform where the user 
> default has been changed, will result in messed up layouts, etc. For 
> the display of the property, either single or multiple statictext 
> fields would probably be better, dropping the curly braces, quotes, 
> and commas on the actual display of the property. This would require 
> some special handling using the normal Update button, but if the 
> changes are only made when the Font dialog is accepted, then it 
> shouldn't be an issue.
>
So would the multiple display fields be read-only, with changes allowed 
only via the Font dialog ? I think that would be good - I can't believe 
there are many people who make a habit of editing the descriptor string, 
so doing that would allow you to have the characteristics visible. I'll 
try it out and see how it looks.
> On a related note, if properties were handled by property-specific 
> handlers as originally envisioned the property editor would be much 
> better. We may still be able to pull that off for a 1.x version of 
> PythonCard without breaking anything, but it might be something done 
> in PythonCard 2 instead of we continue with the idea of 
> self-describing components.
>
>> Anyone willing to test please contact me off-list and I'll email you 
>> a current copy.
>> Anyone who doesn't think it could go as an additional tool, please 
>> respond on-list.
>> Anyone who thinks it should be an additional tool, please respond 
>> on-list also.
>
>
> So, again my suggestion is that your resourceEditor be added to tools 
> as its own directory and files.
>
Cool, I'll do that.
(btw - it's only 4 files that have changed plus two new ones added - but 
they amount to 3400 out of a total of just over 4000 lines, so I don't 
think there's noticeable saving from keeping the unchanged files in common).
I'll see if there's any feedback on the self-adjusting layout, and 
expect to do the commit this week (pending any other opinions in 
response to this)
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005

On Jul 26, 2005, at 9:58 AM, Alex Tweedly wrote:
> I've been bringing the "newResourceEditor" up to date with the latest 
> CVS, and fixing up some of the problems with it. I'd now like a 
> volunteer or two to help me test it on non-Windows machines, and some 
> agreement (or discussion) on how to proceed with it.
>
> How to Proceed.
>
> The intent was to make this a branch in CVS. That seemed to make sense 
> to allow it to be properly distributed and tested by a number of 
> people - but it has the disadvantage (if I understand it properly) 
> that this makes it difficult to have both the original resourceEditor 
> and the branched-resourceEditor in a single installation. Being a 
> cautious type, I like having the old one around as easy backup, and 
> imagine others would feel the same.
>
> So I would prefer to add it as an additional tool (like the newer 
> version of the codeEditor). I think that would encourage more people 
> to try it out, and therefore more people to give necessary feedback 
> which would be needed before we could think about making the new one a 
> complete replacement for the existing one.
I would prefer to have it as a separate directory as well. While this 
is a bit of a pain for the initial checkin, it makes it simpler to 
update and as you pointed out leaves the original intact and available. 
The big downside is that you end up with parallel copies of files that 
are currently the same. If only a few files were changing then it might 
be better to have a single directory and simply change the name of some 
of the modules that would otherwise conflict. Since that could also 
lead to more confusion, I think we'll simply need to have you be 
responsible for updating files in the your resourceEditor.
> Non-Windows volunteers.
>
> I have partially implemented some sizer-based adjustment to the 
> layout. I have tested it as best I can on Windows (by faking the 
> returned sizes and seeing if the layout adjusted reasonably), but it 
> needs to be tested on Mac and/or Unix to see how it does.
> Warning: it's only a partial implementation; it (should) deal with the 
> properties that do not occur in every component (i.e. those below 
> "position and size" line in the display.If it works OK for those, then 
> I'll go back and do the standard ones (oddly enough, that's actually 
> noticeably harder).
I will be able to test on Panther after OSCON. I'm currently in a 
holding pattern on my Mac so that I don't break anything prior to my 
presentation next week. I backed out wxPython 2.6.x as well on the Mac 
since it appears there might be some wxSTC issues, which I'll look into 
further after OSCON.
> Other changes.
>
> The one new feature that didn't feel quite right to me was the 
> implementation of the name-derivation scheme. I really liked the idea 
> - that you could modify only the name and the label (or text, or 
> textarea) would adjust accordingly, or vice versa - but the 
> implementation seemed clumsy. It was clumsy because :
> - two check boxes needed - ugh.
> - needed an update to widget.py, so harder to run in parallel
> - backwards compatibility required that the default for the two new 
> properties be "true", while the resourceEditor required that the 
> initial value for new components be "false" - so almost all resource 
> files would specify values for these properties.
I don't have much experience with this implementation, but it seems to 
"tricky" for the average user and while it could be a clever time saver 
for your own tool where you know what to expect all the time, I expect 
it would just cause problems for an infrequent user. This widget.py 
change is probably a show-stopper.
> I've come up with a new scheme, which I like much better, but which 
> needs to be tried out by others. (Where this description says "label", 
> it could equally be "text" or "textarea").
>
> The name and label are tied together; editing either one will make the 
> corresponding adjustment to the other. If you want them to be 
> different, you check the "Allow Different" checkbox before making the 
> change. This checkbox is a control for the operation of the editor - 
> it is not a property of the component, and is not stored in the 
> resource file.
>
> When a component is selected, the name and label are compared - if 
> they are already different, then "Allow Different" flag is set - 
> otherwise it will be false. (And in particular, this means that when 
> pre-existing resource files are read in, they operate exactly as 
> before, and unless/until a component is edited, it is not affected in 
> any way).
>
> So - if you are editing a component where they currently match, and 
> you click on "Allow Different" but then go off and select another 
> component without changing either name or label, then when you come 
> back to this original component, the flag will no longer be set. That 
> might be a surprise the first couple of times it happens - but in 
> fact, most likely in real use you would clock on the checkbox and 
> immediately change one of them.
My comments above apply here too, but feel free to try it out as long 
as it isn't going to require framework changes.
> Font property.
>
> I have found the field containing a textual description of the font to 
> be pretty useless. The text name is so long that to get to the 
> relevant part of the info, you need to click and side-scroll - and 
> even then it's pretty unreadable. Any time I want to check on the font 
> info, I find it easier to just click on the font button, and see in 
> the pop-up dialog what I need.
>
> And it was almost impossible to fit the button on the same horizontal 
> line as the field - so I have (temporarily) just removed the field, 
> and now it looks much better without (for me) any disadvantage in how 
> I use it. If anyone objects, it can be put back easily - esp 
> non-Windows users who may have more useful font names.
> So please let me know what you think about the font button / field.
I've not been that happy with the Font property for some of the reasons 
you've specified but also because typically this property isn't changed 
and due to how defaults work, the resulting font used on the different 
platforms or even on the same platform where the user default has been 
changed, will result in messed up layouts, etc. For the display of the 
property, either single or multiple statictext fields would probably be 
better, dropping the curly braces, quotes, and commas on the actual 
display of the property. This would require some special handling using 
the normal Update button, but if the changes are only made when the 
Font dialog is accepted, then it shouldn't be an issue.
On a related note, if properties were handled by property-specific 
handlers as originally envisioned the property editor would be much 
better. We may still be able to pull that off for a 1.x version of 
PythonCard without breaking anything, but it might be something done in 
PythonCard 2 instead of we continue with the idea of self-describing 
components.
> Anyone willing to test please contact me off-list and I'll email you a 
> current copy.
> Anyone who doesn't think it could go as an additional tool, please 
> respond on-list.
> Anyone who thinks it should be an additional tool, please respond 
> on-list also.
>
> Thanks,
>
> -- 
> Alex Tweedly http://www.tweedly.net
>
So, again my suggestion is that your resourceEditor be added to tools 
as its own directory and files.
ka

I've been bringing the "newResourceEditor" up to date with the latest 
CVS, and fixing up some of the problems with it. I'd now like a 
volunteer or two to help me test it on non-Windows machines, and some 
agreement (or discussion) on how to proceed with it.
How to Proceed.
The intent was to make this a branch in CVS. That seemed to make sense 
to allow it to be properly distributed and tested by a number of people 
- but it has the disadvantage (if I understand it properly) that this 
makes it difficult to have both the original resourceEditor and the 
branched-resourceEditor in a single installation. Being a cautious type, 
I like having the old one around as easy backup, and imagine others 
would feel the same.
So I would prefer to add it as an additional tool (like the newer 
version of the codeEditor). I think that would encourage more people to 
try it out, and therefore more people to give necessary feedback which 
would be needed before we could think about making the new one a 
complete replacement for the existing one.
Non-Windows volunteers.
I have partially implemented some sizer-based adjustment to the layout. 
I have tested it as best I can on Windows (by faking the returned sizes 
and seeing if the layout adjusted reasonably), but it needs to be tested 
on Mac and/or Unix to see how it does.
Warning: it's only a partial implementation; it (should) deal with the 
properties that do not occur in every component (i.e. those below 
"position and size" line in the display.If it works OK for those, then 
I'll go back and do the standard ones (oddly enough, that's actually 
noticeably harder).
Other changes.
The one new feature that didn't feel quite right to me was the 
implementation of the name-derivation scheme. I really liked the idea - 
that you could modify only the name and the label (or text, or textarea) 
would adjust accordingly, or vice versa - but the implementation seemed 
clumsy. It was clumsy because :
 - two check boxes needed - ugh.
 - needed an update to widget.py, so harder to run in parallel
 - backwards compatibility required that the default for the two new 
properties be "true", while the resourceEditor required that the initial 
value for new components be "false" - so almost all resource files would 
specify values for these properties.
I've come up with a new scheme, which I like much better, but which 
needs to be tried out by others. (Where this description says "label", 
it could equally be "text" or "textarea").
The name and label are tied together; editing either one will make the 
corresponding adjustment to the other. If you want them to be different, 
you check the "Allow Different" checkbox before making the change. This 
checkbox is a control for the operation of the editor - it is not a 
property of the component, and is not stored in the resource file.
When a component is selected, the name and label are compared - if they 
are already different, then "Allow Different" flag is set - otherwise it 
will be false. (And in particular, this means that when pre-existing 
resource files are read in, they operate exactly as before, and 
unless/until a component is edited, it is not affected in any way).
So - if you are editing a component where they currently match, and you 
click on "Allow Different" but then go off and select another component 
without changing either name or label, then when you come back to this 
original component, the flag will no longer be set. That might be a 
surprise the first couple of times it happens - but in fact, most likely 
in real use you would clock on the checkbox and immediately change one 
of them.
Font property.
I have found the field containing a textual description of the font to 
be pretty useless. The text name is so long that to get to the relevant 
part of the info, you need to click and side-scroll - and even then it's 
pretty unreadable. Any time I want to check on the font info, I find it 
easier to just click on the font button, and see in the pop-up dialog 
what I need.
And it was almost impossible to fit the button on the same horizontal 
line as the field - so I have (temporarily) just removed the field, and 
now it looks much better without (for me) any disadvantage in how I use 
it. If anyone objects, it can be put back easily - esp non-Windows 
users who may have more useful font names. 
So please let me know what you think about the font button / field.
Anyone willing to test please contact me off-list and I'll email you a 
current copy.
Anyone who doesn't think it could go as an additional tool, please 
respond on-list.
Anyone who thinks it should be an additional tool, please respond 
on-list also.
Thanks,
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005

Cesar Cardenas Desales wrote:
> Hi guys:
>=20
> My name is Cesar Desales. As a member of the
> Spanish Python Community I'm glad to communicate to
> you the interest of some members of our group on
> traslating to spanish some of your docs and
> tutorials.=20
>=20
> I don't know what kind of license do your docs
> have, neither the electronic address of the author(s).
>=20
> If you know him(them) please let me know, and let
> him know, so that if he agrees, we can obtain the
> latex or html sources of those docs.
>=20
> Greetings
>=20
> C=E9sar
>=20
> https://lists.sourceforge.net/lists/listinfo/pythoncard-devel
C=E9sar
The documentation for PythonCard is under the same license as the code=20
[1], which is the BSD standard license. This is a pretty liberal license=20
and certainly allows for the translation of the documentation.
We currently aren't very sophisticated and the source of all of the=20
documentation is the HTML you see on the web site [2]. You can access=20
the full set quite easily by checking out a copy of the project from CVS=20
[3].
If you want any help or feedback this list is the best place to ask.
[1]=20
http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/LICENSE.txt?v=
iew=3Dmarkup
[2] http://pythoncard.sourceforge.net/
[3] http://sourceforge.net/cvs/?group_id=3D19015
Regards,
Andy
--=20
-------------------------------------------------------------------------=
-------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Hi guys:
 My name is Cesar Desales. As a member of the
Spanish Python Community I'm glad to communicate to
you the interest of some members of our group on
traslating to spanish some of your docs and
tutorials. 
 I don't know what kind of license do your docs
have, neither the electronic address of the author(s).
 If you know him(them) please let me know, and let
him know, so that if he agrees, we can obtain the
latex or html sources of those docs.
 Greetings
 César
	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexión a Internet y <b >2GB</b> extra a tu correo por 100ドル al mes. http://net.yahoo.com.mx 

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.14/48 - Release Date: 13/07/2005

Kevin Altis wrote on 07/14/2005 02:56:33 PM:
> As I'm sure you've noticed I haven't been doing any PythonCard for a 
> while. Thanks to all of you that have been covering the users mailing 
> list. I do want to get back to updating PythonCard, in particular for 
> wxPython 2.6 and to make sure that it is working fine with Python 2.3 
> and Python 2.4. My goal is to do a release before or during the first 
> week of August so that it will be available when I do my OSCON 
> presentation.
I'm glad you're back. That sounds like an ambitious timetable...would
it be too ambitious to include Alex's new Resource Editor in that
release? It's a fantastic improvement, and I've been putting it to
good use on Windows, but on Mac the new Property Editor doesn't work
well and the layout has overlapping elements.
> I'm still running Windows 2000, so that's what I'll be testing against 
> for Windows. I don't have Tiger installed on my Powerbook, so the best 
> I can do on the Mac testing is with Panther and the default Python 2.3. 
> I might be able to do an install on a friends Mac running Tiger, but if 
> someone else can test that will be great. As usual, I can't test any 
> Linux issues.
I can help with Tiger testing. Let me know if you need anything specific
tested.
> Anyway, I would like to find out what is and isn't working for everyone 
> on this list and then update the code in CVS as appropriate along with 
> the installation instructions.
The biggest problem I've noticed on the Mac (10.3/10.4) between wxPython 
2.5.3 and
2.6 is that sometimes TextField don't populate correctly on 2.6. They 
appear
not to populate at all, but if you click in the field and drag left, the
text will scroll into view. This problem doesn't happen on wxPython 2.5.3.
There are a few other Mac-specific bugs that I've been working around,

As I'm sure you've noticed I haven't been doing any PythonCard for a 
while. Thanks to all of you that have been covering the users mailing 
list. I do want to get back to updating PythonCard, in particular for 
wxPython 2.6 and to make sure that it is working fine with Python 2.3 
and Python 2.4. My goal is to do a release before or during the first 
week of August so that it will be available when I do my OSCON 
presentation.
I'm still running Windows 2000, so that's what I'll be testing against 
for Windows. I don't have Tiger installed on my Powerbook, so the best 
I can do on the Mac testing is with Panther and the default Python 2.3. 
I might be able to do an install on a friends Mac running Tiger, but if 
someone else can test that will be great. As usual, I can't test any 
Linux issues.
Anyway, I would like to find out what is and isn't working for everyone 
on this list and then update the code in CVS as appropriate along with 
the installation instructions.
ka

For Windows XP, PythonCard .81, wxPython 2.5.3:
I've noticed that sometimes when I launch my app with the -n for Namespace 
Viewer, 
the main app becomes unreponsive. The namespace viewer works fine, but I 
can't
make the main window for my app gain the focus.
I have yet to try this with newer versions of wxPython, and have some 
apprehension
about changing wxPython version until I hear that the newer versions have 
been
blessed. On Windows and wxPython 2.5.3 I've yet to encounter any other 
significant
problems.

Oops, right. I meant Monday May 23.
Ste...@ao... wrote on 05/22/2005 07:46:20 AM:
> >50ドル if it's fixed by Monday May 22! 
> >I can send via Paypal or check.
> 
> The last time May 22nd was a Monday was year 2000.
> 
> Time travel should be worth more than 50ドル!
> 
> ;)
> 
> ---Tom Nally, New Orleans

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.13 - Release Date: 19/05/2005

More thoughts on the newResourceEditor v.3
When both name and text of a TextField have the "specified" box unchecked
(this is the default after creating a new TextField), often I find
myself wanting to delete the text attribute. When I do so, the 
widget gets renamed to the letter 'a'. In those cases, I would prefer
that the widget name attribute be left alone.
When renaming a widget, on the other hand, I think it's useful for
the text property to update itself when it's not marked 'specified'.
I guess I'm arguing that the "specified" checkbox be dropped from the
widget name, but kept for the widget text and label attributes.
Sidenote: If we end up keeping the "specified" checkbox next to
the widget name, and continue with the auto-naming based on the
widget text or label, we probably should stop using underscores
in the auto-naming, since underscores have special meaning
in PythonCard events (as in on_widgetName_mouseClick).