pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Newbie..... Anything to whatch out for?

[Winston W. <win...@st...>]

I'd say the main thing you have to watch out for is testing on each  
platform.  There are still minor differences in each system.

-Winston

On Jun 5, 2006, at 11:46 AM, Lance Haig wrote:

> Hi,
>
> I am working my way through Alan Gaulds book for beginners as I  
> have no programming experience.
>
> I have an idea and thought it best to ask here, is there anything  
> to watch out for if you want to produce something that runs on  
> Microsoft OSX and Linux. I just want to keep this in mind when I  
> start doing the planning.
>
> Hope it is ok to ask here
>
> Thanks
>
> Lance
>
> -- 
> Lance Haig
> Director
> Work: 07967967108
> Mobile: 07967967108
> Email: lh...@ha...
> http://www.linkedin.com/in/lancehaig
> <hmail1.jpg>
> HaigMail dot Com
> See who we know in commonWant a signature like this?
> <hmail1.jpg>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users




______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

Re: [Pythoncard-users] Trivial bug report - missing tooltip in tree control

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

XXXXXXXXXXX wrote:

>
>Well, I thought I'd go for the record on the longest gap between 
>messages in a thread :-)
>
>Finally got around to applying the tooltip modification...thanks Alex.
>
>I also got a chance to test this out on OSX. Those WX docs appear to be 
>correct - you can't set the tooltips for individual tree items in OSX. 
>But it does mean that the OSX version doesn't suffer from the 
>bug...er...feature whereby the tooltip for the entire control stops 
>working once you mouse over one if its items.
>  
>

Well, it may have been a long gap, but you sent this at just the right 
time. I had found a use for item-specific tooltips, and had planned to 
implement that sometime in the next week. I had forgotten this was 
Windows only - now that you've reminded me of that restriction, I'll 
either not implement it at all, or move its priority (way) down and do 
it later.

btw - my plan was to use it for the items in the sizer-tree in the 
layoutEditor. Each item (sizer, spacer or component) in the tree has 
various properties associated with layout; currently you can view (or 
edit) these with a context-click and menu selection, and I thought it 
would be convenient to be able to simply hover the mouse over an item 
and have the tooltip display its properties.



-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006

[Pythoncard-users] Newbie..... Anything to whatch out for?

[Lance H. <lh...@ha...>]

Hi,

I am working my way through Alan Gaulds book for beginners as I have no 
programming experience.

I have an idea and thought it best to ask here, is there anything to 
watch out for if you want to produce something that runs on Microsoft 
OSX and Linux. I just want to keep this in mind when I start doing the 
planning.

Hope it is ok to ask here

Thanks

Lance

-- 
*Lance Haig*
Director 	

*Work:* 07967967108
*Mobile:* 07967967108
	*Email:* lh...@ha... <mailto:lh...@ha...>
*http://www.linkedin.com/in/lancehaig
*
* * 		*HaigMail dot Com* <http://www.haigmail.com>

See who we know in common <http://www.linkedin.com/e/wwk/6074413/> 	Want 
a signature like this? <http://www.linkedin.com/e/sig/6074413/>

Re: [Pythoncard-users] Trivial bug report - missing tooltip in tree control

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 15/12/05 19:17, XXXXXXXXXXX wrote:
> On 15/12/05 12:16, Alex Tweedly wrote:
> 
>> Oh - you mean you put actual data in it :-)
> 
> :-) A tree-less tree control...
> 
>> I didn't get that far - just created a tree control and checked that a 
>> tooltip then worked.
>>
>>> I'll try upgrading like you suggest.
>>
>>
>> Won't help.     It's not a bug, it's a feature :-)
>>
>> At least on Windows, you can set the tooltip individually for each 
>> item (from the WX docs it does look as though this is Windows only, 
>> but I'm not in a position to try it on other systems just now).
> 
> Wha...different tooltips per item!
> 
> Actually...now that I think about it...I can't think of any use for one 
> tooltip per item. But thanks for solving the mystery. I just need to 
> follow your example and apply the same tooltip to all items.
> 
> I can't check whether the same applies to OSX either, since my iBook's 
> motherboard recently kicked the bucket :-(

Well, I thought I'd go for the record on the longest gap between 
messages in a thread :-)

Finally got around to applying the tooltip modification...thanks Alex.

I also got a chance to test this out on OSX. Those WX docs appear to be 
correct - you can't set the tooltips for individual tree items in OSX. 
But it does mean that the OSX version doesn't suffer from the 
bug...er...feature whereby the tooltip for the entire control stops 
working once you mouse over one if its items.

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] Straw Poll - Screen Size (Possibly OT)

[phil j. <int...@gm...>]

I vote for sticking to 800 X 600.

If you have a bigger monitor, smaller dialogues are not a huge
problem. But if you have some kind of old / cool new tiny handheld
origami-style computer big dialogues are.

