pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] cvs stable again, openBackground, shell redirect

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

I haven't done extensive testing, but cvs seems to be okay for the more
adventurous people on the list. You will need the latest PyCrust from cvs as
well.

The change earlier today added some infrastructure to support background
events. In particular, 'openBackground' which happens after all other
Background initialization and replaces the following two lines in many of
the samples:

    def __init__(self, aParent, aId, aStackRsrc, aBgRsrc):
        PythonCardPrototype.model.Background.__init__(self, aParent, aId,
aStackRsrc, aBgRsrc)

with:

    def on_openBackground(self, source, event):

I'm using openBackground more like the openStack system message in HyperCard
right now, so when we have multiple backgrounds, the usage will change
slightly, since you would only want to init your background once. You'll
also notice that there isn't a name in the method above, which is now true
for any background handler such as the one in tictactoe.py

    def on_bg1_mouseClick(self, button, event):

which is now just:

    def on_mouseClick(self, button, event):

It isn't necessary to provide the name of the background anymore, because
the context is already known.

If you do checkout from cvs, please let me know if you find any problems. I
will be adding additional messages for window resize, window move, idle,
etc. tomorrow if all goes well.

And in case you're wondering, this is sort of tied into my experiments with
scrolling windows and sizers. Scrolling windows looks relatively
straightforward, so I may add that in the next day or two.


Debug menu/Shell feature
I added a "Redirect stdout to shell" option to the Debug menu, so you can
have any print statements in your code, go to the shell instead of the
console. The menu item acts as a toggle, so you can turn it on/off whenever
you like.

ka

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

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

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.

I'll post another message when cvs stabilizes.

ka

RE: [Pythoncard-users] Boa as an IDE for PythonCard?

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

Riaan, the primary Boa developer, has indicated that it would be quite
possible for Boa to work with some kind of resource file, rather than
generating all the code directly. He says the framework is not as
specialized as most people think it is. The Zope interaction is an example
of how the framework can support other development modes. I haven't delved
into the details enough to express my own opinion.

As far as the code generation part goes, there is a clear boundary between
the generated methods that Boa "owns" and the custom coded methods that you
own. As long as you don't try to modify the generated methods there is no
problem. That is the nature of a code generator. Boa should have enough
hooks to let you add whatever behavior your need without risk of
modification by the code generator. If not, complain to Riaan. He is
incredibly responsive to user demands, imo.

That said, I know Kevin in none too fond of code generators in general, and
I respect his point of view. Anything that generates code has its strengths
and its weaknesses. At the same time, it is quite possible the we will see
the day when some of these same complaints are levied against the PythonCard
Resource Editor (or whatever it evolves into). <wink>

---
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 Steven D.
Arnold
Sent: Wednesday, September 05, 2001 8:59 PM
To: Kevin Altis
Cc: pythoncard-Users; riaan@e.co.za
Subject: Re: [Pythoncard-users] Boa as an IDE for PythonCard?

<license stuff snipped>

On another note, I don't really like Riann's approach of using Python
code itself to generate interfaces.  It seems a lot more general to
use some flavor of XML to describe interfaces, and sharply distinguish
this from the user code.  This kind of separation/abstraction allows
one to easily modify the way interface elements work in one's code
without worrying about the IDE overwriting one's changes or making
other undesirable changes.  To put the policy in a sentence: anything
that is automatically generated by the IDE should not be modified by
the user (this would no doubt include the final code/binary as well as
interface template files).

Has anyone else experienced this kind of issue with Boa (or maybe
found a workaround that obviates it as a problem)?

------------------------------------------------------------------------
Steven D. Arnold                                  st...@ne...
AIM: abraxan                                               ICQ: 73804392
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Pythoncard-users] Boa as an IDE for PythonCard?

[Steven D. A. <st...@ne...>]

Hi Kevin,

On Tuesday, September 04, 2001, at 2:56:12 PM, you wrote:

KA> Kevin: Anyway, I would like to give it a shot, but I will not be
KA> locked into the GPL.

KA> Riaan: That's why I mentioned the MPL, if there was some sort of
KA> collaboration, I could relicense those core Boa files under the MPL
KA> which means those core files are 'like' GPL files (you have the
KA> make changes to those files available for free) but with the MPL
KA> you can integrate very easily to the core with code from any license.
KA> It only 'infects' things in the core. Not things that just use or
KA> integrate with it.

So this sounds much like the LGPL.  The core itself is open-source and
must remain so -- any modifications must be released.  But projects
that are built with it would not be GPL or MPL, nor would tools that
merely work with it or link it.  Is that the basic idea?

