pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] workaround for raising child windows in resourceEditor

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

On Apr 5, 2005, at 11:12 AM, bra...@om... wrote:

>
> Kevin Altis wrote on 04/01/2005 11:11:20 AM:
>
>
>  > On a related note, I never added lowercase aliases for
>  > Raise and Lower to the Background class because I
>  > wasn't sure if this would be legal since raise is a
>  > keyword and we need it for raising exceptions. If
>  > someone knows the correct syntax so that we can have a
>  > lowercase alias to Raise I'll add it to the class;
>  > perhaps I could just do a setattr or something?!
>  >
>  > raise = wx.Frame.Raise
>
> Are lowercase aliases used for a lot of other names in PythonCard or 
> wx?

wxPython wraps wxWidgets, which is C++ and the naming convention there 
is CamelCase style. All methods and attributes in PythonCard are 
mixedCase style, even if they are simply aliases for wxPython methods. 
This makes it easy to see where you are using wxPython methods and 
where you're using PythonCard framework code.

In the PythonCard shell, I added code that excludes CamelCase wxPython 
methods from showing up in the auto-complete list so that you wouldn't 
see 150+ extra confusing method names all the time, but if you type 
something like self.Show( you'll notice that the wxPython methods are 
still there and available if you want to use them.

ka

Re: [Pythoncard-users] platform-specific resource files now supported

[<bra...@om...>]

Thanks, Kevin. I hope to test out this feature sometime in the coming 
week.

Kevin Altis wrote on 03/30/2005 12:07:09 PM:

> I've revised the internationalResourceName function in
> model.py to support platform-specific resource files
> as well as language and country specific names. You
> don't have to use platform-specific files, but it is
> an option for those that want to tweak a static layout
> for each platform.
> 
> For example, using the -l (log) option under Windows
> on my system, I get the following DEBUG output which
> shows the possible valid resource filenames and the
> order they are searched for. Valid platform prefixes
> are: win, gtk, mac.
> 
> DEBUG: : Wed Mar 30 09:54:22 2005: default: ('en_US',
> 'cp1252')
> DEBUG: : Wed Mar 30 09:54:22 2005: en US
> DEBUG: : Wed Mar 30 09:54:22 2005:
> ['minimal.win.en_US.rsrc.py',
> 'minimal.win.en.rsrc.py', 'minimal.en_US.rsrc.py',
> 'minimal.en.rsrc.py', 'minimal.win.rsrc.py', 'minimal.rsrc.py']
> 
> 
> 
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Find what you need with new enhanced search. 
> http://info.mail.yahoo.com/mail_250
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Re: [Pythoncard-users] Re: Python distribution problems

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

On Apr 5, 2005, at 12:48 AM, normanwinn wrote:

> ka wrote:
>> Secondly, once we have a viable 1.x release, I would like to have a 
>> single installer option for Python, wxPython, and PythonCard on the 
>> Windows platform
>
> The very fact that you should need to contemplate this demonstrates 
> the severity of the problem. I already have versions of Python that 
> came with Zope, with Open Office, then I'll have another with 
> PythonCard and another with Dabo. Where will this stop? Each time I 
> want to upgrade I end up upgrading n versions of Python? This is 
> folly.
>
> What is the alternative? I can't have an answer as I am not at the 
> interior of an open source effort. Perhaps a standard test suite for 
> Python? Perhaps co-ordinated upgrade days? Perhaps sterner control 
> over the standard Python library?
>
> Then the exe tools. With py2exe I ended up with the tcl library in my 
> 'exe' package when compiling a command line tool! I don't know how 
> many megabytes I had to distribute. I didn't bother. I then found 
> exemaker:
>
> http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README
>
> but this, while being very handy on a system that has Python, is not a 
> standalone exe so can't be distributed.
>
> Please accept that I am not knocking (does that translate into 
> American). I hope my observations can contribute to a process that 
> will make Python tools available to all,
>
> Norman Winn
>

Actually, what I was talking about was more like an uber installer that 
would install Python, wxPython, and PythonCard in one shot, so people 
didn't have to download up to 3 different EXEs and run each installer 
separately. Another way to think of it would be Python that included 
wxPython and PythonCard as part of the distribution. This wouldn't be a 
special copy of Python like you have with some Zope/Plone and 
OpenOffice installs. Furthermore, the individual PythonCard release 
zip, tar.gz, and EXE installer would still be there. I'll be adding a 
Mac disk image installer of the PythonCard distribution as soon as I 
figure that one out. :)

