pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Debug windows are children of the app window

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

All of the Debug windows are now children of the main application window.
  Message Watcher, Namespace Viewer, Property Editor, Shell

I had originally intended to bind the activate events so that all of the
Debug windows would "come forward" when the application was activated, but I
never did figure out the sequence of events to make this work right. The
Message Watcher has always been a child of the main app window due to a bug
in how its events were processed.

Anyway, the good news is that now when you click on any of the windows, all
of them will be brought forward, so you won't have a hard time finding the
Shell window, for example. The bad news is that the Debug windows always
stay in front of the main application window. If you have a small display
you'll need to hide or move the other windows if they are obscuring the main
app. This is most likely to happen with a sample that has a large window
like the turtle.

Once wxPython 2.3.2 is out we can add accelerator keys to hide/show the
various Debug windows which should make it easier to manage multiple windows
on the screen at once.

ka

[Pythoncard-users] Message Watcher now uses sizers

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

Thanks to Robin, the Message Watcher window now uses sizers instead of a
fixed layout. If you have access to cvs, please let me know if you see any
problems; it seems to be fine on Windows, but I can't test on Linux...

ka

Re: [Pythoncard-users] PythonCard and Distutils

[Andy T. <an...@cr...>]

Andy Todd wrote:
> Roman Suzi wrote:
> 
>> On Sun, 9 Sep 2001, Kevin Altis wrote:
>>
>>
>>>> - Run the standard distutils install command ("python setup.py 
>>>> install")
>>>>
>>> This is one of my pet peeves about distutils. The default is always
>>> "setup.py install" but if you only have one Python installation (on 
>>> Windows
>>> at least) you should just be able to run "setup.py" from the Explorer
>>> without specifying the "install" command-line option. Perhaps we should
>>> provide a setup_install.bat file for Windows? Would it be okay to 
>>> actually
>>> modify "setup.py" so that if the user didn't specify a command-line 
>>> option
>>> it would default to "install" ?
>>>
>>
>> I wished Distutils to have some window popup with options for those
>> people who do not hesitate to run things before looking what they are.
>>
>> Just after second line of setup.py:
>> -----------------------------------------
>> WIN_DEFAULT_COMMAND = "install"
>> import sys
>> if len(sys.argv) == 1 and sys.platform.startswith("win"):
>>   sys.argv.append(WIN_DEFAULT_COMMAND)
>> -----------------------------------------
>>
> 

I've updated the setup.py to keep the sample applications with the 
framework code rather than in their own seperate directory.

I've also been playing around with binary distributions, and have 
managed to create a self extracting .exe for windows. Unfortunately this 
only contains the top level of files, so if anyone would like to point 
out how I get the whole directory structure included I'd appreciate it.

I've updated the files in http://pythoncard.sourceforge.net/dist and 
would appreciate as much testing and feedback as possible.

Thanks in advance,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

[Pythoncard-users] pycrustrc.py files

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

PythonCard has pycrustrc.py file support, so that the shell is automatically
loaded with some useful variables.

The main pycrustrc.py file in the PythonCardPrototype directory:

shell.autoCompleteIncludeMagic = 1
shell.autoCompleteIncludeSingle = 0
shell.autoCompleteIncludeDouble = 0
bg = pcapp.getCurrentBackground()
comp = bg.components


Here is the pycrustrc.py file for the turtle sample:

from wxTurtle import *
dc = TurtleDC(pcapp.getCurrentBackground().panel)
t = Pen(dc)


You can put any valid Python code in there and it will be executed when the
app starts up. The main package pycrustrc.py file is run at startup followed
by the one in the app directory. Among other things it means you can put
repetitive test commands in the pycrustrc.py file and as you change your
source and rerun the app it will automatically load the commands and run
your tests.

Patrick might have something to add to this description. It is a very useful
feature we've had almost since we started using PyCrust.

ka

Re: [Pythoncard-users] anyone still using wxPython 2.3.0?

[charlie d. <cd...@si...>]

The newest boa-constructor (0.0.13) requires 2.3.0 (and *not* 2.3.1),
but i don't know how many people other than myself this would affect. 
I'm not that important, as I'm not a pythoncard developer (yet :-]  i
only found this list earlier today).

	~c

