pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] the future direction of PythonCard

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

   Kevin:

> Is anyone using the current prototype? We've had a reasonable number of
> downloads, but the list is very quiet.

   I'm not currently using PythonCard. Much of my UI code is still done in
low level C++ but that is just because of my context. If I wanted to do
something at a high level, either as a mock-up or for-real I'd use browser
based technologies.

> Based on the current samples, is the current framework too complex or too
> limiting or just right?

   The framework appears OK to me but ultimately, its not the framework that
I'd expect to be the appealing feature but the development environment built
on top.

> What elements need to be added to the current framework before you would
use
> PythonCard for your own work?

   It is unlikely PythonCard could have been used for any of the work I have
done recently or expect to do in the near future. Client needs often
constrain technology choices. For the open source projects that I mostly
control, Scintilla and SciTE, PythonCard does not appear to fit any need in
a sensible way.

   SciTE (a text editor) could be written as a PythonCard application but it
is already written in C++ so there is not much point. I have been thinking
about building a demonstration web oriented development environment but that
would be housed inside a web browser.

   A finished and high quality PythonCard would, for me, be useful in
prototyping applications that are shown to clients and then reimplemented in
C++ or Java. One enquiry that could have been demoed with PythonCard but
didn't get anywhere near that far was to build a diagram editor for software
design.

> Is the most important thing having an environment like HyperCard?

   That is a very important aspect but another important aspect will be
deployability. For big budget work, even complex deployment can be viable.
For the sort of rapidly developed small tools that PythonCard could be used
for, deployment should be very simple.

> Project Roles [...]
> Both Neil and Robin
> answer questions, but otherwise are not currently involved in PythonCard
> code.

   That is about as much as I can offer now. I can also do some small pieces
of code to demonstrate techniques but can't really sign up for anything
significant.

> What do you want PythonCard to be?

   Cross-platform HyperCard with Python.

   Neil

Re: [Pythoncard-users] the future direction of PythonCard

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

Kevin,

A stimulating post, my thoughts and suggestions are interspersed below 
but, in summary, I'm not giving up and I would hope the other 
subscribers to this list can spare enough time and/or brain cells to 
keep this project going. I think we have built something pretty great 
and would like to keep it going.

Kevin Altis wrote:

> We're approaching the four month mark since the start of the PythonCard
> mailing list. This seems like a good time to evaluate where the project
> currently stands, whether we're on track, and what direction we should head
> in the future. Even the lurkers out there should respond in some fashion to
> this message if they're interested in the future direction of PythonCard.
> 
> Issues in no particular order:
> 
> Is anyone using the current prototype? We've had a reasonable number of
> downloads, but the list is very quiet. The apps I know about are the samples
> included with each release, some experiments of my own and Simon's blogger
> app. I'm probably forgetting something. Ron posted some source to the list
> and I'm assuming he is still experimenting with PythonCard. Is anyone else
> playing with PythonCard?


I'm using it. I'm trying to test and stress it but am very happy to 
report that I haven't found any problems yet. Maybe I'm not looking in 
the right places, or maybe I'm just lucky. Whatever the reason I shall 
keep trying.

> 
> Based on the current samples, is the current framework too complex or too
> limiting or just right?


It is a little complex to understand at first but once it all slots 
together I think we have a great operating model. My initial problems 
are probably due to my inexperience and no doubt some documentation 
would help. See my to do list at the end of this message.

> 
> What elements need to be added to the current framework before you would use

> PythonCard for your own work?


1. Multiple windows
2. Multiple windows
3. Multiple windows
4. Timers
5. There is no item number 5
6. Multiple windows

> 
> Is the most important thing having an environment like HyperCard?


I would say it is multiple windows ;-)

> 
> Project Roles
> The last update to the roles list was on July 12th, so it is out-of-date
> http://aspn.activestate.com/ASPN/Mail/Message/676720
> At this point, I'm doing most of the work on the framework and samples.
> Patrick is working on PyCrust, which we use for our shell and namespace
> viewer. Andy is still active, but not on the framework. Both Neil and Robin
> answer questions, but otherwise are not currently involved in PythonCard
> code. Rowland is not active either, though we owe a debt to him for the
> original framework, ideas, etc. Rowland and I mostly chat about PythonCard
> outside the list. Roman helped start the distutils work, but Andy took that
> over. There have been a few people offering to get involved, but real life,
> work, etc. has overridden most of the good intentions. There is a limited
> amount we can accomplish without more developers. This will have an impact
> on the scope of the project, so if you're interested in a particular area
> please speak up.
> 
> Documentation
> Suggestions for getting some docs done? Anything in particular you want in
> terms of documentation?


A users guide would be good I think, also a reference guide. I have 
started on the first steps towards a reference guide. Specifically I'm 
trying to generate the widget types and their valid attributes from 
spec.py into some form of HTML (first, then XML perhaps) but it isn't 
ready for public consumption yet.