This is a separate issue from building standalones for end-users. 
py2exe and py2app both do their best to figure out required modules. In 
the case of PythonCard, there is an import of the Image (PIL) module to 
support easy display of PIL images in PythonCard apps, so a generic 
standalone build using py2exe will bring in PIL and thus tkinter and 
its Tcl code. But it is simple enough to exclude modules and libraries 
that you know you're app doesn't use and this is even documented in the 
minimalStandalone example. The standaloneBuilder tool will likely have 
options for excluding common extra libs that most apps wouldn't use.

One of the biggest problems with all standalone applications is simply 
the size of the distribution. It is definitely nicer if you're able to 
just distribute the plain Python code of a normal PythonCard 
application, so in a controlled environment I would recommend that 
people go ahead and install the base Python, wxPython, and PythonCard 
packages, especially in a computer lab or enterprise installation.

On Windows, if there is a security concern over people double-clicking 
a .py, .pyw, .pyc, .pyo, etc. file then it is simple enough to remove 
that file association. A lnk file can be used to provide a full path to 
Python and the executable script with any command-line args, so that 
can be used instead of a double-clickable exe.

ka

Re: [Pythoncard-users] workaround for raising child windows in resourceEditor

[<bra...@om...>]

Kevin Altis wrote on 04/01/2005 11:11:20 AM:

> I've come up with a potential solution to raising
> child windows when the main window is selected in the
> resourceEditor. This is actually a problem for any
> PythonCard application with child windows, but seems
> to be more of annoyance in the resourceEditor as the
> Property Editor window is always being lost behind
> other application windows.
> 
> You can just drop the following code into
> resourceEditor.py and see whether this gives the
> behavior you would expect. I would like to get some
> feedback before I check it into cvs. If you have
> overlapping windows, most likely because you're
> working on a small screen, this solution of forcing a
> Raise could be very annoying, so I would likely add a
> menu item under Options that would allow you to
> disable the Raise.
> 
>     def on_activate(self, event):
>         if not hasattr(self, 'inActivate') or not
> self.inActivate:
>             self.inActivate = True
>             for c in self.GetChildren():
>                 c.Raise()
>             self.Raise()
>             self.inActivate = False
>         #event.skip()


Thanks, I will try this.


> On a related note, I never added lowercase aliases for
> Raise and Lower to the Background class because I
> wasn't sure if this would be legal since raise is a
> keyword and we need it for raising exceptions. If
> someone knows the correct syntax so that we can have a
> lowercase alias to Raise I'll add it to the class;
> perhaps I could just do a setattr or something?!
> 
> raise = wx.Frame.Raise

Are lowercase aliases used for a lot of other names in PythonCard or wx? 

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

> I certainly wouldn't argue for wxPython to enforce this, though I 
> might try to argue for Pythoncard doing it.
> But my main point is that it's a design "feature" I try to avoid, 
> and wanted to plead the case for others to avoid it too.

The point is well-taken. In future, if a customer insists on this,
I can always work around the default PythonCard behavior, but
can also suggest some of the ideas you mentioned for having
cake and eating too.

Re: [Pythoncard-users] Re: Python distribution problems

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

On Tue, 2005-04-05 at 08:48, normanwinn wrote:
> ka wrote:
> > Secondly, once we have a viable 1.x release, I would like to have a 
> > single installer option for Python, wxPython, and PythonCard on the 
> > Windows platform
> 

hmmm...not sure I can fully see the benefit of this. You only need to
install these if you are planning to write your own apps, in which case
downloading and installing them individually wouldn't present any kind
of technical challenge.

For distributing finished applications, then I would contend that you
explicitly *don't* want to have to install Python/wxPython/PythonCard -
you should be using the existing tools to bundle up your program into an
installer.

> The very fact that you should need to contemplate this demonstrates the 
> severity of the problem. I already have versions of Python that came 
> with Zope, with Open Office, then I'll have another with PythonCard and 
> another with Dabo. Where will this stop? Each time I want to upgrade I 
> end up upgrading n versions of Python? This is folly.
> 
> What is the alternative? I can't have an answer as I am not at the 
> interior of an open source effort. Perhaps a standard test suite for 
> Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over 
> the standard Python library?
> 