On another note, I don't really like Riann's approach of using Python
code itself to generate interfaces.  It seems a lot more general to
use some flavor of XML to describe interfaces, and sharply distinguish
this from the user code.  This kind of separation/abstraction allows
one to easily modify the way interface elements work in one's code
without worrying about the IDE overwriting one's changes or making
other undesirable changes.  To put the policy in a sentence: anything
that is automatically generated by the IDE should not be modified by
the user (this would no doubt include the final code/binary as well as
interface template files).

Has anyone else experienced this kind of issue with Boa (or maybe
found a workaround that obviates it as a problem)?

------------------------------------------------------------------------
Steven D. Arnold                                  st...@ne...
AIM: abraxan                                               ICQ: 73804392
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Pythoncard-users] PythonCard papers/tutorials for 10th Python Conference

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

February 4-7, 2002
Hilton Alexandria Mark Center
Alexandria, Virginia
http://www.python10.org/

I don't know whether I'll attend this conference or not, but I'm not
planning on writing a paper. I've had one person already contact me about
writing a paper on python in medical informatics that may use PythonCard as
their GUI.

I just wanted to let everyone know about the paper and tutorial deadlines in
case this is something you want to pursue.

Paper submission deadline:  Monday, October 8, 2001
http://www.python10.org/p10-callpapers.html

Tutorial Proposal submission deadline:  Monday, October 1, 2001
http://www.python10.org/p10-calltutorials.html

You have until mid-December to complete your entire paper or tutorial,
assuming that your initial proposal due in October is accepted.

Like I said, I won't be writing a paper myself, but if someone wants me to
review something I'll be happy to. If you want a little more involvement
such as co-authoring that is probably okay as well, but I'm not going to
write the paper since I'll be focusing on the framework, samples, etc.

ka

RE: [Pythoncard-users] Boa as an IDE for PythonCard?

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

I guess I need to reply to this. It's no secret that I'm a big fan of Boa. I
think it is a great tool and I enjoy using it every day for my own Python
development. I also think there is some potential synergy between Boa and
PythonCard. Now is probably not the time to explore this in great detail.
Both projects need a little more time to settle down. But this is something
I will keep in mind as I use both tools, and if anyone else is interested
they can join in the exploration.

---
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: Tuesday, September 04, 2001 1:56 PM
To: pythoncard-Users
Cc: riaan@e.co.za
Subject: [Pythoncard-users] Boa as an IDE for PythonCard?

A couple of weeks ago I contacted Riaan Booysen about his IDE for wxPython
called Boa. I was interested in using his frame designer and property editor
code in PythonCard, since those parts of the Boa UI seemed to work pretty
well, but I hadn't looked at his code yet.

Anyway, to make a long story short, I ended up writing my own code. The
issue we left unresolved was whether Boa should support editing PythonCard
apps, in particular the .rsrc.py files, but it could also act as a full IDE
for PythonCard. Suffice it to say that adding this support is non-trivial
and Riaan won't be doing it, someone on the PythonCard team would have to
pursue it.

Another issue is that Riaan would need to grant use to us with his modifed
GPL, or MPL as he calls it. From an earlier email:

Kevin: Anyway, I would like to give it a shot, but I will not be locked into
the GPL.

Riaan: That's why I mentioned the MPL, if there was some sort of
collaboration, I could relicense those core Boa files under the MPL
which means those core files are 'like' GPL files (you have the
make changes to those files available for free) but with the MPL
you can integrate very easily to the core with code from any license.
It only 'infects' things in the core. Not things that just use or
integrate with it.

Boa is at http://sourceforge.net/projects/boa-constructor/

What I would like to know is whether anyone interested in PythonCard is
using Boa or whether you think you would be interested in an IDE environment
like Boa that integrates Zope support, cvs, editing, a shell, and other
features [Now is the time for you to speak up Patrick  ;-)]

ka


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

[Pythoncard-users] SourceForgeTracker can launch web pages

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

I updated SourceForgeTracker so that when you double-click on an item in the
topics list it jumps to the tracker item in your web browser. It has no
impact on whether you are logged in or not to SourceForge. This makes it
easy to make modifications of an item or see the other details if you really
need that. The code to support this is pretty straightforward (sorry about
the wrapping):

    def doLaunch(self, url):
        # launch a new browser window and autoraise it
        # there appears to be a bug in webbrowser.py because
        # if a window already exists, a new one isn't being created ?!
        webbrowser.open(url, 1, 1)

    def on_topicList_mouseDoubleClick(self, target, event):
        #
http://sourceforge.net/tracker/index.php?func=detail&aid=446264&group_id=190
15&atid=119015
        selection = target.getStringSelection()
        if selection != "":
            artifactId, summary =
target.getStringSelection().split(TOPIC_SEPARATOR)
            group = self.components.choiceGroups.selection
            groupId = self.groupIds[group]
            category = self.components.choiceCategories.selection
            categoryId = self.categoryIds[group][category]
            url =