Kevin Altis wrote:
> 
> I would like to use the wxTE_RICH rich text style for the TextField class.
> The change to TextField will give PasswordField and TextArea styled text as
> well.
> 
> By allowing the use of the wxTE_RICH attribute we can have an optional
> attribute in the .rsrc.py file to turn on styled text for any given text
> field. I talked briefly with Neil about using the wxSTC control, but I think
> wxSTC is far more complicated for general use and should be a separate
> wrapped control.
> 
> If there isn't any objection to requiring wxPython 2.3.1, I'll go ahead and
> make the change. Originally, I planned on waiting until 2.3.2 was out, but
> it is unclear when 2.3.2 will be released right now; note, that 2.3.2 also
> fixes the long-standing bug with the accelerator keys in menus.
> 
> ka
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] anyone still using wxPython 2.3.0?

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

I would like to use the wxTE_RICH rich text style for the TextField class.
The change to TextField will give PasswordField and TextArea styled text as
well.

By allowing the use of the wxTE_RICH attribute we can have an optional
attribute in the .rsrc.py file to turn on styled text for any given text
field. I talked briefly with Neil about using the wxSTC control, but I think
wxSTC is far more complicated for general use and should be a separate
wrapped control.

If there isn't any objection to requiring wxPython 2.3.1, I'll go ahead and
make the change. Originally, I planned on waiting until 2.3.2 was out, but
it is unclear when 2.3.2 will be released right now; note, that 2.3.2 also
fixes the long-standing bug with the accelerator keys in menus.

ka

RE: [Pythoncard-users] PythonCard and Distutils

[Patrick K. O'B. <po...@or...>]

That would be wonderful. Thanks, Andy.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Andy Todd
Sent: Sunday, September 09, 2001 5:45 PM
To: pyt...@li...
Subject: Re: [Pythoncard-users] PythonCard and Distutils

Patrick,

Patrick K. O'Brien wrote:
> This definitely needs to be done. I will do it myself if nobody wants to
> volunteer. If someone does volunteer, I'd like to learn how it all works.

I'll give this a bash if you like, now that I'm a seasoned packager ;-)
Shouldn't be too much trouble, I'll keep you informed on progress.

Re: [Pythoncard-users] PythonCard and Distutils

[Andy T. <an...@cr...>]

Roman Suzi wrote:
> On Sun, 9 Sep 2001, Kevin Altis wrote:
> 
> 
>>>- Run the standard distutils install command ("python setup.py install")
>>>
>>This is one of my pet peeves about distutils. The default is always
>>"setup.py install" but if you only have one Python installation (on Windows
>>at least) you should just be able to run "setup.py" from the Explorer
>>without specifying the "install" command-line option. Perhaps we should
>>provide a setup_install.bat file for Windows? Would it be okay to actually
>>modify "setup.py" so that if the user didn't specify a command-line option
>>it would default to "install" ?
>>
> 
> I wished Distutils to have some window popup with options for those
> people who do not hesitate to run things before looking what they are.
> 
> Just after second line of setup.py:
> -----------------------------------------
> WIN_DEFAULT_COMMAND = "install"
> import sys
> if len(sys.argv) == 1 and sys.platform.startswith("win"):
>   sys.argv.append(WIN_DEFAULT_COMMAND)
> -----------------------------------------
> 

I'll apply this patch to setup.py and test it with the next release of 
the prototype, thanks.

> 
>>We'll need an installation for PyCrust as well. Patrick, is this something
>>you want to tackle for the 0.6 PyCrust release?
>>
> 
> Sincerely yours, Roman Suzi
> 

Regards,
Andy

-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