What would be really cool though would be dialogues where you could
increase or shrink the text as you can with Firefox with ctrl-+ and
ctrl- -

On 6/5/06, Winston Wolff <win...@st...> wrote:
> Here are some reasons why we might want to keep 800x600 as a minimum
> resolution:
>
>         =95 When I give presentations, I reduce the resolution to 800x600
> because otherwise things get too small for people at the back room to
> read.
>         =95 There is talk on the edu-sig Python mailing list of using
> PythonCard with Ebuntu in an educational package of development
> tools, i.e. teach kids to program using Python and PythonCard.  The
> systems they want to deploy on include that $100 MIT computer.  I
> think the resolution of that is 800x600.
>
> -Winston
>
>
> On Jun 5, 2006, at 8:39 AM, Phil Edwards wrote:
>
> > Whenever I've released software into the big bad world, I've (up to
> > now) made
> > a conscious effort to ensure that all main windows and dialogs
> > require a
> > screen resolution of no more than 800x600. Looking around the
> > office where
> > I'm sitting at the moment, it seems that nobody uses a screen
> > resolution this
> > small any more. For instance, the laptop I'm typing this on has a
> > 1920x1200
> > widescreen display, I have a 1600x1200 CRT sitting next to me, the
> > guy to my
> > left runs a pair of 15-inch TFTs at 1024x768 each, the dev team
> > have 19-inch
> > TFTs running at resolutions up to 1600x1200.
> >
> > I wonder if the list feels there is a minimum reasonable screen
> > resolution to
> > expect most people to be running at? Or is it better from a pure
> > usability
> > point of view to keep individual windows as simple as possible even
> > if that
> > means having to employ multi-page dialogs?
> >
> > Even a single step up from 800x600 to 1024x768 gives a 60% increase in
> > available display area based purely on the total pixel count. I'm
> > conscious
> > of the temptation to try and fit ever more buttons, text boxes and
> > other
> > components onto a bigger screen, but at the same time I know from past
> > experience that many end-users of software I've written are happier
> > to have
> > less clutter per window, even if that means having to click their
> > way through
> > more than one window to accomplish a particular task.
> >
> > Just a bit of random Monday afternoon musing, I'm interested to
> > know if people
> > have any strong opinions one way or another.
> >
> > --
> >
> > Regards
> >
> > Phil Edwards
> > Brighton, UK
> >
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>
>
>
> ______________________________________________________
> winston wolff - (646) 827-2242 - http://www.stratolab.com
> learning by creating - video game courses for kids in new york
>
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] Straw Poll - Screen Size (Possibly OT)

[Winston W. <win...@st...>]

Here are some reasons why we might want to keep 800x600 as a minimum =20
resolution:

	=95 When I give presentations, I reduce the resolution to =
800x600 =20
because otherwise things get too small for people at the back room to =20=

read.
	=95 There is talk on the edu-sig Python mailing list of using =20=

PythonCard with Ebuntu in an educational package of development =20
tools, i.e. teach kids to program using Python and PythonCard.  The =20
systems they want to deploy on include that $100 MIT computer.  I =20
think the resolution of that is 800x600.

-Winston


On Jun 5, 2006, at 8:39 AM, Phil Edwards wrote:

> Whenever I've released software into the big bad world, I've (up to =20=

> now) made
> a conscious effort to ensure that all main windows and dialogs =20
> require a
> screen resolution of no more than 800x600. Looking around the =20
> office where
> I'm sitting at the moment, it seems that nobody uses a screen =20
> resolution this
> small any more. For instance, the laptop I'm typing this on has a =20
> 1920x1200
> widescreen display, I have a 1600x1200 CRT sitting next to me, the =20
> guy to my
> left runs a pair of 15-inch TFTs at 1024x768 each, the dev team =20
> have 19-inch
> TFTs running at resolutions up to 1600x1200.
>
> I wonder if the list feels there is a minimum reasonable screen =20
> resolution to
> expect most people to be running at? Or is it better from a pure =20
> usability
> point of view to keep individual windows as simple as possible even =20=

> if that
> means having to employ multi-page dialogs?
>
> Even a single step up from 800x600 to 1024x768 gives a 60% increase in
> available display area based purely on the total pixel count. I'm =20
> conscious
> of the temptation to try and fit ever more buttons, text boxes and =20
> other
> components onto a bigger screen, but at the same time I know from past
> experience that many end-users of software I've written are happier =20=

> to have
> less clutter per window, even if that means having to click their =20
> way through
> more than one window to accomplish a particular task.
>
> Just a bit of random Monday afternoon musing, I'm interested to =20
> know if people
> have any strong opinions one way or another.
>
> --=20
>
> Regards
>
> Phil Edwards
> Brighton, UK
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users




______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

[Pythoncard-users] Straw Poll - Screen Size (Possibly OT)

[Phil E. <ph...@li...>]