No, no, no, absolutely not. There is *no reason whatsoever* to have
multiple versions of Python on a machine, unless that is specifically
what you want for development purposes, etc.

> Then the exe tools. With py2exe I ended up with the tcl library in my 
> 'exe' package when compiling a command line tool! I don't know how many 
> megabytes I had to distribute. I didn't bother. I then found exemaker:
> 
> http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README
> 

If py2exe is anything like McMillan Installer, then whether to include
Tcl/TK is simply a command line option - it's set to 'on' by default due
to TkInter being the de-facto GUI library for Python for a long, long
time.

You've have made a number of valid and well-reasoned points in your
posts on this thread, but IMHO this one is just nit-picking. I think
you're just going to have to accept that the process of developing,
distributing and maintaining software to a 'professional' standard is
damned hard work, and then just make a decision as to whether to live
with that or not.

I must say, though, that I am enjoying this thread - it's probably the
most vigorous and refreshing discussion we've had on here for months,
well done Norman! ;-)

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] Python distribution problems

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

On Mon, 2005-04-04 at 18:25, Kevin Altis wrote:

> The installer scripts for py2exe (Windows) and py2app (Mac) are almost 
> identical, in fact, Bob Ippolito sent me a script variation to deal 
> with both in a single script. So, once the new standaloneBuilder tool 
> is updated to support py2exe and py2app creating PythonCard standalones 
> should be relatively painless. At Pycon, Bob fixed an earlier problem 

I'll need some help with this, as I have no experience with py2exe - my
current code relies entirely on McMillan Installer and Inno Setup. I'm
still working on adding the finishing touches to standaloneBuilder and I
expect to be checking in the finished version towards the end of this
week.

I'm just about to go off and sign up to the Pythoncard-devel mailing
list, so I'll post an announcement there when I think it's ready.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] Re: Python distribution problems

[normanwinn <nor...@on...>]

ka wrote:
> Secondly, once we have a viable 1.x release, I would like to have a 
> single installer option for Python, wxPython, and PythonCard on the 
> Windows platform

The very fact that you should need to contemplate this demonstrates the 
severity of the problem. I already have versions of Python that came 
with Zope, with Open Office, then I'll have another with PythonCard and 
another with Dabo. Where will this stop? Each time I want to upgrade I 
end up upgrading n versions of Python? This is folly.

What is the alternative? I can't have an answer as I am not at the 
interior of an open source effort. Perhaps a standard test suite for 
Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over 
the standard Python library?

Then the exe tools. With py2exe I ended up with the tcl library in my 
'exe' package when compiling a command line tool! I don't know how many 
megabytes I had to distribute. I didn't bother. I then found exemaker:

http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README

but this, while being very handy on a system that has Python, is not a 
standalone exe so can't be distributed.

Please accept that I am not knocking (does that translate into 
American). I hope my observations can contribute to a process that will 
make Python tools available to all,

Norman Winn


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

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

On Apr 4, 2005, at 12:50 PM, bra...@om... wrote:

>
> I'm still in favor of a separate data structure for tab order. It's=20
> important to be able to take some
> focusable components out of the tab order, just as you can in=20
> FileMaker. This is normally done
> with rarely used-fields which still need to be focusable by =
mouseClick.
>
> Here's a proposal for handling tab sequence:
>
> Every background rsrc gets a new property, which is a simple list of=20=

> component widget names,
> let's call it tabSeq.
>
> Rules for tabSeq:
>
> =A0 =A0 =A0 =A0 - If a widget isn't in tabSeq, it's not included in =
the tab=20
> order.
> =A0 =A0 =A0 =A0 - If a widget is deleted in Resource Editor, it must =
be=20
> deleted from tabSeq
> =A0 =A0 =A0 =A0 - If a widget is renamed in Resource Editor, it must =
be=20
> renamed in tabSeq
> =A0 =A0 =A0 =A0 - By default, at on_initialize, the focus would start =
at the=20
> first widgets in tabSeq
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this would reduce need setFocus =
statements in=20
> on_initialize)
> =A0 =A0 =A0 =A0 - Tab order in final background UI is determined by =
tabSeq
>
> The Resource Editor UI to handle this would be a modal dialog box=20
> listing focusable widgets
> of the current background, with checkboxes alongside each item. Any=20
> widget with a
> checkbox is included in the tabSeq. Widgets could be reordered by=20
> using an
> appropriate list reordering UI.
>
> Yes, this is yet another dialog box for Resource Editor, but I don't=20=