Re: [Pythoncard-users] PythonCard and Distutils

[Andy T. <an...@cr...>]

Roman Suzi wrote:
> On Sun, 9 Sep 2001, Andy Todd wrote:
> 
> 
>>Roman Suzi wrote:
>>
>>>Hi!
>>>
>>>I've made setup.py and MANIFEST.in for the PythonCardPrototype.
>>>(For now Kevin posted them as attachments)
>>>
>>And I've made some minor cosmetic changes and posted them into cvs.
>>I've also had to include a README.txt in the root directory (distutils
>>requires one apparently), but I just copied the one from the docs directory.
>>
> 
> Well. I've just got tar.gz with soource distribution.
> 
> I noticed that MANIFEST file should not be there! Only MANIFEST.in
> It is created as a result of setup.py. The presence of MANIFEST could
> have some side effects on people who forgot to delete it
> when switching to version.
> 

I just checked the tar.gz and zip versions from 
http://pythoncard.sourceforge.net/dist and they only include the 
MANIFEST.in file. I'm not even sure we need this in a source 
distribution anyway as it is only used when creating the archive and is 
ignored when you unpack it and run 'python setup.py install'. But I'd be 
glad to hear your thoughts on the matter ...

> So, the general advice is to run
> 
> setup.py sdist

Actually, I'm running 'python setup.py sdist --formats=gztar,zip' to get 
both source distributions. We don't want to exclude anyone here ;-)

> 
> to get source distribution right. Distutils strip all CVS's and things
> like that automatically, so it is OK to run them in the chkedout
> directory.

Which is what I have done.

> 
> 
>>>Now (if Python 2.x is properly installed) it is possible to
>>>make source and binary distros this way (in the root directory
>>>of the source distro):
>>>
> 
> Sincerely yours, Roman Suzi
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

Re: [Pythoncard-users] PythonCard and Distutils

[Andy T. <an...@cr...>]

Patrick,

Patrick K. O'Brien wrote:
> This definitely needs to be done. I will do it myself if nobody wants to
> volunteer. If someone does volunteer, I'd like to learn how it all works.

I'll give this a bash if you like, now that I'm a seasoned packager ;-)
Shouldn't be too much trouble, I'll keep you informed on progress.

> And what about a real installer, such as Inno Setup, in addition to
> distutils? I think these are what Neil and Robin use:
> 
> http://www.jrsoftware.org/isinfo.htm
> 
> http://www.bhenden.org/istool/
> 

Good idea, but maybe when both projects are out of the prototype stage? 
Not that I would want anyone to not try them out though ...

> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Sunday, September 09, 2001 1:03 PM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] PythonCard and Distutils
> 
> <snip>
> 
> We'll need an installation for PyCrust as well. Patrick, is this something
> you want to tackle for the 0.6 PyCrust release?
> 
> ka
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

RE: [Pythoncard-users] PythonCard and Distutils