'http://sourceforge.net/tracker/index.php?func=detail&aid=' + \
                  str(artifactId) + '&group_id=' + str(groupId) + '&atid=' +
str(categoryId)
            self.doLaunch(url)

ka

Re: [Pythoncard-users] Boa as an IDE for PythonCard?

[Ronald D S. <rd...@ea...>]

Well, I am experimenting with Boa Constructor, and the more I learn about wxPython, the more I like Boa and the more usable I find
it to be. So, I would be happy to see Boa used as an IDE for PythonCard. One could do a lot worse.

Having said that, I still think Boa is a bit over-complex. It would be nice to have an IDE for PythonCard that was simpler but still
as powerful, but I guess you can't have everything ;-))).

My ideal IDE for PythonCard would include a programmable,  hypertext cardfile metaphor; but then I'm really dreaming and I'm not
sure I know what I am even talking about ;-))).

But it would sure be nice to use any parts of Boa that are possible. Boa is impressive and represents an awful lot of work.

Here's hoping the license issues don't get in the way.

Ron Stephens
----- Original Message -----
From: "Kevin Altis" <al...@se...>
To: "pythoncard-Users" <pyt...@li...>
Cc: <riaan@e.co.za>
Sent: Tuesday, September 04, 2001 2:56 PM
Subject: [Pythoncard-users] Boa as an IDE for PythonCard?


> A couple of weeks ago I contacted Riaan Booysen about his IDE for wxPython
> called Boa. I was interested in using his frame designer and property editor
> code in PythonCard, since those parts of the Boa UI seemed to work pretty
> well, but I hadn't looked at his code yet.
>
> Anyway, to make a long story short, I ended up writing my own code. The
> issue we left unresolved was whether Boa should support editing PythonCard
> apps, in particular the .rsrc.py files, but it could also act as a full IDE
> for PythonCard. Suffice it to say that adding this support is non-trivial
> and Riaan won't be doing it, someone on the PythonCard team would have to
> pursue it.
>
> Another issue is that Riaan would need to grant use to us with his modifed
> GPL, or MPL as he calls it. From an earlier email:
>
> Kevin: Anyway, I would like to give it a shot, but I will not be locked into
> the GPL.
>
> Riaan: That's why I mentioned the MPL, if there was some sort of
> collaboration, I could relicense those core Boa files under the MPL
> which means those core files are 'like' GPL files (you have the
> make changes to those files available for free) but with the MPL
> you can integrate very easily to the core with code from any license.
> It only 'infects' things in the core. Not things that just use or
> integrate with it.
>
> Boa is at http://sourceforge.net/projects/boa-constructor/
>
> What I would like to know is whether anyone interested in PythonCard is
> using Boa or whether you think you would be interested in an IDE environment
> like Boa that integrates Zope support, cvs, editing, a shell, and other
> features [Now is the time for you to speak up Patrick  ;-)]
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] PythonCard and Distutils

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

Hi!

I've made setup.py and MANIFEST.in for the PythonCardPrototype.
(For now Kevin posted them as attachments)

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


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



Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rn...@on... -
 

[Pythoncard-users] default sizes and Property Editor, resourceEditor

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

I changed both the Property Editor and resourceEditor so that they handle
default sizes for the widgets. That means that if the width or height of a
widget matches the default size as calculated by wxWindows/wxPython, then
the Property Editor will report the value as -1. The resourceEditor will not
generate a size attribute if the size is (-1, -1). Typically, text fields
and buttons have a default height and that height changes as the font size
changes, so if you change the font size, you'll probably want to select the
widget, set the height of the (width, height) tuple to -1 and hit update.

Let me know if you find any bugs or weird behavior. There is one bug for the
resourceEditor that I don't really have a good solution for that is somewhat
related. Basically, if you change the position or size of a widget via the
Property Editor when a widget is selected and the sizing handles are
showing, then the sizing handles will not change position to match the
widget. You'll also notice that as the selected component changes via the
Property Editor, the sizing handles stay on the last widget clicked on.
These are bugs we're just going to have to live with for a while.

ka

RE: [Pythoncard-users] enable and check menu items

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

In order to make a menu item checkable, you need to specify that in the
.rsrc.py file. For example, I modified conversions.rsrc.py:

            { 'type':'Menu',
              'name':'mnuConvert',
              'label':'Convert',
              'items': [
                { 'type':'MenuItem',
                  'name':'menuConvertMorseCode',
                  'label':'Morse Code',
                  'checkable':1 },
                { 'type':'MenuItem',
                  'name':'menuConvertTemperature',
                  'label':'Temperature',
                  'checkable':1,
                  'checked':1} ]
              }