I'm really interested in generating large parts of documentation 
automatically but I'm not a huge fan of the complex solutions they are 
talking about over on the Doc-Sig (http://www.python.org/sigs/doc-sig), yet.

> 
> The project name
> Is everyone happy with the name PythonCard? I wouldn't bring this up except
> that recently I learned a number of people had never even bothered to look
> at PythonCard because of the implied similarity to HyperCard. There are a
> lot of people out there that have never used a Mac and even if they have, a
> lot of people never liked HyperCard and considered it a toy for building
> apps. On the other hand, a lot of HyperCard users expect PythonCard to
> provide a complete environment, so the name doesn't reflect so much what we
> have today, but what we hope to achieve. It doesn't help that wxPython
> doesn't run on the Mac yet.


I'm happy with the name. As for the link with HyperCard turning people 
off, we do say on the project web page (http://pythoncard.sf.net) "This 
is a project to build a HyperCard like tool in, and using, the Python 
language"

Maybe we could stress it more but the second sentence on our home page 
should be enough shouldn't it? My only suggestion would be to emphasise 
as often as possible that HyperCard is an inspiration, not a specification.

Failing that, I believe the name 'Monty' was suggested back when this 
list was on Yahoo! and checking on sourceforge that project name isn't 
taken yet ;-)

> 
> Should we move beyond the prototype and make the next major release an alpha
> version of the real framework?


That depends on what we decide the alpha release should include. I know 
thats a circular argument but what I think we need to do before anything 
else is state what we are trying to achieve. I know Kevin has an idea, 
as do I, of what we want from PythonCard (see below) and so probably 
does everyone else reading this list. What we haven't done recently is 
check whether we are all on the same page. Lack of posts to this list 
don't help of course, so shout out please everyone.

> 
> How thin should the framework layer be over wxPython? That's a loaded
> question. The implication is that we will only be able to achieve our goals
> with wxPython instead of alternative GUI toolkits for Python. That may or
> may not be true. What do we want to achieve with our framework sitting on
> top of wxPython that wxPython doesn't provide?


Simplicity. I looked briefly at wxPython (and tkinter, etc.) when I 
started to learn Python and ran away - very quickly. Necessarily these 
toolkits are very close to the os/hardware, which is great if you are 
writing Word or Mozilla but not if you are writing an order entry 
application (like I want to do).

The decision to use wxPython was a pragmatic (and I think correct) one 
when we started out on the prototype and still holds true for me. Once 
we have a working framework with a consistent API we could look at the 
applicability of different backends but let us build the horse first 
before selecting a different cart.

> 
> What parts of the framework are most important to you? Some possibilities:
>   Layout descriptions in resource files
>   Automatic widget creation and event binding
>   Dot notation for widgets and other framework items
>   on_widget_event style handlers
>   runtime tools such as the shell, message watcher, property editor


In order; resource files, runtime tools, dot notation, modular 
architecture. Oh, and multiple windows.

> 
> Are the samples useful?


They are, but then I would say that wouldn't I.

> 
> What do you want PythonCard to be?


I want to be able to easily build small to medium sized GUI applications 
  with as little (or as much as necessary) coding as possible. I only 
briefly used HyperCard but I've also used VB, Delphi, Oracle Forms, 
Powerbuilder, etc. and an easy to use version of those kind of app 
builders is what I am after. I'm mindful of the other tools under 
development as well though (specifically Boa and wxDesigner) and suggest 
we try and complement them rather than compete.

I am also a fan of CP4E and think that PythonCard could address this 
requirement as well. Is it in line with my first requirement? Possibly, 
if you consider the shell and the resource editor. Ease of use should be 
our aim, 'kiss' (keep it simple stupid) our motto.

> 
> I definitely pushed PythonCard in the direction I thought it should go back
> in July and I'm going to continue to pursue PythonCard in some form, but it
> may be time to revise some of the original goals. I'll give other people a
> chance to respond before stating some of my own preferences.


I hope I've added some fuel to the fire. I'd like to take this 
opportunity to thank Kevin, Patrick, Rowland, Neil, Robin, Roman (and 
anyone else I've forgotten) who have built something pretty wonderful in 
a few short months. I for one am not giving up on it. Even if we stopped 
work on the framework tomorrow we still have a valuable body of code to 
work with and on. As I've said to Kevin privately I don't feel qualified 
to play with the framework code but one of my aims whilst participating 
in this project is to acquire the knowledge to be able to do so. It 
would be easier if the folks who wrote the code are around to help me 
understand it though ;-)

> 
> This is an open-ended post, so feel free to bring up any topic you think
> relates to the current state of PythonCard or its future even if I didn't
> touch on the topic above.
> 
> ka
> ---
> Kevin Altis
> al...@se...
> 

As I promised at the top of this mail, here are the tasks I'm currently 
working on (or thinking about);


Documentation. I'm trying to write some routines to automatically 
generate components of a reference guide. I think we also need to revise 
  and expand the getting started guide that Kevin wrote and perhaps add 
a guide to how the framework is structured for people who wish to 
examine it (like me).

Data store support. I'm trying to add support for CSV files and more 
varieties of relational databases (Gadfly, PostrgeSQL, Oracle) to the 
dbBrowser sample. My next step would be to try and fit one of these 
(probably Gadfly) into some kind of persistent storage layer for the 
framework as a whole. This slightly overlaps Patrick's investigations 
with ZODB but I think they don't overlap. I got a bit side tracked here 
as Gadfly doesn't operate 'out of the box' with Python 2.0+ and have 
started a thread on the DB-SIG mailing list about upgrading it. That has 
distracted me a bit but should benefit the wider Python community as 
well as, eventually, PythonCard.

Improve the dbBrowser application. My target is to produce a useful 
general purpose RDMBS tool like TOAD (http://www.quest.com/toad). That's 
probably a little ambitous but I am shooting high. If I continue this 
application I may have to move it to wxPython but PythonCard is giving 
me a valuable head start. If I didn't have PythonCard I wouldn't have 
started on this path, reason enough for me to be thankful for PythonCard.

Statement of requirements. We need one. If we know what we want, we know 
how far we have to go to get there. We started with a broad idea of 
which widgets and events we wanted to support when the prototype kicked 
off but now is a good time to more properly define our requirements. 
I've put my broad thoughts in this mail and am happy to discuss them 
with you all.

Packaging. We have used distutils to create the packages which can be 
downloaded from SourceForge. Most of the good work was Roman's, most of 
the head scratching was mine. The documentation for distutils is bad, it 
  provides a very limited example but never explains how it works or 
what its limitations are. I think we need to dig a little deeper into 
the structure of the standard utilities to make them more usable for 
PythonCard (subclassing is apparently the way to go but I haven't tried 
that yet). I also think some new documentation is required and I've 
started on that too. The activity level on the distutils-sig mail list 
makes this one look quite lively so I don't think we will step on any 
toes if we start to produce some more understandable documentation for a 
part of the standard library ;-)

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

[Pythoncard-users] the future direction of PythonCard

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

We're approaching the four month mark since the start of the PythonCard
mailing list. This seems like a good time to evaluate where the project
currently stands, whether we're on track, and what direction we should head
in the future. Even the lurkers out there should respond in some fashion to
this message if they're interested in the future direction of PythonCard.

Issues in no particular order:

Is anyone using the current prototype? We've had a reasonable number of
downloads, but the list is very quiet. The apps I know about are the samples
included with each release, some experiments of my own and Simon's blogger
app. I'm probably forgetting something. Ron posted some source to the list
and I'm assuming he is still experimenting with PythonCard. Is anyone else
playing with PythonCard?

Based on the current samples, is the current framework too complex or too
limiting or just right?

What elements need to be added to the current framework before you would use
PythonCard for your own work?

Is the most important thing having an environment like HyperCard?

Project Roles
The last update to the roles list was on July 12th, so it is out-of-date
http://aspn.activestate.com/ASPN/Mail/Message/676720
At this point, I'm doing most of the work on the framework and samples.
Patrick is working on PyCrust, which we use for our shell and namespace
viewer. Andy is still active, but not on the framework. Both Neil and Robin
answer questions, but otherwise are not currently involved in PythonCard
code. Rowland is not active either, though we owe a debt to him for the
original framework, ideas, etc. Rowland and I mostly chat about PythonCard
outside the list. Roman helped start the distutils work, but Andy took that
over. There have been a few people offering to get involved, but real life,
work, etc. has overridden most of the good intentions. There is a limited
amount we can accomplish without more developers. This will have an impact
on the scope of the project, so if you're interested in a particular area
please speak up.

Documentation
Suggestions for getting some docs done? Anything in particular you want in
terms of documentation?

The project name
Is everyone happy with the name PythonCard? I wouldn't bring this up except
that recently I learned a number of people had never even bothered to look
at PythonCard because of the implied similarity to HyperCard. There are a
lot of people out there that have never used a Mac and even if they have, a
lot of people never liked HyperCard and considered it a toy for building
apps. On the other hand, a lot of HyperCard users expect PythonCard to
provide a complete environment, so the name doesn't reflect so much what we
have today, but what we hope to achieve. It doesn't help that wxPython
doesn't run on the Mac yet.

Should we move beyond the prototype and make the next major release an alpha
version of the real framework?

How thin should the framework layer be over wxPython? That's a loaded
question. The implication is that we will only be able to achieve our goals
with wxPython instead of alternative GUI toolkits for Python. That may or
may not be true. What do we want to achieve with our framework sitting on
top of wxPython that wxPython doesn't provide?

What parts of the framework are most important to you? Some possibilities:
  Layout descriptions in resource files
  Automatic widget creation and event binding
  Dot notation for widgets and other framework items
  on_widget_event style handlers
  runtime tools such as the shell, message watcher, property editor

Are the samples useful?

What do you want PythonCard to be?

I definitely pushed PythonCard in the direction I thought it should go back
in July and I'm going to continue to pursue PythonCard in some form, but it
may be time to revise some of the original goals. I'll give other people a
chance to respond before stating some of my own preferences.

This is an open-ended post, so feel free to bring up any topic you think
relates to the current state of PythonCard or its future even if I didn't
touch on the topic above.

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

[Pythoncard-users] demand for more frequent releases?

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

There hasn't been a release in almost a month, mostly due to a trip that
took me away from development for about two weeks. Quite a few people seem
to be downloading from cvs, but if it will increase the feedback level on
the list I'll start making interim zip releases every night or two between
major releases to simplify getting the latest files.

If you don't have access to cvs and that is what is preventing you from
commenting on daily changes to the framework... just respond to this
message.

Thanks,

ka

[Pythoncard-users] font dialog fix, textEditor additions

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

I fixed a bug with the font dialog that was causing it to return an
incorrect family name.

I found this bug while adding a font dialog to the textEditor sample. I also
added a user.config.txt configuration file that is loaded and saved
automatically whenever the textEditor sample is used. It remembers the last
window position, size, and font. I added a simple About box that shows the
char, word, and line count. Finally, I added a simplistic Find.

I need a decent way of matching against whole words in the findNext method.
I guess I could resort to a regular expression, but perhaps there is a
better way? Suggestions anyone? I think there are some bugs related to
newlines in the text, but since I'm adding onto this sample pretty quickly I
haven't taken the time yet to do much bug checking.

ka

[Pythoncard-users] textEditor sample

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

A post by Thomas Heller on the wxPython-users list
http://aspn.activestate.com/ASPN/Mail/Message/wxPython-users/804764

got me thinking about simple text editors today (aka notepad). I really
haven't had time to digest all the document/view ideas in Thomas's post, but
I did take 45 minutes :-) to do a simple textEditor sample, which I've
checked into cvs.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/textEditor/
One difference from other samples is that I made the file extension .pyw
rather than .py in order to avoid the console window appearing when the
sample is launched. Do not use this sample to do any real editing, always
work on copies of files you want to edit. There are some comments at the
beginning of the file about possible enhancements.