> think it would
> need to be implemented in Resource Editor right away. I for one would=20=

> be happy
> to set the values of tabSeq from a script, but hope for a future time=20=

> in which Resource
> Editor handles keeping the resource file in sync with tabSeq, and=20
> providing
> a dialog UI for managing tabSeq.
>

There are a number of issues that this raises, but the short answer is=20=

that I reject this idea. The main reason why is that a subset of the=20
focusable widgets seems like a border case at best and adds=20
complications to the resource file format, framework, and=20
resourceEditor as well as an additional thing that a user needs to=20
learn. That is contrary to the PythonCard 1.0 goals on pretty much=20
every level. At some point, people just have to use wxPython,=20
PythonCard will never duplicate all the functionality of wxPython, etc.

For the cases where you want something like this it should be=20
relatively easy for you to implement yourself either as a subclass of=20
Background or just user code stuck into your main application.

ka

Re: [Pythoncard-users] Python distribution problems

[Ed L. <ed...@le...>]

On Apr 4, 2005, at 6:24 PM, Steve Christensen wrote:

> I'm not sure how much work was required to bundle all those into a 
> single
> distribution, or how often they update the entire package.

	It's pretty straightforward in Windows, using py2exe and InnoSetup - 
that's how I created the standalone runtime for Dabo. Ieven bundle the 
Dabo code seperately, so that it isn't compiled into the DLLs, so that 
people can update the Dabo classes as often as we do.

	It's much harder under Linux, due to dynamic libraries. I've tried 
building everything statically, and it simply doesn't seem possible. 
Fortunately most Linux users aren't too afraid of compiling stuff on 
their own.

	I haven't spent much time trying this for the Mac yet, but from what 
I've read, it's somewhere in between, given that you can assume certain 
base installs (Panther, Jaguar, etc.) and build for these.

	FWIW, the Dabo runtime for Windows will run nearly any wxPython 
program, including PythonCard. Feel free to use it as base for 
PythonCard distribution, if you like.

      ___/
     /
    __/
   /
  ____/
  Ed Leafe
  http://leafe.com/
  http://dabodev.com/

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Murray A. <m.a...@op...>]

Alex Tweedly wrote:
> bra...@om... wrote:
> 
> 
>>I'm still in favor of a separate data structure for tab order. It's 
>>important to be able to take some
>>focusable components out of the tab order, just as you can in 
>>FileMaker. This is normally done
>>with rarely used-fields which still need to be focusable by mouseClick.
> 
> I completely disagree. (Climbs on hobby-horse ......)
> 
> I think it's important to NEVER have focusable components that can't be 
> reached by TAB order. The idea of a field that needs to be reachable but 
> can be reached ONLY by mouse movement strikes me as being wrong.
> 
> In my own case, it's because I can type much better than I can use the 
> mouse; I like keeping my hands over the keyboard and just typing to get 
> what I want - but I'll admit that's personal preference.
> 
> But there are others who are disabled in various ways, for whom 
> requirements to use a mouse can be close to a show-stopper problem.  I 
> think it behooves us as developers to make our applications as 
> accessible to as wide range of people as possible - there should always 
> be an alternate, non-mouse mechanism, and it should be reasonably easy 
> if that is at all possible. (I accept that for some aspects of say a 
> drawing program there may be no alternative to a mouse other than 
> cursor-arrow-keys - but for reaching fields on an input form, that's not 
> necessary).
> 
> Try it some day - disconnect your mouse. You might be surprised by how 
> possible it is to do 95% of what you need, and how hard the other 5% 
> becomes. And how annoying it is that 4% out of those 5%  could have been 
> easy if someone had just thought about it a bit longer or more 
> sympathetically.
> 
> (Dismounts from hobby horse .....)

I don't think one has to climb on a hobby horse to suggest that
accessibility be a requirement for any project, nor do we need to
appeal to anyone's sense of fairness or ethics. If you're doing
business in the US or the EU, chances are you often have legal
requirements to provide accessible solutions. This applies to
whether you're doing business with government, industry, education,
etc., just as one finds requirements for entry ramps into both
public and private buildings.