So, both 'Convert' menu items are checkable and I set 'Temperature' to be
checked when the application starts. I modified conversions.py, so that when
one of the items is checked, the other one is unchecked.

    def on_menuConvertMorseCode_select(self, menu, event):
        self.conversion = MorseCodeConversion(self.components)
        self.menuBar.setChecked('menuConvertMorseCode')
        self.menuBar.setChecked('menuConvertTemperature', 0)

    def on_menuConvertTemperature_select(self, menu, event):
        self.conversion = TemperatureConversion(self.components)
        self.menuBar.setChecked('menuConvertMorseCode', 0)
        self.menuBar.setChecked('menuConvertTemperature')

The defaults (specified in spec.py) are that menus are enabled, and menu
items are enabled, but not 'checkable', so the other samples run without
modifications. If you specify that a menu item is checkable and want it
checked you'll have to specify that, since the default is 0, which is why it
is specified for 'Temperature' above.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, September 04, 2001 4:36 PM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] enable and check menu items
>
>
> I changed the method names to
>     getChecked
>     setChecked
>     getEnabled
>     setEnabled
>
> getChecked and getEnabled return -1 if the MenuItem can't be found
>
> >>> bg.menuBar.getEnabled('bogus')
> -1
>
> You can enable or disable a whole menu like so (example using proof.py):
>
> >>> bg.menuBar.setEnabled('mnuFile', 0)
>
> Due to a missing feature in wxPython, finding out whether a whole menu is
> enabled or disabled will have to wait until 2.3.2 is released
> unless I find
> that I missed a method in the docs.
>
> BTW, the methods above obviously aren't dot notation. You would need to do
> something like:
> >>> bg.menubar.mnuFile.mnuExit.enabled = 1
>
> which menu.py doesn't currently support. Since menu.py needs to be
> completely rewritten at some point, we'll probably wait until the
> rewrite to
> do dot notation. The existing module won't accomodate it very easily.
>
> ka
>
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of Kevin
> > Altis
> > Sent: Tuesday, September 04, 2001 3:31 PM
> > To: pythoncard-Users
> > Subject: [Pythoncard-users] enable and check menu items
> >
> >
> > I updated menu.py in cvs, so you can now enable/disable and
> check/uncheck
> > menu items. You pass in the 'name' of the MenuItem object as
> > defined in the
> > .rsrc.py file for the application.
> >
> > For example, if you run proof.py with the shell, you can disable
> > the File ->
> > Exit menu item with:
> >
> > >>> bg.menuBar.enable('mnuExit', 0)
> >
> > and then enable it with:
> >
> > >>> bg.menuBar.enable('mnuExit')
> >
> > you can check a menu item the same way. You can't disable/enable a whole
> > menu right now, because the method I wanted to use apparently isn't in
> > wxPython 2.3.1 even though it is in the docs. If I figure out
> > another way to
> > do it, I'll make the change.
> >
> > I updated the addresses sample to use this method rather that relying on
> > wxPython method calls directly.
> >
> >             #menubar = self.GetMenuBar()
> >             #id = menubar.FindMenuItem('File', 'Import Outlook')
> >             #menubar.Enable(id, 0)
> >             self.menuBar.enable('menuFileImportOutlook', 0)
> >
> > ka
> >
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> >
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] enable and check menu items

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

I changed the method names to
    getChecked
    setChecked
    getEnabled
    setEnabled

getChecked and getEnabled return -1 if the MenuItem can't be found

>>> bg.menuBar.getEnabled('bogus')
-1

You can enable or disable a whole menu like so (example using proof.py):

>>> bg.menuBar.setEnabled('mnuFile', 0)

Due to a missing feature in wxPython, finding out whether a whole menu is
enabled or disabled will have to wait until 2.3.2 is released unless I find
that I missed a method in the docs.

BTW, the methods above obviously aren't dot notation. You would need to do
something like:
>>> bg.menubar.mnuFile.mnuExit.enabled = 1

which menu.py doesn't currently support. Since menu.py needs to be
completely rewritten at some point, we'll probably wait until the rewrite to
do dot notation. The existing module won't accomodate it very easily.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, September 04, 2001 3:31 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] enable and check menu items
>
>
> I updated menu.py in cvs, so you can now enable/disable and check/uncheck
> menu items. You pass in the 'name' of the MenuItem object as
> defined in the
> .rsrc.py file for the application.
>
> For example, if you run proof.py with the shell, you can disable
> the File ->
> Exit menu item with:
>
> >>> bg.menuBar.enable('mnuExit', 0)
>
> and then enable it with:
>
> >>> bg.menuBar.enable('mnuExit')
>
> you can check a menu item the same way. You can't disable/enable a whole
> menu right now, because the method I wanted to use apparently isn't in
> wxPython 2.3.1 even though it is in the docs. If I figure out
> another way to
> do it, I'll make the change.
>
> I updated the addresses sample to use this method rather that relying on
> wxPython method calls directly.
>
>             #menubar = self.GetMenuBar()
>             #id = menubar.FindMenuItem('File', 'Import Outlook')
>             #menubar.Enable(id, 0)
>             self.menuBar.enable('menuFileImportOutlook', 0)
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] FW: did you want to commit to getting distutils going for PythonCard?

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