I'll be adding dialogs and perhaps exploring document/view architectures
with this sample. My mind is totally unfocused right now as I try and juggle
turtles, bitmaps, sizers, modal dialogs, and model view controller ideas, so
I'll probably wait until tonight or tomorrow before committing any dialog
stuff to cvs. I was hoping to get some comments on the dialog posts
yesterday before adding the files.

ka

[Pythoncard-users] diaries and dynamic hypertext

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

Hey Simon,
I just found this
http://simon.kittle.info/diaryxml
on your site.

I haven't looked too closely, but diary stuff is another pet project of
mine. My first commercial failure was a Personal Information Manager (PIM)
called Organizer +. Anyway, the original SearchExplorer which I wrote in VB
and which the searchexplorer sample in PythonCard is based on had a nice
feature geared towards my diary usage. The idea is that if the text in the
search box contained 'word: ' before the search term, where 'word' is
associated with a given search site, then that search site would
automatically be associated with the search. For example, in my diary which
is freeform text I use Book: Movie: TV: Game:. If you have 'Movie: Memento',
then ultimately you're going to get a URL like
http://us.imdb.com/Tsearch?title=Memento

Part of the point of searchexplorer is that it is supposed to keep track of
these relations, so if you had a diary PythonCard app, it should invoke
searchexplorer to do its search. We don't have an app to app messaging
infrastructure, but a hack could be done for purposes of exploring the idea.
You probably saw my post on the xml-rpc list
http://groups.yahoo.com/group/xml-rpc/message/3718

An alternative is to put the searchexplorer smarts in the diary and then it
can launch the browser to display results. We'll eventually wrap the wxHTML
control in wxPython, but probably not until 2.3.2 is out. Most sites don't
support getting the data in XML format, so unless you're wanting to do a lot
of screen scraping it is easier to just display an HTML result and the
simplest way to that is via the browser right now.

It would be very easy to have a menu of sites for the major categories you
might use in a diary: Book, Movie, TV, Dictionary, Calendar, Addresses,
Games, generic search (Google), etc. When the menu item is selected, it
would take the currently selected text in the field and launch a browser
window similar to searchexplorer. I have something like this enabled in my
Internet Explorer (IE) browser, but it is invoked via a right-menu click on
text in the browser window and only works in IE.

These type of free form URLs don't have to be limited to searchable web
sites. The original SearchExplorer I did in VB also looked up contacts in
Outlook, but since PythonCard is cross-platform, I pulled that feature out
of the searchexplorer sample. We could define several different ways for
people to search contacts settable via a Preferences dialog (now that we can
do dialogs). Then if you selected say 'Kevin Altis' or 'Altis' or
'al...@se...' in the diary text and chose 'Contact' from the menu
it would jump to the appropriate contact or retrieve and display the info.
Another good item for free form hypertext is hooking up to a local file
search like the findFiles sample.

Anyway, just some ideas. I wouldn't mind working on a diary sample for
PythonCard. It is another good area to explore storage options,
import/export, text searching, and other issues we need to address.

Anyone else on the list interested in the topic of diaries and/or free form
hypertext?

In order to make the UI nicer I would really like to move to using the
wxTE_RICH text style for TextField and TextArea, which means requiring
wxPython 2.3.1 or later. I didn't make the change yet, because some people
are still using 2.3.0 for Boa. I will wait until 2.3.2 is released before
making the change. Once we're using wxTE_RICH we can mix font styles in a
single field.

ka

[Pythoncard-users] FW: PythonCard response to Chris Ryland

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

This may be of general interest for those relatively new to the PythonCard
project. Hopefully, I didn't say anything too stupid below, I'm in a rush to
get out the door and just typed and sent rather than double-checking first
:)

ka

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Monday, October 15, 2001 7:11 PM
To: Chris Ryland
Subject: RE: PythonCard


Yes, please check it out. Right now we have an app framework with various
runtime tools, but not a complete environment. The samples are typically
analagous to a single background, single card stack, but without transparent
data storage. We will have stacks (groupings of backgrounds) and cards
(records) of some form as we progress. However, there is no particular
reason you have to use that, so it can work like a "normal" app.

I can't give you a specific date on the Mac wxPython, but that is what we're
waiting on. wxMac (wxWindows) seems to be pretty far along, but Robin hasn't
committed to a wxPython port for the Mac other than Real Soon Now. Once we
have a Mac version, I'm sure various framework issues will pop up. One of
the biggest right now is that fixed layouts generally don't work well under
Linux, so we're investigating sizers.

There is a py2exe that can probably produce a standalone for Windows, but I
don't think anyone has tried. It does work for wxPython on its own. There is
another bundler that works for Linux, but not as well. I have no idea about
the Mac.

What we've discussed so far leans towards having a .zip bundle more like a
Java .jar/.war file, but no work has been done on that yet and it wouldn't
address your desire to have something that bundles Python/wxPython/etc. it
would only be for an individual PythonCard app.

wxDesigner is a bigger beast. There is also Boa. Both generate wx code,
wxPython would be your preferred output. PythonCard sits on top of wxPython,
so it requires different code, though you can mingle wxPython code inside a
PythonCard app, which is typically how new features are tested before being
made part of the framework. Numerous samples have wxPython code in them. The
only layout tool right now is the resourceEditor sample, which is very weak
since I've only spent a few days on it total.

However, you should still be able to do simple apps fairly quickly even with
the limited UI tools we have today. Lack of documenation is another issue.
For the most part you'll need to program by example, looking at the existing
samples, plus the spec.py and widget.py modules.

Please join the list and contribute ideas and criticisms.

ka