Whenever I've released software into the big bad world, I've (up to now) made 
a conscious effort to ensure that all main windows and dialogs require a 
screen resolution of no more than 800x600. Looking around the office where 
I'm sitting at the moment, it seems that nobody uses a screen resolution this 
small any more. For instance, the laptop I'm typing this on has a 1920x1200 
widescreen display, I have a 1600x1200 CRT sitting next to me, the guy to my 
left runs a pair of 15-inch TFTs at 1024x768 each, the dev team have 19-inch 
TFTs running at resolutions up to 1600x1200.

I wonder if the list feels there is a minimum reasonable screen resolution to 
expect most people to be running at? Or is it better from a pure usability 
point of view to keep individual windows as simple as possible even if that 
means having to employ multi-page dialogs?

Even a single step up from 800x600 to 1024x768 gives a 60% increase in 
available display area based purely on the total pixel count. I'm conscious 
of the temptation to try and fit ever more buttons, text boxes and other 
components onto a bigger screen, but at the same time I know from past 
experience that many end-users of software I've written are happier to have 
less clutter per window, even if that means having to click their way through 
more than one window to accomplish a particular task.

Just a bit of random Monday afternoon musing, I'm interested to know if people 
have any strong opinions one way or another.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] Pythoncard with Sizers - testing update.

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

There's a new version of the PythonCard "layoutEditor with Sizers 
included" now available.

The only change is that it now has a mode where you can display the main 
(i.e. layout) window using the sizers that have been defined. This means 
that you get immediate feedback on any changes to the sizer allocation 
or properties, so is much better for getting the sizer layout to look 
just right.

Existing testers : this can be found in the same place as the earlier 
version, but now called PythonCard-snap-1.1.zip

If you'd like to test it - please get in touch with me for the URL, etc.

Update notes
-------------
DONE SINCE 1.0

# switch to using sizer-based layout for main window.
There is a new Menu entry :  Options / Show Layout with Sizers

When this is checked, the sizers defined are used for the layout
display within the layoutEditor, and when unchecked the static
component positions are used instead.  When the resource file is
written, the static positions are written, regardless of which
display style is being used.