Thanks Roman!

I'm working on other things this afternoon, so if someone familiar with
distutils wants to double-check Roman's setup, try building a distribution
for Linux, Windows, Solaris, etc. and then check the files that would be
great.

I don't know if the instructions below are complete and I don't want to dive
into distutils myself right now.

Thanks,

ka

-----Original Message-----
From: Roman Suzi [mailto:rn...@on...]
Sent: Tuesday, September 04, 2001 3:04 PM
To: Kevin Altis
Subject: RE: did you want to commit to getting distutils going for
PythonCard?



setup.py ready but I am unsure if there is some
program (like PythonCard used to be) which can be run.
This program is a script and need to be put into
execution path).

Please, submit attached files to the root dir of PythonCardProto.

Now you can do Distutilish ways:

python setup.py sdist
python setup.py bdist_rpm
python setup.py bdist_wininst

and many more!

Please, add README.txt file to the root dir telling the above. And then
README.txt could be uncommented in he setup.py.
(README.txt is somehow needed by Distutils. I do not know what for)

TODOs are in setup.py marked by XXX.

Unchecked on Windows, works in my RH 6.2.
Please, also check for the integrity of
tar.gz (or zip) maked by sdist: haven't I lost any
files?

P.S. I have sf account but probably it is faster if you add
these files to CVS for me.

It's late here, so I go sleeping. Sorry if my language was yawny,

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Tuesday, September 04, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Useless Invention: Fine glass-crystal castanets." _/

[Pythoncard-users] enable and check menu items

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

I updated menu.py in cvs, so you can now enable/disable and check/uncheck
menu items. You pass in the 'name' of the MenuItem object as defined in the
.rsrc.py file for the application.

For example, if you run proof.py with the shell, you can disable the File ->
Exit menu item with:

>>> bg.menuBar.enable('mnuExit', 0)

and then enable it with:

>>> bg.menuBar.enable('mnuExit')

you can check a menu item the same way. You can't disable/enable a whole
menu right now, because the method I wanted to use apparently isn't in
wxPython 2.3.1 even though it is in the docs. If I figure out another way to
do it, I'll make the change.

I updated the addresses sample to use this method rather that relying on
wxPython method calls directly.

            #menubar = self.GetMenuBar()
            #id = menubar.FindMenuItem('File', 'Import Outlook')
            #menubar.Enable(id, 0)
            self.menuBar.enable('menuFileImportOutlook', 0)

ka

Re: [Pythoncard-users] Sizers and Layout

[Neil H. <ne...@sc...>]

Kevin Altis:

> Neil actually did a demo that uses the .rsrc.py files to make a web page
> suitable for use in a browser, so the layout of PythonCard background can
> sort of be used as HTML. I thought Neil was going to check the files into
> cvs at:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/proto/samples/
>
> but I don't see the files (Neil can you check them in?). The original
> message is:
> http://groups.yahoo.com/group/pythoncard/message/397

   OK, Pyker.hta and PykerLaunch.hta are now in CVS. These are HyperText
Applications and work only on Windows with a recent version of Internet
Explorer. Similar work could be done in Mozilla with the Python interpreter
embedded although not too many people have this set up.
   Pyker.hta displays the PythonCard resource file given as a command line
argument.
   PykerLaunch.hta displays a list of resource files in subdirectories and
clicking on one displays it using Pyker.hta.

   While I don't intent to takes these any further, they are reasonable
demonstrations of the ability of browsers to produce diverse user
interfaces. It may be possible to turn this code into a PythonCard player
that hosts PythonCard applications inside browsers in a similar manner to
the current wxPython based host.

> Perhaps it might be best for Neil to go into this subject more when he
gets
> time or the framework stabilizes to the point that someone can experiment
> with this without having to update the files with every API change.

   The API resource file hasn't changed since Pyker was first written so
still works.

   Neil

[Pythoncard-users] FW: did you want to commit to getting distutils going for PythonCard?

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

Any Mac users tuning in? The Mac normally uses just a carriage-return (CR)
for line endings. Perhaps distutils resolves all this for us and it is a
non-issue.

ka

-----Original Message-----
From: Roman Suzi [mailto:rn...@on...]
Sent: Tuesday, September 04, 2001 12:59 PM
To: Kevin Altis
Subject: RE: did you want to commit to getting distutils going for
PythonCard?