> -----Original Message-----
> From: Chris Ryland [mailto:cp...@em...]
> Sent: Monday, October 15, 2001 6:24 PM
> To: al...@se...
> Subject: PythonCard
>
>
> Very interesting. You're not going down the true Hypercard "stack" path,
> though are you? (I hope not.)
>
> Just how close is the Mac version? All hinging on wxWindows for Mac?
>
> And how hard would it be to produce a "frozen" executable with Python,
> PythonCard & all resources wrapped into one file for MacOS 8/9?
>
> I'm not looking for automatic code generation (though skeleton code
> generation is helpful where appropriate), just something that makes GUI
> design/development swift and accurate. (RealBasic does well here.)
>
> How does your stuff compare to wxDesigner, which looks fairly interesting?
>
> I guess there's not much more to do than just dive in and try to
> start using
> it all...
> --
> Cheers!
> Chris Ryland
> Em Software, Inc.
> www.emsoftware.com
>
>
>

[Pythoncard-users] dialog and window issues

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

Many of these thoughts aren't fully formed, but here goes...

1. Non-modal dialogs versus regular windows
I'm not sure what big differences there are between a non-modal dialog and a
regular window in an app from the standpoint of PythonCard. The Background
class in PythonCard already uses a wxPanel so tab traversal is handled
automatically and it is simple enough to support a default button, which I'm
already doing for the modal dialogs.

I'm inclined to create a variation on the Background class like I did for
the GenericDialog class and that will give us a generic window class that
can contain widgets. The difference will be that the windows will all be
children of the background they are created from and they won't appear
automatically when the app starts up, only in response to an invocation from
user code. Once we have some transparent data storage mechanism, they
probably won't inherit that capability either, though I could see reasons
for wanting to do that.

A better idea might be to add support for multiple backgrounds first, then
the non-modal and generic windows can simply be separate backgrounds and
we'll support multiple background windows as part of the basic UI. At some
point, Background, GenericDialog, and the other window-related classes will
need to be refactored, so the implementation is cleaner, but we're at the
prototype stage, so that's to be expected.

2. Dialog resource and source code organization
Where should the resource descriptions and classes for dialogs be stored? In
my current example, I'm storing the Find dialog resource in a separate file
'find.rsrc.py'. The FindDialog class is part of the main sample module just
like the Background subclass for the main app. There are a few alternative
possibilities.
A. Store all dialogs for an app in the main .rsrc.py file for the app. The
classes for the dialogs would be stored in the main app module.
B. Store the dialog resources in a separate dialog.rsrc.py for each app. The
classes for the dialogs would go into their own module which the main module
would import.
C. Store each dialog in its own file, possibly storing the class that goes
with the resource in the same file. Otherwise, store the code in its own
file as well.

There are probably some other variations with merit. The last option
probably appeals to me the most, where each dialog would have two files. For
example, the find code I posted earlier might have find.dialog.py and
find.dialog.rsrc.py. I think this might foster code reuse among apps the
most, particularly if we have a dialogs folder as part of the distribution
that is available to apps at runtime. The find dialog example would go into
that 'dialogs' folder. Other common dialogs would be added over time.

3. Validators
Modal modal dialogs often have an associated validator. If the user needs to
enter a particular value to dismiss the dialog then that can be done in the
default or cancel button handler. For example, if you wanted the user to
enter some text in order to do a Find, you might use:

    def on_btnFindNext_mouseClick(self, target, event):
        txt = self.components.fldFind.text
        # this test could be a separate validate method
        if not txt == ''
            event.skip()
        else:
           # present an error dialog or other message here
           ...

4. Editing dialog resources
The resourceEditor sample will not be able to create or edit the dialog
descriptions until the code is updated. In the meantime, a workaround will
be to edit a normal background and copy the components list to place into a
dialog description. I don't want to change the resourceEditor until we
decide on the storage format and organization for dialogs.

Please comment and add your own thoughts.

ka

[Pythoncard-users] modal dialogs for PythonCard

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

I am pleased to say that after some false starts yesterday and today, some
email exchanges with Robin, a bit of inspiration, and a generous donation to
the god of kludge, we are close to having generic modal dialogs in
PythonCard. I've included an example below.

The nice thing about the modal dialogs is that they work almost identically
to the Background class. They don't have a menubar or a background image,
but all of the widgets that we have now should work in the modal dialog and
the attribute and event handlers work identically.

Well not quite identically. Both the default button and the cancel buttons
need to call event.skip() and you have to add an id attribute to the
resource

I'm going to mull over this tonight before putting the code into cvs, but
I'll post when I do. I have some other issues I want to address on this
topic, but I have to run right now, so I'll post on those issues later as
well.

ka
---

class FindDialog(PythonCardPrototype.dialognew.GenericDialog):
    def __init__(self, aBg, searchText='', wholeWordsOnly=0,
caseSensitive=0) :
        # load the resource
        aDialogRsrc =
PythonCardPrototype.res.ResourceFile('find.rsrc.py').getResource()

        PythonCardPrototype.dialognew.GenericDialog.__init__(self, aBg,
aDialogRsrc)

        # if some special setup is necessary, do it here
        self.components.fldFind.text = searchText
        self.components.chkMatchWholeWordOnly.checked = wholeWordsOnly
        self.components.chkMatchCase.checked = caseSensitive

        print "init done"

    def on_btnFindNext_mouseClick(self, target, event):
        print "btnFindNext"
        print self.components.fldFind.text
        event.skip()

    def on_btnCancel_mouseClick(self, target, event):
        print "btnCancel"
        event.skip()

class Minimal(PythonCardPrototype.model.Background):

    def on_btnFind_mouseClick(self, target, event):
        dlg = FindDialog(self)
        dlg.showModal()
        print "fldFind", dlg.components.fldFind.text
        print "chkMatchWholeWordOnly",
dlg.components.chkMatchWholeWordOnly.checked
        print "chkMatchCase", dlg.components.chkMatchCase.checked
        print "FindDialog result:\naccepted: %s\nreturned: %s\n" %
(dlg.accepted(), dlg.returned())
        dlg.destroy()


---

{'type':'GenericDialog',
    #'file':'find.py',
    'classname':'Find',
    'name':'dlgFind',
    'title':'Find dialog',
    'position':(5, 5),
    'size':(370, 120),
    'components': [

{'type':'StaticText',
    'name':'stcFindWhat',
    'position':(7, 10),
    'text':'Find What:',
    },

{'type':'TextField',
    'name':'fldFind',
    'position':(70, 7),
    'size':(195, -1),
    },

{'type':'Button',
    'name':'btnFindNext',
    'position':(280, 5),
    'label':'Find Next',
    'id':5100,
    },

{'type':'Button',
    'name':'btnCancel',
    'position':(280, 35),
    'label':'Cancel',
    'id':5101,
    },

{'type':'CheckBox',
    'name':'chkMatchWholeWordOnly',
    'position':(7, 35),
    'label':'Match whole word only',
    },

{'type':'CheckBox',
    'name':'chkMatchCase',
    'position':(7, 55),
    'label':'Match case',
    },

] # end components
} # end GenericDialog

[Pythoncard-users] minimize window fix for BitmapCanvas

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

Thanks to Robin, I was able to fix a bug in BitmapCanvas. Previously, when a
window was minimized, the BitmapCanvas widget would receive a size event
with a (width, height) of (0, 0) so it promptly deleted the offscreen
bitmap, then when the window was restored the bitmap would be empty. I've
changed the code, so that the offscreen bitmap is not modified if the size
is (0, 0). The change is in cvs.

ka

RE: [Pythoncard-users] turtle sample migrating to use BitmapCanvas

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