Note there are some minor anomalies when you switch display mode
(e.g. if you have components selected, they will be repositioned by
the sizers - but their 'handles' won't be). If you find any of these
get in the way of working (as opposed to being simply a minor annoyance
do let me know about them).


Also, the initial size of components (such as the textArea) is still
significant, since it sets the minimum size to be used. Currently,
this will always be the size used in the static layout - so sometimes
you may need to flip back to the static display mode in order to
change a component size.

Note that same anomaly exists if you manipulate the layout the layout
within the sizer window (e.g. you swap the order of two components
within a sizer, or change a component's border value, or ...) - the
components move around but the handles don't always keep up.




-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/354 - Release Date: 01/06/2006

[Pythoncard-users] Sizers in layoutEditor

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

Docs for snapshot 1.0


Almost everything for sizers is done from the new "Sizer" Window. It 
should be open by default when the layoutEditor starts up, or can be 
made (in)visible from the menu View / Sizer window (Ctrl-I)

The sizer window shows the complete sizer tree, including a root called 
"ALL" (which isn't really used directly for anything). Beneath this 
there are two nodes :
  TOP SIZER, within which the real sizer tree will be built up
  UNPLACED which holds any components which have not yet been placed.

If you open a pre-existing resource file (i.e. no sizer info), then all 
the components will be be put into the UNPLACED section.

At the top of the sizer window are 3 buttons, used to create vertical, 
horizontal and grid sizers (last one is not yet operational, of course). 
(There will later be a button for adding a spacer).  Clicking on one of 
these buttons will create a new sizer - any components which have been 
selected in the main layout window (and which are not yet placed) will 
be put into that sizer, in the order they were selected (i.e. in the 
same order as they appear in the list in the Property Editor window).  
This new sizer will be put at the end of the unplaced section.

(Note - if you do this when some of the selected components are already 
placed, it will fail with an error that a component is already placed. 
Need to decide whether to proceed with placing the other components. 
Also, components which have been put into a sizer, but that sizer is 
still unplaced do not count, they are still considered as ;unplaced; and 
hence may be moved into the new sizer. Is this right ?  I'm unsure.)

Apart from this, almost everything in the sizer window is done by 
selecting an element within the tree, and then context-clicking 
(right-clicking on Win or Mac) to bring up a context-sensitive menu.  
This menu will contain the relevant items from the following list (not 
all apply in all cases):

1. Edit Properties .....
   Brings up a dialog allowing you to set properties of the item. These are:
       border (currently applies to all sides)
       horizontal growth   (value between 0 and 100)
       horizontal align (will only be used if the horGrowth is 0, *and* 
if the item is placed within a vertical sizer)
       hor span - only useful for grid sizers
       verGrowth, ver align, ver span - same, but vertically.

(For those who are already familiar with sizers in wxPython: the 
'growth'  values are used as either the proportion or the 
setting/non-setting of the wx.EXPAND flag in the parent sizer).

If the item in question is a sizer, rather than a component or spacer, 
the growth values are in the range -1:100, where 0:100 have the same 
meaning as for components. The special value of "-1" means that the 
sizer should determine whether to set its growth based on the settings 
of each of its children; if any of them have a non-zero growth value, 
then the sizer will also. This is the default for a sizer.

(Known bug : spacers currently allow -1, but it doesn't mean anything - 
will fix for next release).

2. Delete     (Should perhaps be changed to "remove" ?? )
If it's a component - it is moved to UNPLACED
If it's a spacer - it is deleted
If it's a sizer, it is deleted, and any children will be moved to unplaced.

3. Insert selected components before here
    Insert selected components into here    (only for sizers)
    Insert selected components after here

These all do the obvious - and selected components (if not already 
placed) will be inserted before / after / into the selected item.
Note that for a sizer, components inserted into it are put at the end of 
the sizer.

4. Move up a level.
The selected item is taken *out* of its current sizer, and placed 
immediately *after* it.

5. Add empty slots to sizer
Does nothing, may later be deleted. (?)

6. Insert spacer after here.
Inserts a spacer after the selected item.


The other thing you can do is drag-n-drop items within the sizer tree. 
Click and hold on any item, drag it to another item and release it.
If you drop onto a component or spacer, the dragged item is placed 
*after* that component; if yo drop onto a sizer, the dragged item is put 
*into* the sizer. [I felt was too intrusive and slowed things too much 
to have a dialog to choose here, and was too "indirect" to  have a 
setting for placing before / into / after on a drag operation - feedback 
welcome.]

This means that you can't easily drag/drop items to all places you might 
want to put them (e.g. after a sizer). Use "Move up a level" to do this.

That's about it - at any time you can Save the file, and the Run it to 
see how it behaves a a sizer-based design (assuming you have placed some 
components - if none are placed, the sizer will not be used). Note there 
are settings within menu Edit / Background info... and Dialog info ... 
to control the resizability and whether or not to use sizers.  There is 
also a "Run option" to give some visual feedback on where the sizers are.

Remember this version also has Undo / Redo implemented, please test that 
also.


Other requested feedback :

Should I take over the Property Window rather than using a separate 
Sizer Window ?
   if the "use sizer" flag is set, take the right-hand half of the 
Property Editor window for the sizer tree.
   if  it is not set, stick to current usage (i.e. align, distribute, 
etc. controls).
This would require another button to switch between sizer tree visible 
and individual component properties visible (only when there is a single 
component selected - when there is either no component, or multiple 
components, it would simply show the sizer tree).


btw - there are some sample sizer layouts in 
tools/resourceEditor/t1.rsrc.py, t2.rsrc.py, t3.rsrc.py

Also, if you try out taking the existing samples and adding sizers to 
them, you need to be aware that some of them already implement sizers in 
their code - this generally needs to be removed because it will 
over-ride the resource-based sizer mechanism.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006

Re: [Pythoncard-users] Adventurous testers wanted ....

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

Winston Wolff wrote:

> I'm very interested in using sizers so I will make some time to test  
> for you.  I can test on Mac OS X only though, no Linux.
>
> Regarding distribution size, I think 7MB is no problem, and it makes  
> things simpler all around to have one file to distribute.

Thanks for giving it a test - I'll send download instructions privately, 
and initial documentation will be posted here soon. Once it gets to 
Beta, I'll make the download public, but for now it is an alpha release 
- please remember to backup your files and your original PythonCard 
installation).

I agree it's better to keep distribution simple (and 7Mb isn't so bad 
these days); I've put it up as a  .zip file (I know my Mac can unzip 
this OK, so I assume it's built-in on all Macs, but if that's wrong, let 
me know and I'll put up a .tar.gz as well).

Anyone else willing to test, please get in touch.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006

Re: [Pythoncard-users] Adventurous testers wanted ....

[Winston W. <win...@st...>]

I'm very interested in using sizers so I will make some time to test  
for you.  I can test on Mac OS X only though, no Linux.

Regarding distribution size, I think 7MB is no problem, and it makes  
things simpler all around to have one file to distribute.

-Winston

On May 29, 2006, at 7:28 PM, Alex Tweedly wrote:

>
> I'm about ready for an alpha release of the sizer additions to the  
> layout editor, so I'm looking for a small number of people to test it.
>
> Note that I do not want to put any of this code into CVS yet,  
> possibly not for some time, so trying it out will involve some  
> effort in downloading and installing. It requires changes to quite  
> a lot of PythonCard, not just within the layoutEditor.
>
> It is (intended to be) upward and downward compatible
> - old (existing) resource files work fine
> - new resource files created with this will work fine on the old  
> PythonCard
> but of course, it is an alpha release so there may be bugs, and  
> also it MAY create resource files which are not acceptable to later  
> versions (should be easy to get around, at the very worst a simple  
> manual edit of the resource file).
>
> Documentation will be scant (i.e. this email and another like it),  
> so it would be helpful for testers to be at least partially aware  
> of how sizers work in wxPython already.
>
> What does it support ?
>  Box Sizers only !!
>  spacers (fixed and stretchable)
>  new "background info"  selection of "use sizers" to control  
> whether or not to use the sizer info
>  new "Run Option"  (-i) to control the display of indicators to  
> help see where sizers are
>
> What does it not support ?
>  Grid sizers
>  incomplete set of insertion options
>  no drag and drop form the layout window (or prop editor window)  
> into sizer tree
>      (but there is d'n'd within the sizer tree, and also "select  
> and drop" from layout window into sizer tree / new sizer)
>  no slick graphics in the sizer tree (should have different images  
> per sizer/comp but don't yet)
>
> Anyone interested, please let me know (including system, wxPython  
> versions, etc.) I've tested on Win XP (lots) and Mac (some), but  
> don't have access to  Linux .
>
> Also, let me know what you think about distribution. PythonCard is 7 
> + Mb, still over 3 when zipped, so I've been thinking about  
> distributing without samples, docs and most other tools, which  
> brings it down to ~500Kb - small enough I could always distribute  
> complete snapshots, minimizing the chances of confusion. Would that  
> be convenient to use ?
>
>
>
> -- 
> Alex Tweedly       http://www.tweedly.net
>
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date:  
> 28/05/2006
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and  
> Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users




______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

Re: [Pythoncard-users] Error in PythonCard Walk-through No. 1?

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

Rodolfo Gouveia wrote:

>I was following the walkthrough when I reached the "Changing a PythonCard 
>Application". There it's said to modify the event handler on_menuFileAbout_select
>to display a result when clicking the About menu. But after the change you the
>following is written:
>"Now when the user selects the Exit menu, rather than doing nothing..."
>Shouldn't this be the *About* menu?
>Again a few paragraphs later you mention:
>"When the window appears, select the Exit option from the File menu."
>Now I dunno if the error is in the code or the description.
> 
>  
>
The error is in the description - it should be *About*    (there's 
another occurrence of the same error in Walkthrough 2, saying "Exit" 
where it should say "About" ).

It was discussed on the developers' list last week, and I said then I'd 
fix it, but I got sidetracked with sizers.

I'll put this fix into CVS tonight. Please let us know if you find 
anything else - it's very hard to follow walkthroughs precisely when 
you've done them dozens of times already, your mind sees what the text 
*should* say, not what it *does* say :-)

Thanks

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006

[Pythoncard-users] Error in PythonCard Walk-through No. 1?

[Rodolfo G. <rgo...@co...>]

I was following the walkthrough when I reached the "Changing a PythonCard 
Application". There it's said to modify the event handler on_menuFileAbout_select
to display a result when clicking the About menu. But after the change you the
following is written:
"Now when the user selects the Exit menu, rather than doing nothing..."
Shouldn't this be the *About* menu?
Again a few paragraphs later you mention:
"When the window appears, select the Exit option from the File menu."
Now I dunno if the error is in the code or the description.


Rodolfo Gouveia

Re: [Pythoncard-users] Adventurous testers wanted ....

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

Luca Mandolesi wrote:

>Sorry, I don't understand how add a multi tab in a
>notebook whit pythonCard. Some suggestions?
>Tank you.
>
>  
>
There's an example of usage in 
PythonCard/samples/testNotebook/testNotebook.py

It's also done in the code editor 
(PythonCard/tools/oneEditor/tabcodeEditor.py) - has the advantage of 
being a real, normal usage rather than an example, but it is spread 
around amongst quite a lot of code, so not so obvious.

That should help, but please ask if you have any problems or have any 
further questions.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006

Re: [Pythoncard-users] Adventurous testers wanted ....

[Luca M. <man...@ya...>]

Sorry, I don't understand how add a multi tab in a
notebook whit pythonCard. Some suggestions?
Tank you.


Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

[Pythoncard-users] Adventurous testers wanted ....

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

I'm about ready for an alpha release of the sizer additions to the 
layout editor, so I'm looking for a small number of people to test it.

Note that I do not want to put any of this code into CVS yet, possibly 
not for some time, so trying it out will involve some effort in 
downloading and installing. It requires changes to quite a lot of 
PythonCard, not just within the layoutEditor.

It is (intended to be) upward and downward compatible
 - old (existing) resource files work fine
 - new resource files created with this will work fine on the old PythonCard
but of course, it is an alpha release so there may be bugs, and also it 
MAY create resource files which are not acceptable to later versions 
(should be easy to get around, at the very worst a simple manual edit of 
the resource file).

Documentation will be scant (i.e. this email and another like it), so it 
would be helpful for testers to be at least partially aware of how 
sizers work in wxPython already.

What does it support ?
  Box Sizers only !!
  spacers (fixed and stretchable)
  new "background info"  selection of "use sizers" to control whether or 
not to use the sizer info
  new "Run Option"  (-i) to control the display of indicators to help 
see where sizers are

What does it not support ?
  Grid sizers
  incomplete set of insertion options
  no drag and drop form the layout window (or prop editor window) into 
sizer tree
      (but there is d'n'd within the sizer tree, and also "select and 
drop" from layout window into sizer tree / new sizer)
  no slick graphics in the sizer tree (should have different images per 
sizer/comp but don't yet)

Anyone interested, please let me know (including system, wxPython 
versions, etc.) I've tested on Win XP (lots) and Mac (some), but don't 
have access to  Linux .

Also, let me know what you think about distribution. PythonCard is 7+ 
Mb, still over 3 when zipped, so I've been thinking about distributing 
without samples, docs and most other tools, which brings it down to 
~500Kb - small enough I could always distribute complete snapshots, 
minimizing the chances of confusion. Would that be convenient to use ?



-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006

Re: [Pythoncard-users] Cannot install

[Luca M. <man...@ya...>]

Hi, I'm a beginner in PythonCard world, but I use only
Mac and I have installed PythonCard more times on Mac
Os X 10.3 without problems.

I'm not sure to resolve your problem, but if you
explain me exactly, it's possible that I had just
resolved the same.

Sorry for my english.

Mando

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

Re: [Pythoncard-users] Platform specific restrictions.

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

Brad Allen wrote:

> Thanks for bringing this up, Alex. I hadn't tried any of those 
> settings on the
> Mac. The only limitation I was aware of was on button height; apparently
> there is UI standard for button height on Mac OS X, and wx keeps you
> from violating it while running on the Mac. If you create a tall
> button on another platform, and then run it on a Mac, the button
> smashes down to the standard size, leaving your button label hanging
> outside the button (usually above).
>
Thanks Brad - I had seen that one, but had forgotten it again

> I like the idea of a popping up warning dialog when using LayoutEditor
> to change a widget in a way that causes problems with other platforms.
> It should explain in each case which platform doesn't support the change,
> and offer to either cancel the change or apply anyway. 

I think it would more likely be generic
   "feature not evenly supported on all platforms, see 
http://wiki.wxpython.org/index.cgi/PythonCardPlatformRestrictions
    for list of known restrictions"

> There could also be a checkbox in the dialog saying "Don't warn me 
> about this again."
>
> For those who are targeting only a single platform, and find the warnings
> annoying, create a preference setting for multiresource editor:
>
> checkbox: "Disable All Cross-Platform Warnings"
>
>>  If that was a preference - should it be per-user, or per project ?
>
>
> I didn't know that PythonCard had a concept of "project". I had
> assumed the preference would be per user, but if you can tie it to
> a project that would be great. Some projects target cross-platform,
> while others do not.
>
It doesn't have a 'project' concept - I should have said "per resource file"



-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/348 - Release Date: 25/05/2006

Re: [Pythoncard-users] Platform specific restrictions.

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 26/5/06 14:45, Alex Tweedly wrote:
 >
> It would be good to not only document this somewhere, but (since it will 
> be an easily overlooked footnote in the docs) also make it more obvious 
> to a user when they try to set properties that will not be reasonably 
> honoured cross-platform. This would be especially helpful if they are 
> setting a property while on a system that doesn't really support it - 
> but I think should be done anyway to help people design cross-platform 
> apps if they so desire.
> 
> Would a dialog / preference be too intrusive ?   Something like
> 
>   You have set a property that is not supported on your current platform.
>   [ ]  Don't give this warning again.                         ( OK )
> 
> and also same thing but "... supported on some other platforms."
> 
> If that was a preference - should it be per-user, or per project ?
> 
> Or would it be better to simply document it as prominently as we can ?
> 

IMHO I would just create a page in the documentation and on the site (or 
wiki) that lists what does or doesn't work on each platform, and try to 
keep that up-to-date. If you do add it, I would vote for per-user, so I 
can switch it off once and not see it again. My PythonCard projects 
currently just target Windows, but I do some early design and coding on 
my Mac, so the warning doesn't help me.

Of course, if at some point I target OSX as a release platform and 
forget about the limitations it's my own fault.

I would have thought that adding the dialog could end up being an 
ongoing chore you'd rather not have to deal with. Who knows what might 
happen in the future, e.g.
1) Microsoft suddenly starts following Apple's ideas and starts 
restricting what properties can be changed in a late Vista beta;
2) Apple continues it's "do as I say, not as I do" approach when it 
comes to its HI guidelines, and suddenly 10.5 comes out with some of the 
properties now available for amending;
3) The wxWidgets team replaces some of the Apple components with their 
own versions in which you can start setting the properties.

OK, none of the above could happen, but who knows - you might end up 
having to implement a dialog that needs to test platform, OS version and 
wxPython version. And having to release a new version of PythonCard 
whenever one of the above possible scenarios happens, unless you 
implement a list of affected components that are held in a config. file.

Of course, it's at this point that you tell me you've already added it, 
it does all the above and it only took a few minutes.....;-)

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] Platform specific restrictions.