Those who work with computers should always realize that they're
just one step away from needing accessibility features. Yes, it
can happen to YOU (if you're reading this, I mean YOU). It doesn't
even take some kind of accident. I know several people who simply
blew their hands out by too much typing or mousing, and are now
forced to use voice software in order to use a computer at all.
Yeah, it's a pain in the ass. They don't have any other option if
they want to use a computer. Any one of the people on this list
could be in this situation -- nobody is immune. [I also know a
fantastic acoustic bass player who retired this year after a long
battle with hand problems. In the end, it was just too painful
to continue. And he is a big guy, over six feet tall and strong
like an ox.]

As part of designing any software, Alex's suggestion is a very
good one: disconnect your mouse and see if you can still use
your software. If not, think about how those limited to keyboard
or voice will feel about your product. What if they happen to be
say, your client's purchasing agent, CTO or CEO?

It's good business practice to make one's software applications
accessible.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

        Ils ont l'orteil de Bouc, & d'un Chevreil l'oreille,
        La corne d'un Chamois, & la face vermeille
        Comme un rouge Croissant: & dancent toute nuict
        Dedans un carrefour, ou pres d'une eau qui bruict.

Re: [Pythoncard-users] Python distribution problems

[Steve C. <stn...@xm...>]

Alex Tweedly wrote:
> Schollnick, Benjamin wrote:
> 
> >
> >I am unclear on what you are suggesting they are basing their decisions
> >on?  (The quote does not include it)  Presumably on the fact that they
> >need to instead Python, WxPython, and PythonCard?  Windows programmers
> >are fully aware of dependencies...  .Net anyone?  
> >
> True - they are aware of them - but that doesn't mean they like them. I 
> think it would be pretty cool to have the *option* of a single download 
> and install to do Python, wxPython and Pythoncard in one easy operation. 
> I have no idea how easy it would be to create that - but I suspect it 
> would overcome some people's concerns about the complexity of getting 
> started with Pythoncard.

So, something similar to the Enthought Python distribution?

    http://www.enthought.com/downloads/downloads.htm

I'm not sure how much work was required to bundle all those into a single
distribution, or how often they update the entire package. 

As someone mentioned down-thread, tracking all the options and
dependencies and creating distributions will be a big job.


What about some sort of wizard interface that would step the user
through the process? Sort of like the cygwin setup script. e.g. a tool
written in PythonCard that'd allow the user to select versions of
python/wxPython, unicode flavors, etc. 

Rather than PythonCard distributing a huge bundle, the PythonCard
website would distribute a URLs to the 'good' installers, download the
binaries via urllib and launch the install process for
python/wxpython/pythoncard.

Still a big job, but it might be more managable than the alternative.


-Steve

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

Alex Tweedly wrote on 04/04/2005 03:42:32 PM:

> I think it's important to NEVER have focusable components that can't
> be reached by TAB order. The idea of a field that needs to be 
> reachable but can be reached ONLY by mouse movement strikes me as 
> being wrong. 

Well, I suppose that's a reasonable position, assuming your application is 
attempting to reach the widest possible audience. But what if your 
application is for a very small set of users, or even one end user, such 
as the owner of a small business?

My experience doing custom FileMaker solutions tells me that some 
customers want only specific fields in the tab order, so as to streamline 
data entry, and FileMaker does support omitting fields from the tab order. 
The most egregious example in my experience was a loan application form 
with dozens of obscure fields that were usually not used. The loan officer 
wanted the option of editing those other fields, but didn't want to have 
to tab through them constantly. I suppose I could have made him switch to 
a different layout, but he wouldn't have been happy with that.

Sometimes having a toolset enforce a user-interface convention/ideology 
makes sense, but I'm not sure it makes sense in the case of tab order. 

Re: [Pythoncard-users] clearing up tab order in resourceEditor

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

I'm still in favor of a separate data structure for tab order. It's 
important to be able to take some 
focusable components out of the tab order, just as you can in FileMaker. 
This is normally done 
with rarely used-fields which still need to be focusable by mouseClick.

Here's a proposal for handling tab sequence:

Every background rsrc gets a new property, which is a simple list of 
component widget names,
let's call it tabSeq. 

Rules for tabSeq:

        - If a widget isn't in tabSeq, it's not included in the tab order.
        - If a widget is deleted in Resource Editor, it must be deleted 
from tabSeq
        - If a widget is renamed in Resource Editor, it must be renamed in 
tabSeq
        - By default, at on_initialize, the focus would start at the first 
widgets in tabSeq
                (this would reduce need setFocus statements in 
on_initialize)
        - Tab order in final background UI is determined by tabSeq

The Resource Editor UI to handle this would be a modal dialog box listing 
focusable widgets
of the current background, with checkboxes alongside each item. Any widget 
with a 
checkbox is included in the tabSeq. Widgets could be reordered by using an
appropriate list reordering UI.

Yes, this is yet another dialog box for Resource Editor, but I don't think 
it would
need to be implemented in Resource Editor right away. I for one would be 
happy
to set the values of tabSeq from a script, but hope for a future time in 
which Resource 
Editor handles keeping the resource file in sync with tabSeq, and 
providing
a dialog UI for managing tabSeq.


 

Re: [Pythoncard-users] clearing up tab order in resourceEditor

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

[Pythoncard-users] protected names in self.components

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

On Apr 4, 2005, at 9:52 AM, Kevin Altis wrote:

>
> I don't know why this never came up before, but I bet there is a 
> problem if you want to have a component named parent, data, or order, 
> so I probably need to test that, then change them to have leading 
> underscores or something like that in the future, which also means 
> updating the resourceEditor and perhaps some other tools. I'm not sure 
> if I'll get to that this week before I leave for the UK or not.
>

I retract this last part. Given that there are a number of methods and 
attributes that should be "protected" it makes more sense to change the 
places where you can set the component name to present an error dialog 
that disallows the "protected" names for methods and internal 
attributes. I think that would just be the strings in the list returned 
by dir() since the component names are really in the internal item 
'data' and don't get exposed by dir.

 >>> dir(self.components)
['__cmp__', '__contains__', '__delitem__', '__doc__', '__getattr__', 
'__getitem__', '__init__', '__len__', '__module__', '__repr__', 
'__setattr__', '__setitem__', '_getAttributeNames', '_listeners', 
'addChangeEventListener', 'clear', 'copy', 'data', 'fireChanged', 
'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 
'itervalues', 'keys', 'order', 'parent', 'pop', 'popitem', 
'setdefault', 'update', 'values']

So the code to protect invalid names just has to do

if name in dir(self.components):
     # alert dialog, etc. here asking for a different name

Anyone see a problem with this? The __setitem__ method could also 
protect itself and throw an exception if we get a component name that 
would cause a problem.

BTW, these developer type issues will very soon start appearing only on 
the pythoncard-devel mailing list for those of you that want to be 
involved in this kind of stuff and want to sign-up.

http://lists.sourceforge.net/lists/listinfo/pythoncard-devel

I just submitted a request to gmane to add 
gmane.comp.python.pythoncard.devel as well.

ka

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Bernie H. <ber...@ut...>]