The new turtle.py module and conversion of the turtle sample are now in cvs.
I did not change the name of the turtle sample, since PythonCardPrototype is
a package, there is not a name conflict as long as you are explicit with the
import statement. Here's the output in the shell from the new pycrustrc.py
file:

>>> from PythonCardPrototype.turtle import BitmapTurtle
>>> t = BitmapTurtle(bg.components.bufOff)

'bufOff' is a BitmapCanvas widget I added to the turtle.rsrc.py file. I had
to modify a number of scripts so that the window is explicitly refreshed
rather than always auto-refreshed to improve performance. I will be making
additional tweaks for performance as the BitmapTurtle and BitmapCanvas
classes continue to evolve. Suggestions on any aspect of the turtle are
welcome as always.

The turtle commands haven't changed, so you can still do stuff in the shell
like:
>>> t.st()
>>> t.color('blue')
>>> for i in range(6):
...     t.left(60)
...     t.fd(50)

Now that there is a turtle module, you can use a turtle anywhere you have a
BitmapCanvas and you can subclass the BitmapTurtle class if you want to
change or add functionality.

The big addition/change I still need to make is a wrapped wxPen class. I'll
post more info as changes are checked in.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, October 12, 2001 8:08 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] turtle sample migrating to use BitmapCanvas
>
>
> I'm in the process of converting the turtle sample to use the BitmapCanvas
> widget. I haven't checked the changes into cvs yet, but I expect
> to have the
> conversion done sometime this weekend. The reason I'm posting this message
> now rather than when I'm done is in case some people on the list are using
> the existing turtle sample and want to get their input in while
> I'm working
> on this.
>
> The big change is that there will be a new turtle module that contains an
> AbstractTurtle and BitmapTurtle class. The aTurtle.py and wxTurtle.py
> modules in the turtle sample directory will be removed.
>
> The BitmapTurtle uses a BitmapCanvas widget rather than directly
> drawing on
> a wxPython device context (DC). The drawing time is slower than
> before, but
> all the drawing is buffered, so the bitmap is no longer lost if the turtle
> window is obscured or minimized. In addition, Auto Refresh can be
> turned off
> to get a dramatic speed improvement, you just won't see the
> drawing until it
> is completed.
>
> You can still have any number of turtles you want, so the turtle is a good
> way of doing artificial life experiments. If you want to get fancy you can
> have multiple BitmapCanvas widgets in a window and multiple turtles per
> BitmapCanvas. The turtle(s) can still be driven from the shell. Once the
> change is complete I can start looking at expanding the coordinate system,
> so each turtle can have its own units of measurement, scale, etc. The end
> result should be a system that is very flexible and powerful.
>
> I will have to fix a few of the existing scripts to work with the
> new setup
> and this also gives me some incentive to get back to the
> BitmapCanvas widget
> and wrap up the wxPython wxPen and wxBrush, etc.
>
> I kept the AbstractTurtle class so that in the future we can still have a
> PostScriptTurtle or other varieties.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] turtle sample migrating to use BitmapCanvas

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

I'm in the process of converting the turtle sample to use the BitmapCanvas
widget. I haven't checked the changes into cvs yet, but I expect to have the
conversion done sometime this weekend. The reason I'm posting this message
now rather than when I'm done is in case some people on the list are using
the existing turtle sample and want to get their input in while I'm working
on this.

The big change is that there will be a new turtle module that contains an
AbstractTurtle and BitmapTurtle class. The aTurtle.py and wxTurtle.py
modules in the turtle sample directory will be removed.

The BitmapTurtle uses a BitmapCanvas widget rather than directly drawing on
a wxPython device context (DC). The drawing time is slower than before, but
all the drawing is buffered, so the bitmap is no longer lost if the turtle
window is obscured or minimized. In addition, Auto Refresh can be turned off
to get a dramatic speed improvement, you just won't see the drawing until it
is completed.

You can still have any number of turtles you want, so the turtle is a good
way of doing artificial life experiments. If you want to get fancy you can
have multiple BitmapCanvas widgets in a window and multiple turtles per
BitmapCanvas. The turtle(s) can still be driven from the shell. Once the
change is complete I can start looking at expanding the coordinate system,
so each turtle can have its own units of measurement, scale, etc. The end
result should be a system that is very flexible and powerful.

I will have to fix a few of the existing scripts to work with the new setup
and this also gives me some incentive to get back to the BitmapCanvas widget
and wrap up the wxPython wxPen and wxBrush, etc.

I kept the AbstractTurtle class so that in the future we can still have a
PostScriptTurtle or other varieties.

ka

[Pythoncard-users] weblog app

[Simon K. <si...@ki...>]

Hi everyone,

just to let you all know, I've got a working Manila weblog client
working somewhat.  it does the basic stuff, blogging, flipping a
homepage, download and uploading of OPML files.

one thing to note is that this is the first PythonCard program I've
written, but more importantly, the first Python program I've written :)
(first one thats over 15 lines long anyway).

So, if the code is non-pythonish, or very long when it could be short,
thats why.  I've mailed you all know so you can take a look if you want
and send me thoughts, ideas.

if there's something thats not done right, or not done the best way, I'd
love to hear the better way.

anyway, I've put up a small page here:

http://simon.kittle.info/stories/storyReader$97

it has one screenshot of what it currently looks like, and links to the
code.  (btw, the page is called "BlogMan", i know its a bit lame, but
its only a temporary name, had to call it something).

thanks and cya

Simon

[Pythoncard-users] FW: scipy

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

I discovered SciPy http://www.scipy.org/ two days ago. Originally, I was
interested in graphic format conversions, such as numerical arrays (NumPy)
that we might need to support in PythonCard similar to the support I added
for PIL. I still need more feedback on what should be put in the PythonCard
framework for PIL and NumPy.

Meanwhile, I've been in contact with Eric Jones of the SciPy team and have
installed SciPy and run through the tutorials at:
http://www.scipy.org/site_content/tutorials/plot_tutorial

Since the plt module of SciPy is based on wxPython you can drive plt from
the PythonCard shell (PyCrust) without needing the line:

   >>> import gui_thread

gnuplot also seems to work fine, but I didn't use it for very long so there
may be some window manager conflicts between gnuplot and wxPython. As a
simple exercise I modified minimal.py to simplify data input, a screen shot
is attached. This will probably be expanded and become another sample for
PythonCard; the sample will require SciPy which includes/requires NumPy. The
short story is that PythonCard and SciPy seem like a good match. The
question becomes what level of integration and overlap should we have
between the two projects.

I don't know much about the requirements for "scientific computing" so right
now I'm at the stage of asking newbie questions about what scientific users
need in a GUI framework and environment. I thought Eric's response below was
worth forwarding to the list in case other people have suggestions on how
PythonCard can be a useful tool in science.

If you're on the PythonCard list are interested in this topic, please speak
up.

ka

-----Original Message-----
From: eric jones [mailto:er...@en...]
Sent: Thursday, October 11, 2001 10:53 AM
To: Kevin Altis
Subject: Re: some other questions on scipy


> I noticed SciGraphica today on the SF Python list.
> http://sourceforge.net/projects/scigraphica/
>
> It only works on Linux, but I guess this is a "competitor" of sorts?

Not really a competitor -- SciPy has a huge amount of Numerical calculation
stuff that is orthogonal to SciGraphica's effort.  They are really about
making it easy to build pretty plots.  I'm very in that project as they look
to have taken the graphics a very long way.  Further, they are planning on
breaking things out to make them accesible from Python command line in the
next version which means they can be used right along with SciPy.