[Patrick K. O'B. <po...@or...>]

This definitely needs to be done. I will do it myself if nobody wants to
volunteer. If someone does volunteer, I'd like to learn how it all works.
And what about a real installer, such as Inno Setup, in addition to
distutils? I think these are what Neil and Robin use:

http://www.jrsoftware.org/isinfo.htm

http://www.bhenden.org/istool/

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Kevin
Altis
Sent: Sunday, September 09, 2001 1:03 PM
To: pyt...@li...
Subject: RE: [Pythoncard-users] PythonCard and Distutils

<snip>

We'll need an installation for PyCrust as well. Patrick, is this something
you want to tackle for the 0.6 PyCrust release?

ka

RE: [Pythoncard-users] PythonCard and Distutils

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

Okay, you got me. I'll shut up now.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Roman
> Suzi
> Sent: Sunday, September 09, 2001 11:30 AM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] PythonCard and Distutils
> 
> 
> On Sun, 9 Sep 2001, Kevin Altis wrote:
> 
> >> - Run the standard distutils install command ("python setup.py 
> install")
> >
> >This is one of my pet peeves about distutils. The default is always
> >"setup.py install" but if you only have one Python installation 
> (on Windows
> >at least) you should just be able to run "setup.py" from the Explorer
> >without specifying the "install" command-line option. Perhaps we should
> >provide a setup_install.bat file for Windows? Would it be okay 
> to actually
> >modify "setup.py" so that if the user didn't specify a 
> command-line option
> >it would default to "install" ?
> 
> I wished Distutils to have some window popup with options for those
> people who do not hesitate to run things before looking what they are.
> 
> Just after second line of setup.py:
> -----------------------------------------
> WIN_DEFAULT_COMMAND = "install"
> import sys
> if len(sys.argv) == 1 and sys.platform.startswith("win"):
>   sys.argv.append(WIN_DEFAULT_COMMAND)
> -----------------------------------------
> 
> >We'll need an installation for PyCrust as well. Patrick, is this 
> something
> >you want to tackle for the 0.6 PyCrust release?
> 
> Sincerely yours, Roman Suzi
> -- 
> _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
> _/ Sunday, September 09, 2001 _/ Powered by Linux RedHat 6.2 _/
> _/ "Another case of Cherry Coke down the programming hatch!" _/
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 

RE: [Pythoncard-users] PythonCard and Distutils

[Roman S. <rn...@on...>]

On Sun, 9 Sep 2001, Kevin Altis wrote:

>> - Run the standard distutils install command ("python setup.py install")
>
>This is one of my pet peeves about distutils. The default is always
>"setup.py install" but if you only have one Python installation (on Windows
>at least) you should just be able to run "setup.py" from the Explorer
>without specifying the "install" command-line option. Perhaps we should
>provide a setup_install.bat file for Windows? Would it be okay to actually
>modify "setup.py" so that if the user didn't specify a command-line option
>it would default to "install" ?

I wished Distutils to have some window popup with options for those
people who do not hesitate to run things before looking what they are.

Just after second line of setup.py:
-----------------------------------------
WIN_DEFAULT_COMMAND = "install"
import sys
if len(sys.argv) == 1 and sys.platform.startswith("win"):
  sys.argv.append(WIN_DEFAULT_COMMAND)
-----------------------------------------

>We'll need an installation for PyCrust as well. Patrick, is this something
>you want to tackle for the 0.6 PyCrust release?

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Sunday, September 09, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Another case of Cherry Coke down the programming hatch!" _/

[Pythoncard-users] FW: are all your layouts fixed?

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

name and address withheld on this one...

ka
---
> I use the Microsoft standard widgets, which have some measure of
> flexibility, but not for re-sizing dialogs, fonts etc. A user can easily
> create super-ugly schemes. I do not provide for any re-sizing of any
> dialogs, alert boxes, property sheets, etc. And I assume "normal" type
> sizes. I have never ever had any complaint about the inflexibility of my
> UI designs, and I have a reputation for elegant and usable UIs.
>
> If stretch-O-matic displays are required for the current genre of
> xxnix/xxnux UI designs, you have my deepest sympathies. I just can't
> stand the thought of burning development cycles on stretch-O-matic UIs.
> Sorry if that seems harsh or heartless, but in the real world, with
> "ordinary people" as users, stretch-O-matic is superfluous. No one
> cares.

I want to support some form of sizers in PythonCard, I just don't know what
that will be yet, basically I'm relying on the GUI toolkit underneath
PythonCard to do the hard work, my issue is mostly in presenting a better
config to setting up the required calls and then let the user beware.

My backup plan since we're using resources is to just let people define one
or more layouts and then have the appropriate layout selected automatically
when the app starts up based on platform (win32, mac, linux, etc.). This can
also deal with language and we can even support the notion of a user
preferred layout style, so their preferred layout gets precedence. The
interesting part is that if the alternative resource say for Unix said use
sizers instead of fixed layout, then that would happen automatically as
well. This is pretty easy to do because we aren't sticking layout in the
source code. I'm so glad I learned my lesson from the Mac about separating
layout and code.

ka

RE: [Pythoncard-users] PythonCard and Distutils

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

> - Run the standard distutils install command ("python setup.py install")

This is one of my pet peeves about distutils. The default is always
"setup.py install" but if you only have one Python installation (on Windows
at least) you should just be able to run "setup.py" from the Explorer
without specifying the "install" command-line option. Perhaps we should
provide a setup_install.bat file for Windows? Would it be okay to actually
modify "setup.py" so that if the user didn't specify a command-line option
it would default to "install" ?

We'll need an installation for PyCrust as well. Patrick, is this something
you want to tackle for the 0.6 PyCrust release?

ka

[Pythoncard-users] FW: reply to Michael Swaine

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

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Saturday, September 08, 2001 9:12 AM
To: Michael Swaine
Subject: RE: PythonCard


Danger Will Robinson, long message ahead...

The PythonCard project is roughly two and half months old. The beginning is
described at:
http://www.onlamp.com/pub/a/python/2001/08/16/pythonnews.html
After we had the mailing list up I found that there was already a PythonCard
project on SourceForge and so I contacted the project owner. After sending
the email my synapses finally fired and I realized the owner, Dan Winkler,
was the same person as Bill Atkinson hired for the original HyperCard. His
PythonCard example in cvs (now the textIndexer sample) does text hinting for
searches like HyperCard used to use. Anyway, Dan gave us his project space
and I keep bugging him, so hopefully pretty soon he'll start working on
PythonCard again; right now he is playing with Lisp instead of Python.
Rowland Smith and I wrote the original framework which we've been modifying
for the last two months.

We're at the prototype stage right now. I wanted to make it clear that it is
a prototype, so that everyone would understand why the API changes, features
are missing, etc. We are using wxPython as our GUI layer, though it might be
possible to generalize the GUI toolkit used via anygui (another Python
project later. We should be done with the prototype in a few months or less.
Then the API will be pretty stable and we'll rewrite the framework itself to
be more efficient.

The samples that can be written today are rough-equivelants of single
backround, single card stacks where the user code manages data storage. The
addresses sample is a port of the Addresses stack from HyperCard and
includes the HyperTalk export script and documents the conversion process.
The current focus for the PythonCard project is on GUI widgets, menus,
windows, events, fonts, sizers, etc. Pretty soon we'll be getting into
transparent data storage; two of the samples are already using mySQL and
ZODB. We're also getting closer to some of the environment pieces. The
resourceEditor is the beginning of a GUI for laying out widgets. Layout
descriptions are stored in a separate resource (.rsrc.py) file which is
actually a Python dictionary, once it is no longer necessary to hand edit
the resources it will probably be stored in XML format.

The simplest way to see more of PythonCard without reading the message list
archives is to install it and run the samples.py launcher; install and a
quick look should take less than half an hour. samples.py has brief
descriptions of all the samples, displays the source code and resource files
for each sample, and let's you turn on any of the run-time tools: Logging,
Message Watcher, Namespace Viewer, Property Editor, and Shell (full Python
interpreter available at runtime). The shell also serves the same function
as the Message Box in HyperCard, so there is a Debug menu item to "Redirect
stdout to Shell".

PythonCard will probably always be an application framework as well as an
environment, so that people that don't want to use the environment will be
able to code directly in Emacs or another editor. My desire is to keep
PythonCard simple, yet capable, so that simple projects can be coded in an
afternoon without much planning. Pythoncard should provide the application
framework to match Python in elegance and power.

ka

[Pythoncard-users] FW: reply to Jon Udell

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

I often exchange email with people outside the list regarding PythonCard.
I've found lately that I often end up explaining my viewpoints about what
PythonCard could or should be and how to use it effectively. Sometimes this
duplicates a discussion that we already had on the list, but usually not.
Anyway, I'm going to start forwarding these emails either verbatim or with
minor edits. The first one is below.

Feel free to launch a discussion on any point that you disagree with or want
more explanation about.

ka

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Sunday, September 09, 2001 9:48 AM
To: Jon Udell
Subject: RE: did you ever get a chance to look at PythonCard?


> > Hi Jon,
> > I never got a reply from you re: PythonCard, so I wasn't sure
> if you ever
> > got a chance to look at the latest version or not.
>
> Yes, I tried it a few days ago. I never really thought of HyperCard as
> an app framework, distinct from its interactive GUI-builder. That's what
> this is, currently, right? Interesting.

Building the app framework is the first step. If it isn't possible to build
simple apps using just an editor then things won't be much better in the
environment. The syntax and API and event model have to be easier to grasp
than say tkinter and wxPython. Even when we start providing a full
environment I want to support editing in Emacs or another text editor to
make the Unix folks happy, if nothing else. We'll probably be doing runtime
editing experiments in the next month.

> Does it make sense to imagine formally decoupling the GUI builder from
> the framework, I wonder? So that other GUI-builder projects targeting
> wxPython (or indeed other Python or non-Python open-source GUI kits)
> could work with PythonCard (and other frameworks)?

We're sitting on wxPython right now, but based on the work of the anygui
project http://anygui.sourceforge.net/ it might be possible to work on a
variety of GUI toolkits in the future. We probably won't know until they get
to at least release 0.3.

The main reason in my mind to force the use of the environment is that right
now it is too easy for the scripts and resource description names (ids) to
get out of sync (on_btn1_mouseClick handler goes with component 'btn1').
Once we are doing transparent data storage saves that problem will escalate.
That means anyone working say from Emacs will have to be responsible for
keeping their names in sync, but I think we'll provide some tools for
helping with this problem.

As you can see, we have a lot to do before PythonCard is directly comparable
to HyperCard and it is likely we'll continue to provide pieces of the puzzle
as samples or runtime elements like the Message Watcher, Property Editor,
and Shell before we get to the complete environment stage.

Since there is no compile, link cycle, you can open up the resourceEditor
sample to edit your layout description and keep your Python script open in
IDLE, PythonWin, Notepad, etc., make changes, save and then run your app
with a changed layout and/or script without closing the resourceEditor or
script editor. This is a little closer to SuperCard than HyperCard, but it
is pretty effective.

Does that make sense?

ka

Re: [Pythoncard-users] PythonCard and Distutils

[Roman S. <rn...@on...>]

On Sun, 9 Sep 2001, Andy Todd wrote:

>Roman Suzi wrote:
> > Hi!
> >
> > I've made setup.py and MANIFEST.in for the PythonCardPrototype.
> > (For now Kevin posted them as attachments)
>
>And I've made some minor cosmetic changes and posted them into cvs.
>I've also had to include a README.txt in the root directory (distutils
>requires one apparently), but I just copied the one from the docs directory.

Well. I've just got tar.gz with soource distribution.

I noticed that MANIFEST file should not be there! Only MANIFEST.in
It is created as a result of setup.py. The presence of MANIFEST could
have some side effects on people who forgot to delete it
when switching to version.

So, the general advice is to run

setup.py sdist

to get source distribution right. Distutils strip all CVS's and things
like that automatically, so it is OK to run them in the chkedout
directory.

> > Now (if Python 2.x is properly installed) it is possible to
> > make source and binary distros this way (in the root directory
> > of the source distro):

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Sunday, September 09, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Another case of Cherry Coke down the programming hatch!" _/

Re: [Pythoncard-users] PythonCard and Distutils

[Andy T. <an...@cr...>]

Roman Suzi wrote:
 > Hi!
 >
 > I've made setup.py and MANIFEST.in for the PythonCardPrototype.
 > (For now Kevin posted them as attachments)

And I've made some minor cosmetic changes and posted them into cvs.
I've also had to include a README.txt in the root directory (distutils
requires one apparently), but I just copied the one from the docs directory.

 >
 > Now (if Python 2.x is properly installed) it is possible to
 > make source and binary distros this way (in the root directory
 > of the source distro):
 >
 > python setup.py sdist
 > python setup.py bdist_rpm
 > python setup.py bdist_wininst
 > python setup.py bdist --format=zip