Also regarding the radio buttons -
(Mac, 10.3 python 2.3 (self-installed) pythoncard .81)

When I change the buttons from vertical to horizontal, and then reload the
resource file it loads them as vertical, and I have to manually click on
them to get them back to horizontal. Only happens for me when I specify the
size rather than (-1,-1). I realized the difference is in the ordering in
the resource file. When I manually change the resource file so that for each
radio component the alignment is above size, I don't get this behaviour.

(and yes, group select or some lasso function would be VERY much
appreciated). 

Take Care,
BERNiE

I received a message from Kevin Altis at approximately 4/4/05 12:01 PM.
Above is my reply.

> On Apr 1, 2005, at 7:24 AM, Bo Green wrote:
> 
>> Phil Edwards wrote:
>> 
>>> 2. there's a problem with radiogroup components not displaying
>>> properly
>>> in either the resource editor or the running application
>>> 
>>> 
>> 
>> Speaking of radio groups, any time I have a radio group present, the
>> resource editor behaviour for left-right arrow keys is to change the
>> default radio group value. It would be less noticable if it only
>> happened when the radio group is selected, but that's the behaviour
>> when any component is selected, effectively making the left-right
>> arrow keys useless in the resource editor whenever there's a radio
>> group present. I like to use the arrow keys to move components around
>> in small increments, so I find it fairly annoying.
>> 
> 
> Bo, which platform are you working on? I can look into this on Mac and
> Windows, but not Linux/GTK; if you're using Linux, specify whether it
> is a GTK1 or GTK2 build of wxPython. I suspect what is happening is
> that the problem platform has a compound control and the focus doesn't
> behave the way it should. I can probably add an explicit setFocus()
> call to go along with the display of the sizing handles and that will
> get rid of the problem, but I need to know if this is something Phil,
> Andy, or another GTK user will need to double-check after I check in
> the change.
> 
> ka
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