On Tue, 4 Sep 2001, Kevin Altis wrote:

>> Yes, I will to find time to look at it this week.
>> I will mail you setup.py and MANIFEST.in when ready. OK?
>
>That's fine. Will this give us double-clickable binary installers or is
that
>a separate process?

If properly done, Distutils make Wininstallers and rpms automagically.
(and tar.gz-s and zip-s for those who want them).

I am less sure about handling CRLF-s though... Maybe, UNIX line ends are
expected and proper line-ends are created. I still think that UNIX line
ends are more Pythonic: there are no problems with them in Python for
Windows, but on UNIX LFs are fatal...

Making setup.py is easy. PythonCard is in pure Python
(no C) - so all it's files are:
 - modules
 - data
 - scripts
 - docs

I only need know which are which and make a couple of functions which sort
them out automatically (based on the directory structure, etc)

>> I only need to know if there will be no major structural
>> changes to the directory layout in the PythonCardProto distro
>> at least for some time.
>
>Nothing major. There might be additional files added to
PythonCardPrototype,
>but the directory won't change.

>ka

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Tuesday, September 04, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Useless Invention: Fine glass-crystal castanets." _/

RE: [Pythoncard-users] Re: Encapsulation

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

> Something like a .jar sounds cool to me.  What's a .pyw file?

If you don't want your .py Python script to launch a console window, rename
it to .pyw and it will get launched by pythonw instead of python and the
console window won't show up. For example, in my local copies, I renamed
worldclock and searchexplorer to:

  worldclock.pyw
  searchexplorer.pyw

No changes to the .rsrc.py file. Basically, once the debugging is done, if
your app doesn't use the console for output, then renaming to .pyw is
usually a good thing.

ka

[Pythoncard-users] Re: Encapsulation

[PeterAndBrian <pe...@pe...>]

At 11:25 AM 9/4/2001 -0700, Kevin wrote:
>The way to do this will be to have the equivalent of a Java .jar file,
>basically a .zip or something with a well-defined manifest describing the
>other files in the archive. The .jar equivalent has to be double-clickable
>or runnable just like any other .py script, so it will probably be a .pyw
>file with some other magic. Yet another project for someone to figure out.
>We will have multiple resource descriptions, modules, images, sounds, icons,
>cursors, configuration info, user data and all sorts of things that
>typically get stuck in the resource fork in a Mac application and in a
>sub-directory on Unix and Windows.

Something like a .jar sounds cool to me.  What's a .pyw file?

Sounds like there may come a day when we want some features from the 
Macintosh Resource Manager - if something like that does not already exist 
in the Python world.  I wonder if Apple's open source Darwin project 
includes the Resource Manager for OS X.  We cold not use the code directly, 
without resorting to compiled C - but it might be instructive if we have to 
implement something like it.

[Pythoncard-users] Boa as an IDE for PythonCard?

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

A couple of weeks ago I contacted Riaan Booysen about his IDE for wxPython
called Boa. I was interested in using his frame designer and property editor
code in PythonCard, since those parts of the Boa UI seemed to work pretty
well, but I hadn't looked at his code yet.

Anyway, to make a long story short, I ended up writing my own code. The
issue we left unresolved was whether Boa should support editing PythonCard
apps, in particular the .rsrc.py files, but it could also act as a full IDE
for PythonCard. Suffice it to say that adding this support is non-trivial
and Riaan won't be doing it, someone on the PythonCard team would have to
pursue it.

Another issue is that Riaan would need to grant use to us with his modifed
GPL, or MPL as he calls it. From an earlier email:

Kevin: Anyway, I would like to give it a shot, but I will not be locked into
the GPL.

Riaan: That's why I mentioned the MPL, if there was some sort of
collaboration, I could relicense those core Boa files under the MPL
which means those core files are 'like' GPL files (you have the
make changes to those files available for free) but with the MPL
you can integrate very easily to the core with code from any license.
It only 'infects' things in the core. Not things that just use or
integrate with it.

Boa is at http://sourceforge.net/projects/boa-constructor/

What I would like to know is whether anyone interested in PythonCard is
using Boa or whether you think you would be interested in an IDE environment
like Boa that integrates Zope support, cvs, editing, a shell, and other
features [Now is the time for you to speak up Patrick  ;-)]

ka

RE: [Pythoncard-users] Encapsulation - was Script Encapsulation

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

> From: PeterAndBrian
>
> Yes, I agree we need to maintain the ability to edit and test in IDLE for
> now, since PythonCard IDE does not exist yet.  Yet, it's so NICE to have
> scripts bound to objects.  Perhaps we could have both.

I think we can, I'm just not sure about the actual implementation yet.