[Brad A. <bra...@ma...>]

Alex Tweedly wrote:

>The Mac OS X guidelines, indeed the OS provided controls, have some 
>restrictions on what they allow. Since wxWidgets uses these 
>controls, wxPython and PythonCard have the same restrictions. 
>Currently those restrictions are not reflected in the layoutEditor, 
>which can lead users to think there is a bug in the layoutEditor 
>(and therefore PythonCard in general). (btw - I wouldn't be at all 
>surprised if there were indeed bugs in PythonCard and/or the 
>layoutEditor that exacerbate these problems - but so far I haven't 
>seen any confirmed cases).
>
>There probably are lots of such restrictions, but the ones I  have 
>come across are
>- textfields (i.e. single line TextCtrl) does not support setting 
>the backgroundColour
>- textarea (i.e. multi-line TextCtrl) does not support alignment 
>(other than left)
>- button does not support setting foregroundColour
>- button does not (adequately) support setting backgroundColour
>         (the rectangle "behind" the button is set, but not within 
>the button itself - ugly !!)

Thanks for bringing this up, Alex. I hadn't tried any of those settings on the
Mac. The only limitation I was aware of was on button height; apparently
there is UI standard for button height on Mac OS X, and wx keeps you
from violating it while running on the Mac. If you create a tall
button on another platform, and then run it on a Mac, the button
smashes down to the standard size, leaving your button label hanging
outside the button (usually above).