-- 

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Bo G. <bo...@sy...>]

Kevin Altis wrote:

> On Apr 1, 2005, at 7:24 AM, Bo Green wrote:
>
>> Phil Edwards wrote:
>>
>>> 2. there's a problem with radiogroup components not displaying properly
>>> in either the resource editor or the running application
>>>
>>>
>>
>> Speaking of radio groups, any time I have a radio group present, the 
>> resource editor behaviour for left-right arrow keys is to change the 
>> default radio group value. It would be less noticable if it only 
>> happened when the radio group is selected, but that's the behaviour 
>> when any component is selected, effectively making the left-right 
>> arrow keys useless in the resource editor whenever there's a radio 
>> group present. I like to use the arrow keys to move components around 
>> in small increments, so I find it fairly annoying.
>>
>
> Bo, which platform are you working on? I can look into this on Mac and 
> Windows, but not Linux/GTK; if you're using Linux, specify whether it 
> is a GTK1 or GTK2 build of wxPython. I suspect what is happening is 
> that the problem platform has a compound control and the focus doesn't 
> behave the way it should. I can probably add an explicit setFocus() 
> call to go along with the display of the sizing handles and that will 
> get rid of the problem, but I need to know if this is something Phil, 
> Andy, or another GTK user will need to double-check after I check in 
> the change.
>
> ka


This was observed while in Windows. I am sometimes using Mac as well, 
but not since I added the radio group.
Thanks.
Bo

RE: [Pythoncard-users] Python distribution problems

[Schollnick, B. <Ben...@xe...>]

> >I am unclear on what you are suggesting they are basing=20
> their decisions=20
> >on?  (The quote does not include it)  Presumably on the fact=20
> >need to instead Python, WxPython, and PythonCard?  Windows=20
> programmers=20
> >are fully aware of dependencies...  .Net anyone?

> True - they are aware of them - but that doesn't mean they=20
> like them. I=20
> think it would be pretty cool to have the *option* of a=20
> single download=20
> and install to do Python, wxPython and Pythoncard in one easy=20
> operation.=20
> I have no idea how easy it would be to create that - but I suspect it=20
> would overcome some people's concerns about the complexity of getting=20
> started with Pythoncard.

The option might be nice....  But is it a reasonable option?

That's at least 6+ different archives.... (Windows, *Nix, MacIntosh) ...
That Kevin would have to maintain.  I don't even know if Kevin has all
of those systems....

Plus just python alone (without Source code) is 10 MB.  And that's a
dedicated installer (.MSI)....  It will be larger in this combined
installer....  WxPython is another 6 MB, and PythonCard is another 2...

SubTotal roughly 20Mb.

That is not including Python Source code, nor Win32 Extensions...
And is consists of 3 different installers....

1) This will be at least a 20 Mb download....
2) Who is liable for this?  If a problem occurs with <fill in the blank>
	is Kevin going to be forced to Fix it?  (WxPython Developer:
It's=20
	not a bug in our code, your installer goofed...)
3) How is all of this going to be packaged?  We have a .MSI installer,
	two .EXE installers...  Prepackage/ZIP everything up?  What if
	the person installing wants a non-standard path or library?

It maybe a good idea, but I think it is safer and smarter to use=20
approved installers directly from the authors...

A better suggestion, IMHO, is to suggest to Kevin to have a quick link
at the top pointing to each installer... =20

ie.
-----------------------------------------------------------------
PythonCard is currently at Version v0.81. =20

Pythoncard requires the following software:

	* Python v2.3.x or later
	  Tested with Version v2.3.888 (download Installer) on xx/xx/xx

	* WxPython v2.x.x or later (Unicode and Non-Unicode versions)
	  Tested with Version v2.3.888 (download Installer) on xx/xx/xx

-------------------------------------------------------------------

Each development environment is going to be different, some people will
want WxPython with Unicode support, some without...  Some will need
WxPython vxx.yy.zz and some want to be using the CVS nightly builds...

There is no sensible way to allow of that to be bundled without a huge
amount of effort.

		- Benjamin