> If we added an ID property to all objects, we could adopt a naming
> convention that used the ID in all handlers that "belong to" that
> object.  For instance, we might make a rule that object-specific handlers
> include a pattern like "_[0-9]+_".  Then, the function
> "on_123_mouseDown()"
> could be recognized as belonging to the object who's ID is 123.  And, if
> all _123_ handlers were clustered together in an appropriately (and
> automatically) commented section of the code, they would be
> reasonable for
> conventional IDLE coders to work with.

PythonCard uses 'name' as the id for a component and we're pretty much doing
what you describe above, at least as I understand it. 'name' must be unique
at a given level of the hierarchy, so all the components (widgets) of the
background have unique names. Initially, I thought we would follow the
standard HyperCard method of supporting a name, number, and unique id, where
the unique id is actually a globally unique identifier created by the
framework that is never reused and can't be changed once created. However,
because dictionaries and lists are a fundamental part of Python, it looks
like we can get by with just using names as the unique identifier, at least
for what is exposed to the user programmer and it ends up making PythonCard
more "pythonic" because you have one way of doing an object reference.

> To support object copy and paste between stacks, we could pack up all the
> handlers into a .script property, just while traveling.  Then, on paste,
> they could be integrated into the destination stack.  The IDs
> might need to
> be adjusted at some point. If you copy and paste an object into the same
> stack (or another stack where that ID exists) the pasted object
> will need a
> new ID, and handlers tagged by ID would need to be adjusted.  But that's
> doable.

This is where it gets tricky. Dan Winkler brought this up when I was
chatting with him last week. We were actually talking about copying whole
cards or backgrounds, the layout, graphics, scripts, and data in the
widgets. Since we don't have the environment going yet, I shelved the
problem as any good procrastinator would do. At some point, we have to
evaluate how this is going to work. This is one of the big problem points
when you still support editing outside the environment since an id ('name')
change can cause all sorts of things to break. Simply matching a textual
label as the id through the rest of the code won't work.

There are a number of things I consider warts in HyperCard that we don't
have to recreate. For example, it is often better to create a separate class
to handle a lot of your logic and so the actual handlers associated with a
widget don't need to have all the logic, they just use the separate class.
This increases readability and code reuse. Another thing that we can do at
some point is allow an arbitrary data structure, class, etc. to be part of a
card or background, so that rather than using a hidden Field to store data
as was so common in HyperCard, you can just pickle a Python object and get
all of the benefits without the kludge aspects.

> It all comes back to the lovely simplicity HyperCard provided.
> One stack =
> one file = one application = one window.  OK, the one window part sucked,
> but you see where I'm going.
>
> What do you think about merging all dependant files in a single .py file,
> making PythonCard stacks fully self contained?  Is this feasible or
> desirable?
>
> It would not be too hard to merge the Resourse file into the main
> module.  But what about icons, graphics, sounds - the binary payload
> HyperCard stacks used to carry?  It might never be efficient to
> do this in
> a text based format (base-64 encoding anyone?). That leads us to a binary
> format - a whole stack as one big pickled object?  That doesn't sound so
> great either.

The way to do this will be to have the equivalent of a Java .jar file,
basically a .zip or something with a well-defined manifest describing the
other files in the archive. The .jar equivalent has to be double-clickable
or runnable just like any other .py script, so it will probably be a .pyw
file with some other magic. Yet another project for someone to figure out.
We will have multiple resource descriptions, modules, images, sounds, icons,
cursors, configuration info, user data and all sorts of things that
typically get stuck in the resource fork in a Mac application and in a
sub-directory on Unix and Windows. Many samples already have multiple files.
If somebody solves this problem now, we'll have to revise it as our
resources and modules change with the framework, but that shouldn't be a big
deal.

I would like to get a fair amount of reuse out of the resources and modules,
so that you can borrow whole files from another PythonCard app. I would also
like to be able to break up pieces of the resource file so that we can do
imports for common pieces like the Edit menu, a Find dialog, etc. We won't
have the closed single binary file of a HyperCard stack, so our paradigms
for sharing pieces of an app are going to be different even if many of the
intentions are the same.

ka

[Pythoncard-users] Encapsulation - was Script Encapsulation

[PeterAndBrian <pe...@pe...>]

Yes, I agree we need to maintain the ability to edit and test in IDLE for 
now, since PythonCard IDE does not exist yet.  Yet, it's so NICE to have 
scripts bound to objects.  Perhaps we could have both.

If we added an ID property to all objects, we could adopt a naming 
convention that used the ID in all handlers that "belong to" that 
object.  For instance, we might make a rule that object-specific handlers 
include a pattern like "_[0-9]+_".  Then, the function "on_123_mouseDown()" 
could be recognized as belonging to the object who's ID is 123.  And, if 
all _123_ handlers were clustered together in an appropriately (and 
automatically) commented section of the code, they would be reasonable for 
conventional IDLE coders to work with.