I like the idea of a popping up warning dialog when using LayoutEditor
to change a widget in a way that causes problems with other platforms.
It should explain in each case which platform doesn't support the change,
and offer to either cancel the change or apply anyway. There could also
be a checkbox in the dialog saying "Don't warn me about this again."

For those who are targeting only a single platform, and find the warnings
annoying, create a preference setting for multiresource editor:

checkbox: "Disable All Cross-Platform Warnings"

>  If that was a preference - should it be per-user, or per project ?

I didn't know that PythonCard had a concept of "project". I had
assumed the preference would be per user, but if you can tie it to
a project that would be great. Some projects target cross-platform,
while others do not.

[Pythoncard-users] Platform specific restrictions.

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

The Mac OS X guidelines, indeed the OS provided controls, have some 
restrictions on what they allow. Since wxWidgets uses these controls, 
wxPython and PythonCard have the same restrictions. Currently those 
restrictions are not reflected in the layoutEditor, which can lead users 
to think there is a bug in the layoutEditor (and therefore PythonCard in 
general). (btw - I wouldn't be at all surprised if there were indeed 
bugs in PythonCard and/or the layoutEditor that exacerbate these 
problems - but so far I haven't seen any confirmed cases).

There probably are lots of such restrictions, but the ones I  have come 
across are
 - textfields (i.e. single line TextCtrl) does not support setting the 
backgroundColour
 - textarea (i.e. multi-line TextCtrl) does not support alignment (other 
than left)
 - button does not support setting foregroundColour
 - button does not (adequately) support setting backgroundColour
         (the rectangle "behind" the button is set, but not within the 
button itself - ugly !!)

It would be good to not only document this somewhere, but (since it will 
be an easily overlooked footnote in the docs) also make it more obvious 
to a user when they try to set properties that will not be reasonably 
honoured cross-platform. This would be especially helpful if they are 
setting a property while on a system that doesn't really support it - 
but I think should be done anyway to help people design cross-platform 
apps if they so desire.

Would a dialog / preference be too intrusive ?   Something like
 
   You have set a property that is not supported on your current platform.
   [ ]  Don't give this warning again.                         ( OK )

and also same thing but "... supported on some other platforms."

If that was a preference - should it be per-user, or per project ?

Or would it be better to simply document it as prominently as we can ?

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/348 - Release Date: 25/05/2006

Re: [Pythoncard-users] Cannot install

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

Rod wrote:

> Hi,
>
> I am trying to install Pythoncard on Mac OS X 10.3.9, I already had 
> wxPython installed and upgraded MacPython to 2.3.2 as requested. 
> However I keep getting the error message below:
>
> error: invalid Python installation: unable to open 
> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/Makefile 
> (No such file or directory)
>
> MacPython does seem to be installed - indeed I have used it with other 
> tools, and everything is there except the Makefile.
>
> Does anyone know how I could overcome this problem? Should I reinstall 
> MacPython - but I see this is not advised on the MacPython website.

Rod,

I'm not (at all) a Mac expert, so I may be missing something (and 
hopefully the someone who does understand the Mac better will chime in).