We don't need to bdist (yet) as we have no binary (i.e. needing some
sort of compilation step) components in PythonCard. I have created two
source distributions, one for Windows and one for *nix.

Before making them the 'official' releases for the project I've posted
them on the web site for  initial testing by the subscribers to this
list. You can get the source distributions at
http://pythoncard.sourceforge.net/dist/

To install from one of these distributions;

- Copy the appropriate file to your machine
- Unpack it to a temporary directory (using WinZip on Windows or "tar
-xzf PythonCardPrototype-0.4.4.5.tar.gz" on *nix)
- This will create a directory called "PythonCardPrototype-0.4.4.5", cd
to that directory, then;
- Run the standard distutils install command ("python setup.py install")
- The framework code will then be installed as a module in your Python
set up (in the directory $PYTHON_HOME/PythonCardPrototype)
- The sample applications will be installed in a PythonCard directory in 
the share directory under your Python Home.
- Finally, you can remove the working directory you created by unpacking 
the distribution above.

 >
 >
 > Right now, Distutil support is not full: setup.cfg with meta-information
 > fields specific to different binary distribution methods is missing.
 >

As I said, we don't need this yet so we have a complete set up. If we
ever get to the stage of performing some come of compile step at least
Roman has an idea of what we need to do.

I will post the steps to created these distributions tomorrow, for those 
who want to act as release managers when we cut a new version. In the 
meantime, if these distributions are OK perhaps someone could post them 
to the file release system on SourceForge.

 >
 >
 > Sincerely yours, Roman A.Suzi
 >

As ever, any and all feedback is welcome.

Regards,
Andy
-- 
-----------------------------------------------------------------------
  From the desk of Andrew J Todd esq.
"Shave my poodle!"

[Pythoncard-users] Announce: release 0.4.4.5

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

Another release I'm only announcing to the list. As usual, the file is at:
https://sourceforge.net/project/showfiles.php?group_id=19015


changes since 0.4.4.1

Release 0.4.4.5 2001-09-08
posted Help Wanted on SourceForge
  http://sourceforge.net/people/?group_id=19015
posted Python Conference request for papers/tutorials
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/767719
added addMethod to Scriptable class for dynamically adding
  handlers at runtime, see:
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/770015
added 'openBackground' message to replace using __init__
changed background handlers to on_mouseClick form
modified SourceForgeTracker so that double-clicking on a topic
  launches the web page for that topic in a browser
Neil added Pyker.hta and PykerLaunch.hta
  see the following URL for more info
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766307
Andy added a TODO.txt to document short-term plans for PythonCard
  development
Property Editor and resourceEditor sample were changed to use
  default size (-1, -1) values
added enable and check menu items to menu.py
  see the url below and thread replies
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766371
started some documentation for the Button class
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/764832
added display of .rsrc.py files in samples.py
Patrick added dot notation support to the Font class
Jeff and Neil provided some Unix screenshots
  These show we need to get sizers working to deal with variable
    size widgets and fonts on different platforms
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763602
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763659
res.py eval() changed to support using Windows-style line endings
  under Unix
added "Redirect stdout to Shell" option to Debug menu


And yes, my version numbers are a bit arbitrary. I just wanted to get this
out so I can go back to concentrating on fonts and sizers. If someone
finishes off the remaining distutils issues, then I hope to do a release
with a binary win32 installer, RPMs, etc. this coming week.

ka

[Pythoncard-users] Help Wanted

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

I've put together some basic "job openings" on the PythonCard project.

http://sourceforge.net/people/?group_id=19015

I'll probably add some more openings and revise the descriptions later, but
take a look and let me know if you are interested in any of the items, have
suggestions on revising the existing postings, suggestions for new jobs,
etc. The more people we have working in parallel on different aspects of the
project, the sooner we'll go from prototype to a finished API and a stable
production release.

I'm trying to put on my manager cap and delegate as much as possible, so
people that like having ownership and responsibility for a task or
sub-project will be the most helpful.

Thanks,

ka
---
Kevin Altis
al...@se...

RE: [Pythoncard-users] fwd: The Pros and Cons of XML

[Patrick K. O'B. <po...@or...>]

You've got a link the HTML version of the paper, but I'd like a link to the
XML version, preferably DocBook. Thanks. <g,d&r>

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Kevin
Altis
Sent: Friday, September 07, 2001 1:41 PM
To: pythoncard-Users
Subject: [Pythoncard-users] fwd: The Pros and Cons of XML

At some point we are going to support XML, at least for import/export and
possibly the resource format. It will certainly be used for any XML-RPC or
SOAP connectivity, which is probably how PythonCard apps are going to talk
to the rest of the world in a standard way. Even XML gurus will probably
benefit from reading through the paper below.

Anyway, this is one of the better pro/con papers I've seen on XML,
especially considering that the company behind the paper are "XML Industry
Analysts". If you have other links that are relatively well-balanced on the
pluses and minuses of XML, feel free to post them as a reply to this
message.

The Pros and Cons of XML by ZapThink Research
http://www.zapthink.com/reports/proscons.html

HTML version
http://www.zapthink.com/reports/proscons-view.html

ka


_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] fwd: The Pros and Cons of XML

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

At some point we are going to support XML, at least for import/export and
possibly the resource format. It will certainly be used for any XML-RPC or
SOAP connectivity, which is probably how PythonCard apps are going to talk
to the rest of the world in a standard way. Even XML gurus will probably
benefit from reading through the paper below.

Anyway, this is one of the better pro/con papers I've seen on XML,
especially considering that the company behind the paper are "XML Industry
Analysts". If you have other links that are relatively well-balanced on the
pluses and minuses of XML, feel free to post them as a reply to this
message.

The Pros and Cons of XML by ZapThink Research
http://www.zapthink.com/reports/proscons.html

HTML version
http://www.zapthink.com/reports/proscons-view.html

ka

[Pythoncard-users] addMethod, dynamic method binding

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

I made an addition to the Scriptable class in model.py so that we can add
methods during runtime. It uses 'instanceMethod' from the 'new' module. The
following interaction in the shell shows how this can be used. Startup
minimal.py with the shell and type the following lines to add a button with
a mouseClick handler. [As always, this change is currently in cvs, but will
be part of the next release.]

>>> def on_btn1_mouseClick(self, button, event):
... 	self.components.field1.text = button.name
...
>>> comp['btn1'] = {'type':'Button', 'name':'btn1', 'position':(0, 30),
'label':'btn1 hello'}
>>> bg.addMethod(on_btn1_mouseClick)

This simplifies creating PythonCard UIs on the fly. The more important
reason for making this addition is to bring us closer to runtime editing of
scripts.

ka

Re: [Pythoncard-users] cvs will be unstable until further notice

[Roman S. <rn...@on...>]

On Thu, 6 Sep 2001, Kevin Altis wrote:

>Rowland and I are deep into some new event bindings and I'll probably check
>these files into cvs so that we don't get out of sync. I'm also
>experimenting with a number of other changes that impact numerous files in
>the framework. If you want a stable version of PythonCardPrototype, do not
>checkout from cvs until further notice. Please don't check in any files in
>the main directory either.

Maybe, you could tag last stable release so people will be able to
get it?


>I'll post another message when cvs stabilizes.
>
>ka
>
>
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Friday, September 07, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Dreams are free, but you get soaked on the connect time." _/