The big problem with SciGraphica is its based on GTK.  GTK looks bad on
Windows, isn't easy to install, and isn't stable.  Windows is a major
platform and SciPy has to support it as well as, or even better than Linux,
to be viable.  After all, Linux people are used to fiddling with things to
get them to work.  Windows people aren't.  That means GTK isn't a viable
option in my view.

On the other hand, I have wondered how hard it is to switch this general
framework over to wxPython or even try to set it up so it is backend
independent.  I have been talking with the guys at the Space Telescope
Institute (they run Hubble), and they are also very interested in graphics
stuff.  We have pitched around this idea quite a bit in the last few weeks,
but haven't formalized a set of specs or a game plan yet with regards to
this.

We are also looking hard at using VTK (www.kitware.com) for all 3D stuff.
There are benefits and drawbacks to this that are still under consideration.

> What are other comparable packages, anything driven by Python or that
Python
> interfaces to? I'm just trying to understand the bounds of the problem
that
> needs to be addressed.

I don't think SciPy really has a competitor.  The Scientific Python project
by Konrad Hinsen is similar, but is slightly more focused on computational
chemistry.  The most similar package to
SciPy would be Matlab (or Octave in the Open Source version).  National
Instruments has a less used one called HiQ.  There is also IDL, Mathematica,
Maple, etc. which serve a similar purpose.  The general goal of SciPy is to
make python a viable alternative to these tools and then leverage the power
of Python to take it beyond them.  If you have access to Matlab, you might
try it out.  Octave is less useful, but still a reasonable thing to look at.
I've also heard of a language called R that is OS that might serve similar
purposes.

So SciPy proper I guess focuses on two things: scientific libraries and
visualizing data.  We want to make it easy to do scientific stuff in Python
as well as make sure that the tools or algorithms/scripts developed with
SciPy can be dropped into larger apps with minimal fuss.  Things like turtle
might  actually have a place in the visualization section.  The GUI building
end, at least right now, is stuff we'd like to borrow from you guys that
know what is going on in that arena of Python.  Later, we might have a full
blown GUI with all this stuff available together though.  I'm very glad your
playing with SciPy because combining SciPy with PythonCard is *exactly* what
is so powerful about building it in Python -- and I'm counting on you et al.
to think of things we never had. :)

> I can't do the sample with !NewAxis:

This is a mistake.  Thanks for finding it.  Where is it and I'll fix it.

see ya,
eric

[Pythoncard-users] outliner/blogging app using PythonCard

[Simon K. <si...@ki...>]

hi all,

Just thought i'd post a quick message clarifying the status of the app.
Dave's post (forwarded here) was a little misleading,  I didn't 
set out to create an full blown outliner for Linux, rather, a way to 
connect the outliners out there that work on Linux to Manila.  
I hope that was clear from the page on my site.

The app as it is now:  Its really pretty simple, based on PyManila, the
app can currently: flip a manila homepage, blog text to the homepage,
list stories on a site, and download selected story to an OPML file
(this is the thing I really wanted).

Obviously the download/upload'ing of files to the server doesn't apply
to blog services like Blogger, but it would certainly be possible to
incorporate Blogger support and just hide details of the Manila support
to create a generic blog app.

Presumably things like Zope could be supported too, I've never really
investigated Zope but I'm sure its possible.


Anyway, I hadn't planned on creating an Ouliner itself, just a way of
connecting/converting outline documents used on Linux to Manila.  From
there though, the obvious step is to create a more generic weblog client
that can be used with other CMS's.


- Simon

RE: [Pythoncard-users] FW: [opml-dev] Simon Kittle's work

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

For grins, try the following in the shell:

>>> import Zope
>>> app = Zope.app()
>>> app.__doc__
'Top-level system object'
>>>

Then drill around in the namespace viewer. (Zope objects actually have an
overwhelming number of methods.) You'll need the version of PyCrust from CVS
to get the full effect, as I've recently enhanced the introspection of Zope
and ZODB objects.

---
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: Wednesday, October 10, 2001 5:05 PM
To: pythoncard-Users
Cc: si...@ki...
Subject: RE: [Pythoncard-users] FW: [opml-dev] Simon Kittle's work

<snip>

It sounds like a lot of the management for a blogger site like Manila will
be taken care of by his app. It may also be a good excuse to make a wrapped
version of the wxTreeCtrl for use in PythonCard. I'm hoping that this is the
first hint at how we might do interesting things between PythonCard and Zope
as well.

ka

RE: [Pythoncard-users] FW: [opml-dev] Simon Kittle's work

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

I've been in touch with Simon, in fact I think that's what got him started
doing this in PythonCard.

A digression...
I contacted him after finding out about pyManila
http://sourceforge.net/projects/pymanila. Unfortunately, the pyManila
author, Mark Pilgrim - same guy that does diveintoptyhon
http://diveintopython.org/index.html - just got fired, so I don't know the
schedule for future pyManila updates and docs. If you want to read more on
Mark's life, why he says he got fired, etc. check out
http://diveintomark.weblogger.com/ It is an interesting read.

Hopefully, Simon will chime in on the list soon (he's subscribed, but in
digest mode). I'll let him decide whether to forward any of our off-list
discussions. Based on what he's already done his app should be a great
sample to include in the distribution.

It sounds like a lot of the management for a blogger site like Manila will
be taken care of by his app. It may also be a good excuse to make a wrapped
version of the wxTreeCtrl for use in PythonCard. I'm hoping that this is the
first hint at how we might do interesting things between PythonCard and Zope
as well.

ka
ps. Must remember to always hit Reply to All, argh!

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Wednesday, October 10, 2001 2:10 PM
> To: Pythoncard
> Cc: da...@us...
> Subject: [Pythoncard-users] FW: [opml-dev] Simon Kittle's work
>
>
> I took a look at the project mentioned below because of a
> lingering interest
> I have in outliners and the thought that one day I might create one. It
> turns out that this guy is using PythonCard to create his app. So
> I figured
> I would forward it here to see if anyone might want to help him. I'm too
> busy at the moment, myself.
>
> ---
> Patrick K. O'Brien
> Orbtech (http://www.orbtech.com)
> "I am, therefore I think."
>
> -----Original Message-----
> From: Dave Winer [mailto:da...@us...]
> Sent: Wednesday, October 10, 2001 3:18 PM
> To: opm...@ya...
> Cc: xm...@ya...
> Subject: [opml-dev] Simon Kittle's work
>
> He's bravely putting together an outliner for Manila on Linux.
>
> http://simon.kittle.info/stories/storyReader$55
>
> This is wonderful. It's a good vision, but he's struggling with
> some of the
> XML-RPC and it would be great if a Linux outliner would directly support
> OPML.
>
> If you can help Simon, please do.
>
> Dave
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] FW: [opml-dev] Simon Kittle's work

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

I took a look at the project mentioned below because of a lingering interest
I have in outliners and the thought that one day I might create one. It
turns out that this guy is using PythonCard to create his app. So I figured
I would forward it here to see if anyone might want to help him. I'm too
busy at the moment, myself.

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

-----Original Message-----
From: Dave Winer [mailto:da...@us...]
Sent: Wednesday, October 10, 2001 3:18 PM
To: opm...@ya...
Cc: xm...@ya...
Subject: [opml-dev] Simon Kittle's work

He's bravely putting together an outliner for Manila on Linux.

http://simon.kittle.info/stories/storyReader$55

This is wonderful. It's a good vision, but he's struggling with some of the
XML-RPC and it would be great if a Linux outliner would directly support
OPML.