To support object copy and paste between stacks, we could pack up all the 
handlers into a .script property, just while traveling.  Then, on paste, 
they could be integrated into the destination stack.  The IDs might need to 
be adjusted at some point. If you copy and paste an object into the same 
stack (or another stack where that ID exists) the pasted object will need a 
new ID, and handlers tagged by ID would need to be adjusted.  But that's 
doable.

It all comes back to the lovely simplicity HyperCard provided.  One stack = 
one file = one application = one window.  OK, the one window part sucked, 
but you see where I'm going.

What do you think about merging all dependant files in a single .py file, 
making PythonCard stacks fully self contained?  Is this feasible or 
desirable?

It would not be too hard to merge the Resourse file into the main 
module.  But what about icons, graphics, sounds - the binary payload 
HyperCard stacks used to carry?  It might never be efficient to do this in 
a text based format (base-64 encoding anyone?). That leads us to a binary 
format - a whole stack as one big pickled object?  That doesn't sound so 
great either.

What do you guys think?

Peter

Re: [Pythoncard-users] anygui docs

[Magnus L. H. <ml...@id...>]

From: "Kevin Altis" <al...@se...>


> Sorry, I should have been more clear, I mostly meant borrowing
documenation
> ideas.

Ah!

You might want to check out the doc sources in CVS too, then. They are
written in a homebrewn XML dtd, and transformed with XSL to LaTeX and
HTML, which is again transformed to pdf, ps and text using pdfLaTex,
pdf2ps and Lynx.

(Didn't I mention that I liked XML and LaTeX? <wink>)

> I think we'll wait until anygui is a bit further along before borrowing
much
> from the framework itself.

A wise decision, I think. Anygui is fluctuating quite a bit at the moment.

> Of course, at some point it might be sitting
> under PythonCard instead of just wxPython.

As I have said before, I think that would be a good idea for both projects.
(Strength in numbers... :)

> ka


--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

RE: [Pythoncard-users] anygui docs

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

Sorry, I should have been more clear, I mostly meant borrowing documenation
ideas. Thanks for the pointer to Greg's docs. Apparently, everyone but me
can write documenation.

I think we'll wait until anygui is a bit further along before borrowing much
from the framework itself. Of course, at some point it might be sitting
under PythonCard instead of just wxPython.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Magnus
> Lie Hetland
> Sent: Tuesday, September 04, 2001 9:25 AM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] anygui docs
>
>
> If you want to "borrow" ideas, I suggest you also
> take a look at Greg's GUI API [1] (which has been mentioned
> before) which is the basis for a lot of the Anygui
> API.
>
> Also, the Anygui docs are available in more formats
> at:
>
>   http://www.idi.ntnu.no/~mlh/anygui
>
> _And_ they are very much in a state of flux :)
>
> [1] http://www.cosc.canterbury.ac.nz/~greg/python_gui/
>
> --
>
>   Magnus Lie Hetland         http://www.hetland.org
>
>  "Reality is that which, when you stop believing in
>   it, doesn't go away."           -- Philip K. Dick
>
> ----- Original Message -----
> From: "Kevin Altis" <al...@se...>
> To: "pythoncard-Users" <pyt...@li...>
> Sent: Tuesday, September 04, 2001 5:42 PM
> Subject: [Pythoncard-users] anygui docs
>
>
> > Magnus has put up some docs
> > http://www.idi.ntnu.no/~mlh/anygui/anygui.html
> > for the anygui project. Yet another place to "borrow" ideas from :)
> >
> > ka
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] anygui docs

[Magnus L. H. <ml...@id...>]

If you want to "borrow" ideas, I suggest you also
take a look at Greg's GUI API [1] (which has been mentioned
before) which is the basis for a lot of the Anygui
API.

Also, the Anygui docs are available in more formats
at:

  http://www.idi.ntnu.no/~mlh/anygui

_And_ they are very much in a state of flux :)

[1] http://www.cosc.canterbury.ac.nz/~greg/python_gui/

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

----- Original Message ----- 
From: "Kevin Altis" <al...@se...>
To: "pythoncard-Users" <pyt...@li...>
Sent: Tuesday, September 04, 2001 5:42 PM
Subject: [Pythoncard-users] anygui docs


> Magnus has put up some docs
> http://www.idi.ntnu.no/~mlh/anygui/anygui.html
> for the anygui project. Yet another place to "borrow" ideas from :)
> 
> ka
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] anygui docs

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

Magnus has put up some docs
http://www.idi.ntnu.no/~mlh/anygui/anygui.html
for the anygui project. Yet another place to "borrow" ideas from :)

ka