Re: [Pythoncard-users] Python distribution problems

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

On Apr 4, 2005, at 10:03 AM, Alex Tweedly wrote:

> Schollnick, Benjamin wrote:
>
>>
>> I am unclear on what you are suggesting they are basing their 
>> decisions
>> on?  (The quote does not include it)  Presumably on the fact that they
>> need to instead Python, WxPython, and PythonCard?  Windows programmers
>> are fully aware of dependencies...  .Net anyone?
> True - they are aware of them - but that doesn't mean they like them. 
> I think it would be pretty cool to have the *option* of a single 
> download and install to do Python, wxPython and Pythoncard in one easy 
> operation. I have no idea how easy it would be to create that - but I 
> suspect it would overcome some people's concerns about the complexity 
> of getting started with Pythoncard.
>

First of all, I just want to make sure everyone actually found the 
install instructions at:

http://pythoncard.sourceforge.net/installation.html

Those are step by step and are supposed to be bullet proof. If there is 
a problem with them, like needing more images, more explanation at a 
particular step, please provide specifics on the needed changes.

Secondly, once we have a viable 1.x release, I would like to have a 
single installer option for Python, wxPython, and PythonCard on the 
Windows platform; Robin Dunn and I talked about doing this almost four 
years ago, but it doesn't make any sense until the parts of the big 
package are at a stable point like the combo of Python 2.3.5, wxPython 
2.6, PythonCard 1.0, etc. On the Mac, it will just be wxPython and 
PythonCard, since Macs already include Python. Given the various 
versions and combinations of Python and wxPython, the single installer 
will only support one combination. If possible, we'll do the same for 
Linux.

The installer scripts for py2exe (Windows) and py2app (Mac) are almost 
identical, in fact, Bob Ippolito sent me a script variation to deal 
with both in a single script. So, once the new standaloneBuilder tool 
is updated to support py2exe and py2app creating PythonCard standalones 
should be relatively painless. At Pycon, Bob fixed an earlier problem 
with how py2app renames the startup module, so people that have had 
problems with py2app should find that the latest version in cvs works 
correctly now with PythonCard; I don't know if/when he will have a new 
release of that outside of cvs.

ka

Re: [Pythoncard-users] Tabv order in dyamic components [Was: Pythoncard-users digest, Vol 1 #938 - 5 msgs]

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

Phil Edwards wrote:

> AFAIK, Alex, it's just down to the order they appear in self.components.

Thanks Phil. Some things are just so obvious that even when you're 
looking right at them, it doesn't click.
Thanks again.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] Python distribution problems

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

Schollnick, Benjamin wrote:

>
>I am unclear on what you are suggesting they are basing their decisions
>on?  (The quote does not include it)  Presumably on the fact that they
>need to instead Python, WxPython, and PythonCard?  Windows programmers
>are fully aware of dependencies...  .Net anyone?  
>
True - they are aware of them - but that doesn't mean they like them. I 
think it would be pretty cool to have the *option* of a single download 
and install to do Python, wxPython and Pythoncard in one easy operation. 
I have no idea how easy it would be to create that - but I suspect it 
would overcome some people's concerns about the complexity of getting 
started with Pythoncard.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

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

On Apr 1, 2005, at 7:24 AM, Bo Green wrote:

> Phil Edwards wrote:
>
>> 2. there's a problem with radiogroup components not displaying 
>> properly
>> in either the resource editor or the running application
>>
>>
>
> Speaking of radio groups, any time I have a radio group present, the 
> resource editor behaviour for left-right arrow keys is to change the 
> default radio group value. It would be less noticable if it only 
> happened when the radio group is selected, but that's the behaviour 
> when any component is selected, effectively making the left-right 
> arrow keys useless in the resource editor whenever there's a radio 
> group present. I like to use the arrow keys to move components around 
> in small increments, so I find it fairly annoying.
>

Bo, which platform are you working on? I can look into this on Mac and 
Windows, but not Linux/GTK; if you're using Linux, specify whether it 
is a GTK1 or GTK2 build of wxPython. I suspect what is happening is 
that the problem platform has a compound control and the focus doesn't 
behave the way it should. I can probably add an explicit setFocus() 
call to go along with the display of the sizing handles and that will 
get rid of the problem, but I need to know if this is something Phil, 
Andy, or another GTK user will need to double-check after I check in 
the change.

ka