If you can help Simon, please do.

Dave

[Pythoncard-users] added loadFile and saveFile methods to Bitmap

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

The Bitmap class in graphic.py now has loadFile and saveFile methods. I also
added file type support for some formats I had overlooked earlier.

Supported extensions/formats:
  BMP, GIF, JPG/JPEG, PCX, PNG, PNM, TIF/TIFF, XBM, and XPM.

You can specify an empty filename ('') for loadFile if you just want to
create an empty Bitmap; you should specify a size when creating an empty
bitmap. Empty bitmaps via the Image class, are used in the
SourceForgeTracker example to provide colored rectangles behind widgets. If
a filename is not specified for saveFile, then the filename that was used to
initialize the Bitmap will be used instead.

You can't save in GIF format due to licensing restrictions. XBM format
didn't work for me under Windows, but I have a question into Robin to make
sure it isn't a bug. You can't always trust the wxWindows documentation on
these issues.

There is currently no way to specify the bitmap depth, palette, or do any
image manipulation such as scaling and rotation or even get information such
as the color value of a given pixel. Internally, the Bitmap class uses a
wxBitmap. wxPython uses a separate image class wxImage for image
manipulation. We could wrap up some or all of the image manipuation routines
inside Bitmap and then hide the necessary conversion to/from wxImage. If
we're not worried about memory usage, we could keep a duplicate of the
wxBitmap as a wxImage to reduce the delay for some routines. Other
suggestions?

Remember that last month I added the getPILBits and setPILBits methods, so
you can always do image manipulation with PIL if you want.

Initially, the Bitmap class was created for the use of the Image and
ImageButton classes and it was geared towards always loading a bitmap from a
file. Given that the Bitmap class is now being used for images that don't
come from a file the design may need to be tweaked to be more flexible, yet
still simple to use. Please respond to the list with suggestions for what
you want to see in the Bitmap class.

ka

RE: [Pythoncard-users] keyDown, keyUp, and keyPress events

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

I've updated dispatch.py, event.py and wxPython_binding.py so that the
framework can tell if an Event was handled by user code. This means that if
you have a keyPress handler (none of the current samples use one) then you
must call event.skip() at the end of your handler or the character pressed
will not actually show up in the field. For example:

    def on_field1_keyPress(self, target, event):
        print 'field1_keyPressed'
        nEvent = event.getNativeEvent()
        print nEvent.GetKeyCode()
        event.skip()

Now that this change is in place, I'll start wrapping key code and modifier
keys, so we don't have to access the native wxPython event. I'm going to
check with Robin on the proper way to modify events or deal with
"intercepted" events for code where you want to change the behavior of a key
press such as automatically converting letters typed to uppercase.

Note that the current implementation is not equivalent to 'pass' in
HyperCard. Once other event issues are worked out, skip() may go away in
favor of calling a 'pass' equivalent that simply sends the message up the
hierarchy.

If you have no idea what I'm talking about, don't worry about it, since the
current change doesn't really break any current samples, you can ignore it
for now.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, October 06, 2001 1:06 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] keyDown, keyUp, and keyPress events
>
>
> Based on a recent discussion on the wx-dev mailing list, the
> addition of the
> key handlers may cause a problem under wxGTK. There may be
> additional issues
> with differences in key codes generated. Please report any issues you find
> to the list.
>
> The key events which were defined back in July and added to spec.py, never
> got added to the TextField, PasswordField, and TextArea class event
> bindings. There was a problem with passing the event on (wxPython
> Event.Skip()) if the user code didn't process the event. Anyway, I want to
> finally solve the issue, so I've checked in changes to:
>   event.py, widget.py, and wxPython_binding.py
>
> There will probably be a change to dispatch.py as well. The
> current changes
> don't do much except allow the user code to handle the event and
> display the
> event in the Message Watcher. I still need to add support for not
> passing on
> the keyPress event, which will be necessary to limit the valid keystrokes
> for a field. For example, if you only wanted a user to enter numbers you
> would define a on_fieldName_keyPress handler that only called skip() when
> the key code was 0 through 9.
>
> The order of events:
>   keyDown, keyPress, textUpdate, keyUp
>
> Adding these events exposed some problems with the handling of
> tabs and the
> return/enter key which I also need to investigate. However, it doesn't
> appear that any of the samples have been broken by adding the key
> events. As
> an example of handling each event, the following code could be added to
> minimal.py:
>
>     def on_field1_keyDown(self, target, event):
>         print 'field1_keyDown'
>
>     def on_field1_keyPress(self, target, event):
>         print 'field1_keyPressed'
>         #event.skip()
>
>     def on_field1_keyUp(self, target, event):
>         print 'field1_keyUp'
>
> Note that the 'event.skip()' line commented out above will need to be
> uncommented in the future or the keyPress handler above would keep the
> characters from showing up in the field as user typed them.
>
> In order to do anything with the event right now you need to get
> the native
> wxPython event and then use wxPython methods.
>
>     def on_field1_keyPress(self, target, event):
>         print 'field1_keyPressed'
>         nEvent = event.getNativeEvent()
>         print nEvent.GetKeyCode()
>         #event.skip()
>
> See wxKeyEvent and the Keycodes topics in the wxWindows/wxPython
> documentation for more info; I've included the Keycodes topic below. We'll
> have to define our own method wrappers and keycode constants in order to
> duplicate the wxPython functionality.
>
> I am thinking about just duplicating the codes below, but using a KEY_
> prefix instead of WXK_ prefix; the constants will be put in a separate
> module file to make it easy to reference them. I'll need some suggestions
> for whether we need to do anything specific for supporting Unicode or
> keyboards outside the USA generating different 8-bit ASCII key codes
> (Russian, Swedish, etc.)
>
> It would be helpful to have some suggestions for a sample or two that need
> to do key processing to get a better idea of the functionality we need to
> support.
>
> ka
> ---
>
> Keycodes
> Keypresses are represented by an enumerated type, wxKeyCode. The possible
> values are the ASCII character codes, plus the following:
>
>
>  WXK_BACK    = 8
>  WXK_TAB     = 9
>  WXK_RETURN  = 13
>  WXK_ESCAPE  = 27
>  WXK_SPACE   = 32
>  WXK_DELETE  = 127
>
>  WXK_START   = 300
>  WXK_LBUTTON
>  WXK_RBUTTON
>  WXK_CANCEL
>  WXK_MBUTTON
>  WXK_CLEAR
>  WXK_SHIFT
>  WXK_CONTROL
>  WXK_MENU
>  WXK_PAUSE
>  WXK_CAPITAL
>  WXK_PRIOR
>  WXK_NEXT
>  WXK_END
>  WXK_HOME
>  WXK_LEFT
>  WXK_UP
>  WXK_RIGHT
>  WXK_DOWN
>  WXK_SELECT
>  WXK_PRINT
>  WXK_EXECUTE
>  WXK_SNAPSHOT
>  WXK_INSERT
>  WXK_HELP
>  WXK_NUMPAD0
>  WXK_NUMPAD1
>  WXK_NUMPAD2
>  WXK_NUMPAD3
>  WXK_NUMPAD4
>  WXK_NUMPAD5
>  WXK_NUMPAD6
>  WXK_NUMPAD7
>  WXK_NUMPAD8
>  WXK_NUMPAD9
>  WXK_MULTIPLY
>  WXK_ADD
>  WXK_SEPARATOR
>  WXK_SUBTRACT
>  WXK_DECIMAL
>  WXK_DIVIDE
>  WXK_F1
>  WXK_F2
>  WXK_F3
>  WXK_F4
>  WXK_F5
>  WXK_F6
>  WXK_F7
>  WXK_F8
>  WXK_F9
>  WXK_F10
>  WXK_F11
>  WXK_F12
>  WXK_F13
>  WXK_F14
>  WXK_F15
>  WXK_F16
>  WXK_F17
>  WXK_F18
>  WXK_F19
>  WXK_F20
>  WXK_F21
>  WXK_F22
>  WXK_F23
>  WXK_F24
>  WXK_NUMLOCK
>  WXK_SCROLL
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] reply-to munging, you must use Reply to All when responding to messages

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

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