When do you get this message ?

(When I installed Pythoncard on Mac, all I did was
  - downloaded the .tar.gz file
 - uncompressed it (by d-click in Finder( to get a .tar file)
 - unpacked it (again by d-click in Finder) (to get a whole PythonCard 
directory)

and either  put that directory inside my Python2.4/Lib/site-packages or 
(more likely) put a pythoncard.pth file inside Python2.4/lib/site-packages
(don't remember which I did, and the Mac is unavailable at the moment).

None of that is really an 'install' that seems likely to lead to an 
error message such as you get - so I would like to know if you get that 
while installing PythonCard or when you try to run a PythonCard app ?

I very much doubt that it is an error directly from PythonCard - there 
is no reference to any Makefile within the PythonCard-0.8.2.tar.gz 
download file for OS X.  I fear that the problem is with your 
re-installation of MacPython; I have vague memories of having seen dire 
warnings about installation problems with MacPython, but don't remember 
what they were (this was before I got a Mac). When I did get the Mac, I 
stuck to the pre-installed Python, until I recently added Python 2.4 - 
but I added it to /Library/Frameworks/...,  not to 
/System/Library/Frameworks/...


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date: 24/05/2006

[Pythoncard-users] Cannot install

[Rod <use...@ya...>]

Hi,

I am trying to install Pythoncard on Mac OS X 10.3.9, I already had wxPython installed and upgraded MacPython to 2.3.2 as requested. However I keep getting the error message below:

error: invalid Python installation: unable to open /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/Makefile (No such file or directory)

MacPython does seem to be installed - indeed I have used it with other tools, and everything is there except the Makefile. 

Does anyone know how I could overcome this problem? Should I reinstall MacPython - but I see this is not advised on the MacPython website.

Best,

rod

[Pythoncard-users] Updated the pythoncard.org web pages

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

I have, I think, now updated all the web pages on www.pythoncard.org to 
reflect the 0.8.2 release.

If you notice anything on there that is out of date, please let us know 
(email to this list is best).
If you notice anything on there that kind of ought to be changed or 
revised, even if it isn't exactly "wrong", please let us know about that 
too.  And things that *should* be there but aren't.

Already know about updating the walkthroughs and screenshots to include 
new tabcodeEditor and layoutEditor.
And the need for a documentation page on the "helpful" functions.

And then some day I need to overcome my fear (and dislike) of wikis and 
start updating that :-)

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date: 24/05/2006

Re: [Pythoncard-users] Announce: PythonCard 0.8.2

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

Grats and thanks to Alex for learning the ropes on getting a release  
out and doing the work this time around. There are actually quite a  
few more little bug fixes in this release than the release notes  
might lead you to believe so I encourage everyone to upgrade and then  
let us know what is still broken so that can be fixed ASAP. Try out  
Alex's new layoutEditor, the tabcodeEditor, etc. and give us some  
feedback.

Thanks,

ka

On May 22, 2006, at 4:20 PM, Alex Tweedly wrote:

>
>
> PythonCard is a GUI construction kit for building cross-platform   
> desktop applications on Windows, Mac OS X, and Linux.
>
> Release 0.8.2 includes over 50 sample applications and tools to  
> help  users build applications in Python, including codeEditor,  
> findfiles,  and resourceEditor (layout editor). A list of changes  
> since release 0.8.1  is at the end of this message. New samples  
> include a US-UK converter and a Sudoku solver. There are a new set  
> of "convenience" functions to assist is creating pop-up menus and  
> some commonly used custom dialogs (usage of these is demonstrated  
> in the Sudoku sample, as well as in a new sample "helpful wrappers").
>
<snip>
> Alex Tweedly
> al...@tw...
>
>
> changelog.txt changes since release 0.8
>
> Release 0.8.2 2006-05-18
> added minimized and maximized attributes to Background class
> created documentation.py module to hold code previously in widgets.py
>   for automatically generating component and background docs
> added getTextExtent and getFullTextExtent methods to BitmapCanvas
> revised internationalResourceName to support platform-specific  
> resources
> added UK <-> US to conversions.py and simplified SOAP.py module check
> updated turtle.py and bitmapcanvas.py component to force update on Mac
> renamed samples.py to samples.pyw
> added work-in-progress version of multiresourceEditor
>   (tools/resourceEditor/multiresourceEditor)
>   renamed to layoutEditor
> support customizable window styles in backgroundInfo of resourceEditor
> added convenience wrappers for pop-up menus, multiple check-box  
> dialogs,
>   multiple button dialogs (helpful.py and samples/helpfulWrappers)
> added sample for sudoku solver/helper (samples/sudoku)
> replaced StringType with StringTypes to handle Unicode better
> Major update standaloneBuilder, including support for py2exe
> allow for Python2.4 or Python 2.5 on Mac