> http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1
>
> Apparently, SourceForge changed the rules once again while I was away. I
> find this very annoying, but there isn't anything I can do about it. I
guess
> you get what you pay for.

I've been ranting about this on the anygui list too... I readlly don't
understand their justification for not leaving this up to each list
(or to each user, for that matter -- whether or not they want to receive
their mail with a reply-to header.)

> So, if you've been hitting 'Reply' rather than 'Reply to All' to respond
to
> a list message and find that you didn't get a copy back from list, then
now
> you know why.
>
> They also added a default in Mailman to allow non-members to post to the
> list, but I turned that off.

They said they'll add a filter later so that you can choose not to receive
two copies if someone else does a "reply to all" without editing the
list of receivers. It sounds like a hack to me, but at least if everyone
starts using "reply to all" and sets this option, it's close to the
"reply-to" functionality, at least.

> 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

[Pythoncard-users] reply-to munging, you must use Reply to All when responding to messages

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

http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1

Apparently, SourceForge changed the rules once again while I was away. I
find this very annoying, but there isn't anything I can do about it. I guess
you get what you pay for.

So, if you've been hitting 'Reply' rather than 'Reply to All' to respond to
a list message and find that you didn't get a copy back from list, then now
you know why.

They also added a default in Mailman to allow non-members to post to the
list, but I turned that off.

ka

RE: [Pythoncard-users] Find dialog layout and issues

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

I added the modal FindDialog to dialog.py and updated the dialogs sample to
demonstrate the dialog usage. I also added FindDialog to the addresses
sample, but haven't implemented the find logic for it yet, it just shows the
dialog when you click on the Find button.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, October 08, 2001 11:36 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] Find dialog layout and issues
>
>
> I've put together a basic Find dialog layout. The resource description is
> shown below and also attached as a file that you can view using the
> resourceEditor sample. The final layout will probably be done
> with sizers if
> possible in order to avoid display problems under Linux and Solaris.
>
> I'm thinking about implementing this as a modal dialog and making
> it part of
> the dialog.py module. So, usage would be something like:
>
>     dlg = FindDialog(self, 'text to find', 0, 0)
>     if dlg.accepted():
>         ...
>
> The last arguments would be for matching whole words only and
> matching case
> and would default to 0 (false).
>
> Should the dialog have an up/down direction searching option?
>
> wxPython appears to be unable to display the selection in a field if the
> window and field don't have focus, so I don't see any way of
> doing a normal
> non-modal Find dialog at this time, since there would be no
> feedback to the
> user that the selection has changed. I consider this a big limitation, so
> I'll be lobbying over on wx-dev to have this fixed in wxWindows, so
> eventually wxPython will work correctly.
>
> Another issue is that if the dialog is made non-modal, then it would be
> necessary to create the Find dialog in one method of the user code and
> provide a method callback as part of the dialog argument list to
> be executed
> when the user presses the Find Next button. An alternative
> solution would be
> to let the Find dialog call framework find classes directly once they are
> implemented.
>
> Anyway, this is just a heads up for anyone interested in this part of the
> framework. If you have some suggestions for the layout, how the dialog
> should work, or anything else related to doing text searching in the
> framework, let me know.
>
> ka
> ---
>
> {'stack':{'type':'Stack',
>           'name':'Find',
>           'title':'Find dialog',
>           'position':(5, 5),
>           'size':(370, 120),
>
>     'backgrounds': [
>     {'type':'Background',
>          'file':'find.py',
>          'classname':'Find',
>          'name':'bgFind',
>          'components': [
>
> {'type':'StaticText',
>     'name':'stcFindWhat',
>     'position':(7, 10),
>     'text':'Find What:',
>     },
>
> {'type':'TextField',
>     'name':'fldFind',
>     'position':(70, 7),
>     'size':(195, -1),
>     },
>
> {'type':'Button',
>     'name':'btnFindNext',
>     'position':(280, 5),
>     'label':'Find Next',
>     },
>
> {'type':'Button',
>     'name':'btnCancel',
>     'position':(280, 35),
>     'label':'Cancel',
>     },
>
> {'type':'CheckBox',
>     'name':'chkMatchWholeWordOnly',
>     'position':(7, 35),
>     'label':'Match whole word only',
>     },
>
> {'type':'CheckBox',
>     'name':'chkMatchCase',
>     'position':(7, 55),
>     'label':'Match case',
>     },
>
> ] # end components
> } # end background
> ] # end backgrounds
> } }
>

[Pythoncard-users] Find dialog layout and issues

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

I've put together a basic Find dialog layout. The resource description is
shown below and also attached as a file that you can view using the
resourceEditor sample. The final layout will probably be done with sizers if
possible in order to avoid display problems under Linux and Solaris.

I'm thinking about implementing this as a modal dialog and making it part of
the dialog.py module. So, usage would be something like:

    dlg = FindDialog(self, 'text to find', 0, 0)
    if dlg.accepted():
        ...

The last arguments would be for matching whole words only and matching case
and would default to 0 (false).

Should the dialog have an up/down direction searching option?

wxPython appears to be unable to display the selection in a field if the
window and field don't have focus, so I don't see any way of doing a normal
non-modal Find dialog at this time, since there would be no feedback to the
user that the selection has changed. I consider this a big limitation, so
I'll be lobbying over on wx-dev to have this fixed in wxWindows, so
eventually wxPython will work correctly.

Another issue is that if the dialog is made non-modal, then it would be
necessary to create the Find dialog in one method of the user code and
provide a method callback as part of the dialog argument list to be executed
when the user presses the Find Next button. An alternative solution would be
to let the Find dialog call framework find classes directly once they are
implemented.

Anyway, this is just a heads up for anyone interested in this part of the
framework. If you have some suggestions for the layout, how the dialog
should work, or anything else related to doing text searching in the
framework, let me know.

ka
---

{'stack':{'type':'Stack',
          'name':'Find',
          'title':'Find dialog',
          'position':(5, 5),
          'size':(370, 120),

    'backgrounds': [
    {'type':'Background',
         'file':'find.py',
         'classname':'Find',
         'name':'bgFind',
         'components': [

{'type':'StaticText',
    'name':'stcFindWhat',
    'position':(7, 10),
    'text':'Find What:',
    },

{'type':'TextField',
    'name':'fldFind',
    'position':(70, 7),
    'size':(195, -1),
    },

{'type':'Button',
    'name':'btnFindNext',
    'position':(280, 5),
    'label':'Find Next',
    },

{'type':'Button',
    'name':'btnCancel',
    'position':(280, 35),
    'label':'Cancel',
    },

{'type':'CheckBox',
    'name':'chkMatchWholeWordOnly',
    'position':(7, 35),
    'label':'Match whole word only',
    },

{'type':'CheckBox',
    'name':'chkMatchCase',
    'position':(7, 55),
    'label':'Match case',
    },

] # end components
} # end background
] # end backgrounds
} }