pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] wrapping wx.Notebook

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

At 11:04 14/09/2004 -0700, Kevin Altis wrote:

>There didn't seem to be any major objections, so I went ahead and checked 
>in the Notebook component, the necessary changes to the framework, and a 
>testNotebook sample. The changes should show up on anonymous cvs later 
>this afternoon. See my other comments below.

Not sure if it's better to cc the whole list on these messages while I 
stumble around trying the Notebook component or not - might save others 
repeating the same sequence, so I'll do that for now, and take it off-list 
if this goes on too long.

Aim - build a program that uses a tabbed notebook to display multiple csv 
files; each time you do File/Open, it creates a new tab and displays the 
file in it.

First, I built a very simple csv-viewer program (one component, a 
multicolumn list), and only filled in the FIle/Open handler, to get a file 
name, then call on_openFile to read in the csv file and display it.

Then I changed that from a stand-alone program to make it ready for 
inclusion in a notebook (i.e. I changed it from model.Background to 
model.PageBackground).

Then I built another very simple app (one component - a notebook), but 
didn't put anything into the notebook in on_initialize; and I made its 
on_openFile do the following :

         win = model.childWindow(self.components.myNotebook, csv_page.csvPage)
         self.components.myNotebook.AddPage(win, pageName, True)
         win.openFile(path)

i.e. create the window, add it to the notebook, then invoke the openFile 
handler, passing in the filename to read .....

It kind of works - it displays the data from the csv file in a 
multicolumnlist inside the notebook; and if I open another file, it opens a 
new tab, and displays it.

BUT there is a problem - I get errors because some variables within the 
csvPage don't exist.
Adding some debug "print"s, I found that the on_openfile seems to be called 
before the on_initialize.
It looks as though the on_initialize is being called later (maybe from 
wxMainLoop)

Does that make any sense ?
Or should I go back and look for other causes for why things seem to be 
called in the "wrong" order ?

-- Alex.

[Pythoncard-users] Re: generic container model

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

Sigh, I just can't seem to make a short post...

On Sep 13, 2004, at 1:47 PM, Donnal Walter wrote:

> Kevin Altis" <al...@se...>
>> There is no built-in support for the wx.Notebook class
>> right now, which is what you would use to do a real tabbed
>> interface. This is mostly due to PythonCard having a "flat"
>> layout model rather than supporting a generic container
>> model ...
>
> <delurking>
> Aha! A critical insight. If I understand correctly this "flat"
> model also explains (at least in part) why sizers are problematic
> to implement in the framework. Ideally, each container should have
> a built-in sizer to which components are automatically added as
> they are added to the container. The kind of sizer should be
> determined by the container, and the parameters for each component
> should be passed like 'size' and 'pos' are now. (Another useful
> parameter for each component would be a data model from some kind
> of abstraction layer.)

No, sizers are an orthogonal issue. You can stick sizers into a layout 
once the components are created or you can create and embed the 
controls as each sizer is created. Regardless, the default tab order 
and overlap of the controls is dependent on the order the controls are 
created and has nothing to do with the sizers. This may not be apparent 
when editing XRC files, using wxDesigner, wxGlade, etc. but that is how 
it works. Sizers do not inherit from wx.Window, they are a way of 
controlling layouts.

As many of the PythonCard samples and tools show it is very simple to 
use "raw" wxPython sizer code in a PythonCard program, it looks and 
behaves exactly like it would in a plain wxPython program. What 
PythonCard doesn't support is specifying sizers in the resource file 
nor does it provide any UI tools in the resourceEditor for controlling 
the layout with sizers. It would be relatively easy to support sizer 
descriptions in the resource file, it would just be another nested list 
attribute that would make references to the components list.

However, the bigger problem is doing the layout tool that uses sizers, 
but remains as easy to use as a direct manipulation paradigm, which is 
what the resourceEditor does now. I don't know how to make a layout 
tool based on sizers that is easy to grasp, certainly XRCed, 
wxDesigner, and wxGlade, while very nice tools don't seem simple to 
make and modify layouts, at least to me. wxGlade is probably the best, 
but it seems quite daunting, especially to newbies. Other opinions?

The "flat" model I was referring to has more to do with all the bits of 
wxPython that are being hidden in order to make PythonCard programs 
simple. For example, the Background which is what all programs use is a 
wx.Frame that contains a wx.Panel with an optional menu bar and status 
bar. There is only one set of components (wxPython controls) on the 
panel which is always accessed via the self.components list from the 
Background.

The advantage of this is that there is a whole lot of wxPython code 
that you don't have to put in your program, and probably more 
importantly over time, all PythonCard program source code looks the 
same. This is the same sort of reasoning which led to standardizing the 
event names and auto-binding events so programs wouldn't have a whole 
lot of event binding cruft in the initialization as well as completely 
different names for all the events which just makes reading other 
peoples code that much more difficult. It is also why the layout is 
kept separate from the program logic/source.

You don't have to figure out the object hierarchy doing a whole bunch 
of GetChildren() or GetParent() iterations. The background always has 
the same interface and behaves the same way, so Backgrounds can be 
reused as child windows or now, with the addition of the PageBackground 
class as pages in a Notebook. My hope is that this really is simpler 
for people to grasp and we aren't just being different to be different.

There is also the issue of not having the concept of a compound 
component which could be made up of one or more other components. 
Rowland has done some work in that area, but it still hasn't made it 
into the main cvs branch because we needed to make some fundamental 
changes to how resources and components are loaded as well as how 
events are handled. Now that I've created the PageBackground class I 
can see where we might actually be able to use a variation on that 
which would act as a nice building block.

>> ... where you could have a different layout in each notebook
>> tab/page. This has been discussed a number of times on the
>> mailing list and is obviously a big missing feature, but I
>> don't really know how to support it correctly. There was one
>> attempt to incorporate this into the framework and
>> resourceEditor, but it was never incorporated into the main
>> cvs code or updated for release 0.8.
>>
>> It is probably time for a separate discussion thread on the
>> issues and possible solutions such as treating each page as
>> a type of child window where only the components of the child
>> window resource are used. I'm just brainstorming here. ...
>
> Brainstorming further, I would suggest that for PythonCard *2.0* a
> class-based rather than an instance-based framework be considered.
> Each container would be defined as a *class* (with an appropriate
> resource-file notation, something other than a dictionary), such
> that multiple instances could be created if so desired. In either
> case, however, as the class is instantiated (initialized) the
> parent-child relationships are established as well as sizer
> relationships.
>
>> ... You would end up with a separate source and resource file
>> for each tab/page. I guess the references to each tab layout
>> would end up being something like
>> self.components.notebook[0].components.field1, etc. where
>> each page (window) of the notebook is referenced via a list.
>
> In a class-based framework, the top-level resource file would
> import component resource files as they are needed. Just a thought.
> </delurking>
>
I don't know what PythonCard 2.0 will look like, we'll have to wait 
until 1.0 is done and see just how far users take it in 1.x releases 
without tampering with the API... I'm pretty sure people will surprise 
us with what they are able to do, even with a framework and tools that 
are more limited than just using wxPython. What I do know is that if I 
still end up being the primary driving force for how PythonCard works 
then my tendency will be to keep it simple. There are many other tools 
for using wxPython, so it seems like a bad move to make PythonCard 
complicated and lose whatever small audience it may already address.

Certainly, some parts of PythonCard can be extracted from the framework 
such that they could be used in any wxPython program, but it isn't 
clear that the general wxPython-user base really wants that.

I still think a lot of your ideas for data driven applications are good 
but probably more appropriate for frameworks people might come up with 
on the wxPython-users or monty mailing list. However, I still like to 
get this kind of feedback because after three years of working on 
PythonCard it is very easy for me to have a very restricted view and 
completely miss the right answer. For example, it has been great 
exchanging ideas and code with Alex because he still has a fresh 
viewpoint and isn't bogged down with the idea baggage I'm carrying 
around. He already came up with two or three improvements to Notebook 
that I hadn't thought of, but after seeing them, they seemed obvious, 
which is what the right answer looks like ;-).

So, the more feedback pro or con the better!

Does any of this make any sense?

ka

Re: [Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions

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

On Sep 13, 2004, at 3:08 PM, normanwinn wrote:

> Kevin Altis asked:
>
>> In particular, I would like to hear about features that products like 
>> FileMaker Pro provide that are needed for an OS tool that users could 
>> transition to without feeling like they are taking a step backwards.
>>
> I'd like to start more positively. My major client would forgive a 
> great deal if he got more speed. And I'm pretty sure he will get it if 
> I go down this, the Python/PythonCard, road. I start with this comment 
> as much of what Filemaker does is probably not worth reproducing 
> providing the user experience in the new environment is perceived as 
> positive.
>
> Filemaker 7 has just come out and it is much slower than version 6. On 
> moving to OS X we already took a speed hit so, in the four years I 
> have been working on this thing, instead of hardware improvements 
> making things slick it has all got slower. On top of this, FM7 
> requires relearning much of what one has done + obliges a rewrite. 
> Hence the reason my search is on.
>
>
<snip>

I just went to say, wow, that was an awesome breakdown of FileMaker 
issues. Building a complete replacement is certainly no easy task, but 
from what I've seen lately such as the Slashdot discussion below, the 
demand for an Open Source replacement is certainly there.

http://slashdot.org/article.pl?sid=04/08/31/0121250

And in case I forgot to mention it before, check out the PyFileMaker 
module.

http://www.yellowduck.be/filemaker/

I look forward to seeing more PythonCard apps and samples that address 
the DB problem space.

ka

Re: [Pythoncard-users] Re: Pythoncard-users digest, Vol 1 #797 - 7 msgs

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

On Sep 13, 2004, at 8:03 PM, jamesr wrote:

> To adress the questions on the mailing list, i have already developed
> what i call the 'AdvancedEventFramework' that allows for tabbed
> interfaces, as well as the dynamic growing and shrinking of windows to
> accomodate them, if needed. I have myself and possibly a friend
> helping. It makes the creation of larger pycard program very painless,
> and i would like it to be considered as a contribution to the project.
> Since the capabilities it offers are extremely flexible (i have
> already begun development of a 'visual python' using it), i would like
> to see it's incorporation spark development along those lines. i have
> been using it for every program i have written for pycard since it's
> creation. I am wondering how or in what context i could introduce
> this?
>
> I am sincerely motivated and impressed by pycard,
>
> James.

If your changes are simply additional modules and don't require a 
change to framework files such as model.py, widget.py, etc. then you 
should just make the files available on the web for people to download. 
If the files in a zip archive aren't too big, then you could send them 
to the list as an attachment if you don't have a web site where you can 
host the files.

If your extensions do require changes to the framework in order to be 
used, then we'll have to consider a different approach. Either way, 
people will want to see some concrete examples of how to use it, steps 
for building a layout, calls you need to make in user code, etc.

ka

Re: [Pythoncard-users] wrapping wx.Notebook

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

There didn't seem to be any major objections, so I went ahead and 
checked in the Notebook component, the necessary changes to the 
framework, and a testNotebook sample. The changes should show up on 
anonymous cvs later this afternoon. See my other comments below.

On Sep 14, 2004, at 5:43 AM, Alex Tweedly wrote:

> At 16:41 13/09/2004 -0700, Kevin Altis wrote:
>> The notebook component wouldn't have an attribute list for all the 
>> pages, instead you would add those manually by calling addPage, most 
>> likely in your on_initialize method. I made a pageWindow function 
>> that is almost identical to the childWindow function so that adding a 
>> page looks something like this:
>>
>> page = model.pageWindow(self.components.notebook, minimal.Minimal)
>> self.components.notebook.AddPage(page, 'minimal', True)
>
> Any strong reason for not using an attribute list within the notebook 
> component ?
> The fact that I have say 5 pages in the notebook feels like something 
> I should be dealing with in the resource Editor if possible.

I agree, it seems natural to want to be able to provide a list of key, 
value pairs of the page name for the tab/key and the class as the 
value. It would be possible to parse the value such as minimal.Minimal 
and do the appropriate dynamic imports when the Notebook component is 
loaded. That could be a bit error-prone, but we can do some experiments 
and see how well it works.

>> Since I didn't hide the wxPython methods behind a list interface, 
>> accessing a elements of the child pages look like:
>>
>> print self.components.notebook.GetPage(0).components.field1.text
>
> Would have been nice to be able to "name" the pages, and then 
> reference something like
>   print self.components.notebook.AboutPage.components.field1.text

Again, this is an additional set of attribute hooks we'll have to try. 
When pages are added, it would be possible to do something like this in 
the Notebook component in small wrappers for AddPage and InsertPage:

win = childWindow(...)
name = pageText.replace(' ')
self.AddPage(win, pageText, True)
setattr(self, name, win)

Rather than just removing spaces, the text would need to be completely 
sanitized so it only contains Alphanumerics and starts with a letter. 
The biggest problem would be name collision with an existing method or 
another page. So, we would need to decide whether to use a prefix to 
help protect against collision as well as provide some other means of 
auto-renaming... DeletePage would remove the attribute.

>> So, will people be happy with this kind of solution? Any alternative 
>> suggestions? If I check this into cvs does anyone have a app or 
>> dialog they've been wanting to do that needs a wx.Notebook so we 
>> would have a decent test case to flesh out other issues?
>
> I've always wanted the code editor to use tabbed pages instead of 
> covering my screen with windows - but there's probably too big a 
> learning curve to try that. And in any case, it's an example where 
> each tab is identical - so probably not the most demanding test case.

Excellent, I've been wanting to do that as well. It will require a 
refactor of the codeEditor to deal with multiple documents, but that 
will be a good change, because then it should be simpler to add an 
editor window to the resourceEditor as well. Maybe we can work on that 
together.

> There'd be something ironic about adding tabbed browsing to the 
> simpleIEBrowser sample :-)

:)

> I would convert one of my Rev scripts that uses tabbed pages for 
> configuration settings and on-line help, just to compare - but again I 
> don't think that's a very demanding usage.
>
> -- Alex.

The widgets sample could be refactored so each tab contains a different 
set of controls.

ka

Re: [Pythoncard-users] Alternative to the Notebook

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

At 00:29 14/09/2004 -0400, jamesr wrote:

>I was perhaps not specific enough in that I would like a volunteer or
>two to experient with the framework i have, and report to the list in
>general as to your opinion of it. It represents the (text only)
>portion of a standard way of laying out python card program that would
>be created and edited in a gui framework (!) in a future iteration.
>the setup allows for a clean seperation of different gui elements and
>it is especially for a code generation developemtn environment that
>attaches python code to the larger strucuture sensibly. Any one with
>experience in python card and is willing to listen to <5 minutes of
>explanation would suffice.
>
>At this point i think having some peer-review is my only chance to
>have such a setup realistially considered by the group. Please email
>cir...@gm... if you will beta test.

James,

I'd be happy to consider being a beta tester.

I know - not a very committed response, but I'm not able to commit much of 
my time without some understanding of what it is. The above description is 
enough to be intriguing, but not enough to justify a commitment yet.

I actually think the best idea would be to send a brief summary of what the 
framework is or does to the list, and then you'll likely attract the most 
appropriate beta testers. And I don't think you need to be shy - I've 
posted on here well beyond my knowledge level and no-one's taken umbrage or 
got cross with me :-)

But if you would prefer to keep the explanations etc. off-list until you've 
refined then a bit, I can sympathise and would offer to be a tester for you.

-- Alex.

Re: [Pythoncard-users] wrapping wx.Notebook

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

At 16:41 13/09/2004 -0700, Kevin Altis wrote:
>I sat down after the earlier posts about Notebook and did some 
>experiments. I created a Notebook component and made a simple sample that 
>uses the Notebook component and then manually adds a Panel with a TextCtrl 
>to the notebook. That worked fine and the resourceEditor worked with the 
>Notebook component too on the first try, though of course there weren't 
>any page attributes to complicate matters. Then I started trying to add 
>existing backgrounds as pages in the on_initialize method. You can't add a 
>wx.Frame as a notebook page and PythonCard backgrounds subclass wx.Frame 
>so that didn't work.
>
>I was able to get it to work by making a PageBackground class that is 
>almost identical to Background except that instead of a wx.Frame it 
>subclasses wx.Panel. Of course, many of the features of a Background don't 
>make any sense for a notebook page, so I commented out the menubar, 
>statusBar, and all of the events except idle. I had to make some further 
>tweaks to the event binding and dispatch to correctly deal with the 
>notebook pages without breaking events in Background and CustomDialogs, 
>but it all seems to be working now. I made a sample that uses the minimal 
>and widgets backgrounds without any changes except that instead of 
>model.Background, the Minimal and WidgetsTest background subclass 
>model.PageBackground.
>
>Since this was a fairly quick "hack" I hesitate to check it into cvs 
>without some discussion on the subject.
>
>If we went with a solution like this I would probably modify the 
>resourceEditor to support a new PageBackground template type. A 
>PageBackground is basically going to be like a Background, but there won't 
>be any menus, statusBar, etc., otherwise the .rsrc.py files will be almost 
>identical to keep things simple. You would edit each page of the notebook 
>separately just like you do different backgrounds today. If and when the 
>resourceEditor is changed to allow editing of multiple windows at once 
>that would be a little less clunky.

>The notebook component wouldn't have an attribute list for all the pages, 
>instead you would add those manually by calling addPage, most likely in 
>your on_initialize method. I made a pageWindow function that is almost 
>identical to the childWindow function so that adding a page looks 
>something like this:
>
>page = model.pageWindow(self.components.notebook, minimal.Minimal)
>self.components.notebook.AddPage(page, 'minimal', True)

Any strong reason for not using an attribute list within the notebook 
component ?
The fact that I have say 5 pages in the notebook feels like something I 
should be dealing with in the resource Editor if possible.

>Since I didn't hide the wxPython methods behind a list interface, 
>accessing a elements of the child pages look like:
>
>print self.components.notebook.GetPage(0).components.field1.text

Would have been nice to be able to "name" the pages, and then reference 
something like
   print self.components.notebook.AboutPage.components.field1.text

>So, will people be happy with this kind of solution? Any alternative 
>suggestions? If I check this into cvs does anyone have a app or dialog 
>they've been wanting to do that needs a wx.Notebook so we would have a 
>decent test case to flesh out other issues?

I've always wanted the code editor to use tabbed pages instead of covering 
my screen with windows - but there's probably too big a learning curve to 
try that. And in any case, it's an example where each tab is identical - so 
probably not the most demanding test case.

There'd be something ironic about adding tabbed browsing to the 
simpleIEBrowser sample :-)

I would convert one of my Rev scripts that uses tabbed pages for 
configuration settings and on-line help, just to compare - but again I 
don't think that's a very demanding usage.

-- Alex.

Re: [Pythoncard-users] wrapping wx.Notebook

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

At 23:36 13/09/2004 -0500, Brad Allen wrote:

>I'd don't really understand all of what you are describing here, and I'm 
>too sleepy to dig into it tonight. But both you and Alex both seem to be 
>talking about introducing a major architectural change to support tabbed 
>browsing.

Actually, I think Kevin's PageBackground is a way to avoid doing too major 
changes.

(And my discussion about sizers was also not about any major change - I 
wouldn't want to see Pythoncard changing the resourceEditor GUI to 
explicitly use sizers. I'm hoping that we can (adequately, but perfectly) 
reconcile the effectiveness and power of sizers with the ease of use of 
"direct layout".

>This may be the right way to do it, and may provide other benefits, but 
>before I retire for the evening I just want to mention how the tabbed 
>interface widget is used in Revolution. It may not be the best way, but 
>it's worth mentioning.
>
>In Revolution, a tabbed interface is implemented as a dead-simple button. 
>The tabs don't "contain" other widgets. They don't act as a Panel or 
>implement a container model.  Clicking on a tab just generates an event 
>similar to picking an item from a Combo button or a popup menu. It sends a 
>mouseUp event along with the parameter of what tab the user clicked. 
>Hiding and showing interface widgets as a response is left up to the scripter.

Yeah, it's a neat trick. I was a bit surprised to see Rev use it, because 
they already have the inheritance/container infrastructure for groups, so 
it might have been easy to just re-use that for tabs. But I agree it does 
give 90% of the benefit for relatively little effort within the tool; I've 
user it for help/docs and for preference setting, and found it very easy to 
use.

>Of course, you can leverage Revolution's existing container model of 
>cards, backgrounds, and stacks if you want. I usually put a tabbed button 
>at the background level so that it shows up on all the cards in a given 
>stack. Then, I set up a correlation of one card per tab, so that if the 
>user clicks on the tab, the tab button takes the user to the appropriate 
>card. But that isn't the only way of doing it. I could just as easily have 
>hidden and shown the appropriate widgets all on one card.

I tried the "hide / reveal widgets" and found it pretty cumbersome and 
error-prone - the "card per tab" may add a number of cards, but it is much 
cleaner. The other issue with hide/reveal for Pythoncard will be when you 
use sizers - the current set of sizers don't have a way to properly handle 
multiple, non-interacting sets of widgets.

I think if PythonCard had  the multiple-cards-per-stack model, then it 
would be a good idea to look at using a similar trick, but without it, 
we're better off with PageBackground or similar approach.

-- Alex.

Re: [Pythoncard-users] wrapping wx.Notebook

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

I'd don't really understand all of what you are describing here, and 
I'm too sleepy to dig into it tonight. But both you and Alex both 
seem to be talking about introducing a major architectural change to 
support tabbed browsing. This may be the right way to do it, and may 
provide other benefits, but before I retire for the evening I just 
want to mention how the tabbed interface widget is used in 
Revolution. It may not be the best way, but it's worth mentioning.

In Revolution, a tabbed interface is implemented as a dead-simple 
button. The tabs don't "contain" other widgets. They don't act as a 
Panel or implement a container model.  Clicking on a tab just 
generates an event similar to picking an item from a Combo button or 
a popup menu. It sends a mouseUp event along with the parameter of 
what tab the user clicked. Hiding and showing interface widgets as a 
response is left up to the scripter.

Of course, you can leverage Revolution's existing container model of 
cards, backgrounds, and stacks if you want. I usually put a tabbed 
button at the background level so that it shows up on all the cards 
in a given stack. Then, I set up a correlation of one card per tab, 
so that if the user clicks on the tab, the tab button takes the user 
to the appropriate card. But that isn't the only way of doing it. I 
could just as easily have hidden and shown the appropriate widgets 
all on one card.


>From an earlier message:
>"It is probably time for a separate discussion thread on the issues 
>and possible solutions such as treating each page as a type of child 
>window where only the components of the child window resource are 
>used. I'm just brainstorming here. You would end up with a separate 
>source and resource file for each tab/page. I guess the references 
>to each tab layout would end up being something like 
>self.components.notebook[0].components.field1, etc. where each page 
>(window) of the notebook is referenced via a list."
>
>I sat down after the earlier posts about Notebook and did some 
>experiments. I created a Notebook component and made a simple sample 
>that uses the Notebook component and then manually adds a Panel with 
>a TextCtrl to the notebook. That worked fine and the resourceEditor 
>worked with the Notebook component too on the first try, though of 
>course there weren't any page attributes to complicate matters. Then 
>I started trying to add existing backgrounds as pages in the 
>on_initialize method. You can't add a wx.Frame as a notebook page 
>and PythonCard backgrounds subclass wx.Frame so that didn't work.
>
>I was able to get it to work by making a PageBackground class that 
>is almost identical to Background except that instead of a wx.Frame 
>it subclasses wx.Panel. Of course, many of the features of a 
>Background don't make any sense for a notebook page, so I commented 
>out the menubar, statusBar, and all of the events except idle. I had 
>to make some further tweaks to the event binding and dispatch to 
>correctly deal with the notebook pages without breaking events in 
>Background and CustomDialogs, but it all seems to be working now. I 
>made a sample that uses the minimal and widgets backgrounds without 
>any changes except that instead of model.Background, the Minimal and 
>WidgetsTest background subclass model.PageBackground.
>
>Since this was a fairly quick "hack" I hesitate to check it into cvs 
>without some discussion on the subject.
>
>If we went with a solution like this I would probably modify the 
>resourceEditor to support a new PageBackground template type. A 
>PageBackground is basically going to be like a Background, but there 
>won't be any menus, statusBar, etc., otherwise the .rsrc.py files 
>will be almost identical to keep things simple. You would edit each 
>page of the notebook separately just like you do different 
>backgrounds today. If and when the resourceEditor is changed to 
>allow editing of multiple windows at once that would be a little 
>less clunky.
>
>The notebook component wouldn't have an attribute list for all the 
>pages, instead you would add those manually by calling addPage, most 
>likely in your on_initialize method. I made a pageWindow function 
>that is almost identical to the childWindow function so that adding 
>a page looks something like this:
>
>page = model.pageWindow(self.components.notebook, minimal.Minimal)
>self.components.notebook.AddPage(page, 'minimal', True)
>
>Since I didn't hide the wxPython methods behind a list interface, 
>accessing a elements of the child pages look like:
>
>print self.components.notebook.GetPage(0).components.field1.text
>
>So, will people be happy with this kind of solution? Any alternative 
>suggestions? If I check this into cvs does anyone have a app or 
>dialog they've been wanting to do that needs a wx.Notebook so we 
>would have a decent test case to flesh out other issues?
>
>ka
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM. 
>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] Alternative to the Notebook

[jamesr <cir...@gm...>]

I was perhaps not specific enough in that I would like a volunteer or
two to experient with the framework i have, and report to the list in
general as to your opinion of it. It represents the (text only)
portion of a standard way of laying out python card program that would
be created and edited in a gui framework (!) in a future iteration.
the setup allows for a clean seperation of different gui elements and
it is especially for a code generation developemtn environment that
attaches python code to the larger strucuture sensibly. Any one with
experience in python card and is willing to listen to <5 minutes of
explanation would suffice.

At this point i think having some peer-review is my only chance to
have such a setup realistially considered by the group. Please email
cir...@gm... if you will beta test.

I appreciate the support, 
James.

On Mon, 13 Sep 2004 20:48:31 -0700,
pyt...@li...
<pyt...@li...> wrote:
> Send Pythoncard-users mailing list submissions to
>         pyt...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> or, via email, send a message with subject or body 'help' to
>         pyt...@li...
> 
> You can reach the person managing the list at
>         pyt...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pythoncard-users digest..."
> 
> Today's Topics:
> 
>    1. Calendar component will use datetime (Kevin Altis)
>    2. wrapping wx.Notebook (Kevin Altis)
> 
> --__--__--
> 
> Message: 1
> Date: Mon, 13 Sep 2004 15:13:11 -0700
> From: "Kevin Altis" <al...@se...>
> To: "pythoncard-Users" <pyt...@li...>
> Subject: [Pythoncard-users] Calendar component will use datetime
> 
> This is just an FYI that I plan to have the Calendar component support
> the new wxPython datetime methods that will be in wxPython 2.5.2.9 and
> later. I've already checked in some changes so that calendar events now
> have a date attribute and there is also a date attribute. If you have
> one of the wxPython 2.5.2.9 daily builds installed then you can see the
> methods at work in the widgets sample:
> 
>  >>> comp.calCalendar.date
> datetime.date(2004, 9, 13)
>  >>> import datetime
>  >>> comp.calCalendar.date = datetime.date(2004, 9, 20)
> 
> http://starship.python.net/crew/robind/wxPython/daily/20040910/
> CHANGES.html
> 
> "Extended the wx.calendar.CalendarCtrl class with methods that get/set
> a Python datetime or date object. (These will only work with Python
> 2.3+) The methods are PySetDate, PyGetDate, PySetLowerDateLimit,
> PySetUpperDateLimit, PySetDateRange, PyGetLowerDateLimit, and
> PyGetUpperDateLimit. Also, CalendarEvent was extended with PySetDate
> and PyGetDate methods."
> 
> http://docs.python.org/lib/module-datetime.html
> 
> ka
> 
> --__--__--
> 
> Message: 2
> Date: Mon, 13 Sep 2004 16:41:30 -0700
> From: "Kevin Altis" <al...@se...>
> To: "pythoncard-Users" <pyt...@li...>
> Subject: [Pythoncard-users] wrapping wx.Notebook
> 
>  From an earlier message:
> "It is probably time for a separate discussion thread on the issues and
> possible solutions such as treating each page as a type of child window
> where only the components of the child window resource are used. I'm
> just brainstorming here. You would end up with a separate source and
> resource file for each tab/page. I guess the references to each tab
> layout would end up being something like
> self.components.notebook[0].components.field1, etc. where each page
> (window) of the notebook is referenced via a list."
> 
> I sat down after the earlier posts about Notebook and did some
> experiments. I created a Notebook component and made a simple sample
> that uses the Notebook component and then manually adds a Panel with a
> TextCtrl to the notebook. That worked fine and the resourceEditor
> worked with the Notebook component too on the first try, though of
> course there weren't any page attributes to complicate matters. Then I
> started trying to add existing backgrounds as pages in the
> on_initialize method. You can't add a wx.Frame as a notebook page and
> PythonCard backgrounds subclass wx.Frame so that didn't work.
> 
> I was able to get it to work by making a PageBackground class that is
> almost identical to Background except that instead of a wx.Frame it
> subclasses wx.Panel. Of course, many of the features of a Background
> don't make any sense for a notebook page, so I commented out the
> menubar, statusBar, and all of the events except idle. I had to make
> some further tweaks to the event binding and dispatch to correctly deal
> with the notebook pages without breaking events in Background and
> CustomDialogs, but it all seems to be working now. I made a sample that
> uses the minimal and widgets backgrounds without any changes except
> that instead of model.Background, the Minimal and WidgetsTest
> background subclass model.PageBackground.
> 
> Since this was a fairly quick "hack" I hesitate to check it into cvs
> without some discussion on the subject.
> 
> If we went with a solution like this I would probably modify the
> resourceEditor to support a new PageBackground template type. A
> PageBackground is basically going to be like a Background, but there
> won't be any menus, statusBar, etc., otherwise the .rsrc.py files will
> be almost identical to keep things simple. You would edit each page of
> the notebook separately just like you do different backgrounds today.
> If and when the resourceEditor is changed to allow editing of multiple
> windows at once that would be a little less clunky.
> 
> The notebook component wouldn't have an attribute list for all the
> pages, instead you would add those manually by calling addPage, most
> likely in your on_initialize method. I made a pageWindow function that
> is almost identical to the childWindow function so that adding a page
> looks something like this:
> 
> page = model.pageWindow(self.components.notebook, minimal.Minimal)
> self.components.notebook.AddPage(page, 'minimal', True)
> 
> Since I didn't hide the wxPython methods behind a list interface,
> accessing a elements of the child pages look like:
> 
> print self.components.notebook.GetPage(0).components.field1.text
> 
> So, will people be happy with this kind of solution? Any alternative
> suggestions? If I check this into cvs does anyone have a app or dialog
> they've been wanting to do that needs a wx.Notebook so we would have a
> decent test case to flesh out other issues?
> 
> ka
> 
> --__--__--
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> End of Pythoncard-users Digest
>

[Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions

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

I'm right there with you, Norman. That summation of the FileMaker 
situation is pretty much dead-on.

>Kevin Altis asked:
>
>>In particular, I would like to hear about features that products 
>>like FileMaker Pro provide that are needed for an OS tool that 
>>users could transition to without feeling like they are taking a 
>>step backwards.
>>
>
>I'd like to start more positively. My major client would forgive a 
>great deal if he got more speed. And I'm pretty sure he will get it 
>if I go down this, the Python/PythonCard, road. I start with this 
>comment as much of what Filemaker does is probably not worth 
>reproducing providing the user experience in the new environment is 
>perceived as positive.
>
>Filemaker 7 has just come out and it is much slower than version 6. 
>On moving to OS X we already took a speed hit so, in the four years 
>I have been working on this thing, instead of hardware improvements 
>making things slick it has all got slower. On top of this, FM7 
>requires relearning much of what one has done + obliges a rewrite. 
>Hence the reason my search is on.
>
>I looked at many possibilities, some commercial, some open source. 
>The reasons my quest has brought me here are:
>
>1) I liked python from the moment I started to play with it.
>2) one of the wx demos (then on OS X - now working mainly on a PC) 
>showed some really rapid responsiveness to events.
>
>
>Here is what Filemaker gives:
>
>No need to define field lengths for any type of field. This seems 
>trivial but gives an amazing freedom in database design.
>
>Pretty maintenance free. Most sites have no database expert. I have 
>never lost data (have come pretty close). However, no rollback.
>
>Almost transparently cross platform - some font and printing issues. 
>But client (as opposed to FM Server) not available on Linux. This 
>latter is political as, now that the Mac is Unix based, doing the 
>port would involve little work.
>
>No connection hassles. FM mixes data, scripts, layouts and stuff all 
>in one file per database (in FM7 this become per table).
>
>An integrated form designer that, being designed for the purpose of 
>databases, is pretty easy to use.
>Same tool is used to design reports.
>
>A relationship model that makes one to one, one to many, many to 
>many, many to one relationships pretty easy to get a grasp of. (At 
>least that's how it seems now, looking back).
>
>Where SQL would use scripts (I believe) to select a group of 
>records, FM frequently uses calculation fields as part of the 
>relationship.
>
>Calculations can appear in scripts as well as field definitions. 
>These make great use of an extensive set of 'Status' functions.
>
>FM is responsive to what is showing on the screen. If you haven't 
>seen this it needs some explanation. If you go to a layout that 
>contains references to another file(file = table in version < 7) 
>then that file gets opened. If you open that layout in a small 
>window only what is showing and referenced gets opened.
>
>Pretty neat pop-up lists that can be up to 64k characters (much more 
>in v7). On clicking in a field that has a pop-up the list becomes 
>live to the keyboard i.e. typing 'be' takes one to entries beginning 
>with 'be'. These lists can be based on
>a) custom values
>b) a value list from another file
>c) the values from a field
>d) the values from a field via a relationship.
>One pretty neat thing here is that a relationship can be defined 
>from virtually anywhere - deep withing the creation of a value list 
>or during field definition or script creation.
>
>However, there is no inbuilt type-ahead searching.
>
>
>What is horrible and nasty:
>
>No event based scripting.
>
>No automated field or layout creation. Nothing of this type can be 
>done on the fly.
>
>Can't get at the controls when some speed tweaks are needed.
>
>Incremental back ups are difficult to implement. Built in back up 
>method can be slow as much more than the raw data is getting backed 
>up. Can export fields and specify just data fields. Problem is that 
>this process cannot be dynamically scripted.
>
>Wide area network performance is lamentable as, at start up, the 
>whole caboodle has to be dragged over the wires before anything 
>happens. (This is another one that would lead my client to accept 
>re-learning an interface)
>
>Every user has to have a full copy of FM - form designer, script 
>maker et al included. This is expensive and adds unnecessary 
>security risks (there is a so-called kiosk version but these are not 
>net workable).
>
>Limited ability to produce dynamic dialogues.
>
>Poor documentation once above novice level. Poor response to bugs 
>and queries from FM, the company. (Happily, there are a couple of 
>good lists).
>
>Can't save or access scripts as text so can't cut and past chunks.
>
>Until v7, no application wide globals, no parameters for scripts (a 
>nightmare).
>
>Oh, I forgot - no variables. Filemaker uses what it call 'global 
>fields' for this. A real pain.
>
>No regular expression searches. No wildcards.
>
>__________________-
>
>Apologies if I have been too detailed or not enough.
>
>With all those downers some of you must be wondering why there is 
>hesitation. It is worth noting that most Filemaker developers are 
>doing quite nicely. FM, once mainly a Mac thing, now has 80% of new 
>sales on Windows. And sales are (or at least, were, up till v7) 
>growing fast. Many of these new users are tempted in by the ease 
>with which rudimentary databases can be produced. They then come 
>searching for guys like me when things get more complicated (as they 
>inevitably do),
>
>Norman Winn
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM. 
>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions

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

>A long message deserved a long reply, so...

Thanks! I appreciate the time.

>The primary benefit of Open Source (OS) is not the cost of the 
>frameworks, tools and applications. The key issue on whether to use 
>OS or proprietary tools is control. In terms of Python you know that 
>the language isn't going to go away and it will continue to work on 
>all major platforms for a long time, which you can't say for some of 
>the smaller proprietary company solutions. wxWidgets and wxPython 
>are getting better and much better supported financially each year, 
>especially with large OS projects like Chandler funding development; 
>Robin Dunn is a full-time employee of the OSAF. Whether you need all 
>the control that an OS solution gives you is a business decision 
>that I can't answer for you, but in general I think it is the right 
>direction.

I'm in agreement with you about those points; they are some of the 
reasons I'd prefer developing in an open standard such as Python. Of 
course, not everyone in our IT dept sees it that way. The standard 
response has been that we should do it in Visual Basic. However, 
cross-platform is a hard requirement for this project (we have over 
400 Macs that aren't going away), and I am making the case that we 
should consider Python as the standard tool for automation (shell 
scripts) and that these should integrate for our database 
environment. Folks in corporate IT depts are often suspicious about 
the benefits of open source in general, but Python is so manifestly 
robust and widely-used that I think it will prove to be no-brainer. 
In any case, the main two guys who are building the application want 
to do it in Python, and so as long the app meets our needs, I don't 
think we'll meet resistance. That's why I'm wanting to make sure the 
GUI platform is solid, because that's what the boss (and the users) 
will see.

What I'm gathering from the rest of your comments is that I'm not 
crazy just for trying to use PythonCard in a production application, 
but it is new territory and I should be prepared to encounter 
surprises, and at a minimum, expect to revamp my UI logic and 
resource files significantly with every major PythonCard update until 
the API stabilizes. On the upside, I get some training wheels for 
wxPython and a way to get up and running very quickly with an 
application prototype.

>"Customer feedback" on PythonCard is actually pretty minimal 
>considering that there are 260+ people on the mailing list. Most of 
>the discussions on this list are support-related, either bugs or 
>people trying to figure out how to do something within PythonCard. I 
>think I'm generally pretty responsive to issues that people bring 
>up, but if nobody is talking about design, UI features or other 
>things they want to see in the project, then I just move at my own 
>pace and treat myself as the customer :)

Maybe people don't want to be seen as complaining about a free 
product that is so generously being donated to the public.  I will 
take your comments as an invitation to provide feedback and generate 
ideas.

>I would love for us to get to the point that PythonCard had a really 
>nice environment so that someone could write a book "PythonCard for 
>Visual Basic Users" or something like that, but realistically the 
>environment is just too clunky right now, so maybe we'll get there 
>in 2005.

I'm glad to hear you're ambitious about improving PythonCard. I think 
it will fill an important need for a lot of people, once it matures. 
I don't really know much about the "competition", though. You 
mentioned Boa, wxGlade, wxDesigner, etc. I'll take a look at those...

>On the topic of database solutions, I'm extremely interested in that 
>application space, though I don't really do much with databases, 
>especially SQL databases day-to-day. In particular, I would like to 
>hear about features that products like FileMaker Pro provide that 
>are needed for an OS tool that users could transition to without 
>feeling like they are taking a step backwards.

There's definitely a big gap right there in the open source 
offerings. Building something like FileMaker or MS Access would be an 
enormous task, though. However, neither of those products has yet 
quite "got it right". I've spent a lot of time with FileMaker. It has 
improved tremendously with the version 7 release, but it's still very 
difficult to manage as your application grows in complexity. I don't 
know much about MS Access, but I knock it because it's not 
cross-platform. In it's favor, I've heard that it's a great way to 
learn SQL because it can act as a direct front end to MS SQL Server, 
and it makes use of SQL syntax in doing so.

  If only we had something FileMaker "done right" in the form of an 
open source database product, with these features:

	* database design/layout/reporting ease of FileMaker Pro
	* the slick scriptable GUI capabilities of Runtime Revolution
	* access to SQL syntax for database interaction,
	* ability to act as front-end for remote or local SQL 
database of choice
	* bundled local "default" database engine for use "out of box"
	* API for Python, PHP, Javascript, Ruby, Perl, etc.
	* built-in IDE and default scripting language (Python!)
	* point-and-click scripts as well as "real"
	* entity relationship diagrammer
	* report generation tool similar to Crystal Reports

A product like that could be used by non-scripters as well as serious 
developers. It's a great candidate for an open-source project, 
because a database is something needed by most people who have a 
computer. It's in the same category as word processor, spreadsheet, 
and email. Hm...now that I think of it, it's hard to believe someone 
in the open source world isn't already doing this. It looks like 
OpenOffice has some database tools, but it's nothing like the pie in 
the sky I'm talking about here.

[Pythoncard-users] Re: Pythoncard-users digest, Vol 1 #797 - 7 msgs

[jamesr <cir...@gm...>]

To adress the questions on the mailing list, i have already developed
what i call the 'AdvancedEventFramework' that allows for tabbed
interfaces, as well as the dynamic growing and shrinking of windows to
accomodate them, if needed. I have myself and possibly a friend
helping. It makes the creation of larger pycard program very painless,
and i would like it to be considered as a contribution to the project.
Since the capabilities it offers are extremely flexible (i have
already begun development of a 'visual python' using it), i would like
to see it's incorporation spark development along those lines. i have
been using it for every program i have written for pycard since it's
creation. I am wondering how or in what context i could introduce
this?

I am sincerely motivated and impressed by pycard,

James.


On Mon, 13 Sep 2004 15:09:14 -0700,
pyt...@li...
<pyt...@li...> wrote:
> Send Pythoncard-users mailing list submissions to
>         pyt...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> or, via email, send a message with subject or body 'help' to
>         pyt...@li...
> 
> You can reach the person managing the list at
>         pyt...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pythoncard-users digest..."
> 
> Today's Topics:
> 
>    1. Re: [Pythonmac-SIG] quicktime info? (Arthur Elsenaar)
>    2. Re: PythonCard suitability for a project; looking for
>        opinions (bra...@om...)
>    3. Re: PythonCard suitability for a project; looking for opinions (Kevin Altis)
>    4. generic container model (Donnal Walter)
>    5. Re: generic container model (Alex Tweedly)
>    6. Re: PythonCard suitability for a project; looking for opinions (normanwinn)
> 
> --__--__--
> 
> Message: 1
> From: Arthur Elsenaar <ar...@ia...>
> Date: Mon, 13 Sep 2004 19:36:34 +0200
> To: pyt...@li...
> Subject: [Pythoncard-users] Re: [Pythonmac-SIG] quicktime info?
> 
> On Sep 13, 2004, at 18:08, Kevin Altis wrote:
> 
> >>> looked around the archives and documentation, but can't find
> >>> information on how to use some very limited quicktime functionality.
> >>>
> >>> The main functionality I need are the movieplayer to load a sound
> >>> file, duration and position information.
> >>>
> >>> I like to add this an existing pythoncard application, so I suspect
> >>> a PyObjC solution is out the door?
> >>
> >> Well, I'm in the process of developing wxQtMovie for wxPython, which
> >> should already do what you need. (There's also wxSound, though I
> >> don't think you can get duration or position information with it.)
> >> Since pythoncard uses wxPython underneath, I think all that's needed
> >> is for Kevin A. to make the class accessible from pythoncard itself.
> >> I'm forwarding this to wxPython developer's list so that we can
> >> discuss this further and work out a solution.
> >>
> > PythonCard already wraps wx.Sound with its own Sound class in
> > PythonCard/sound.py that is demonstrated by the sound sample
> > application. There is another sample application, mp3player that uses
> > the PyGame movie module to play MP3 files and the PyGame movie module
> > definitely lets you do all the positional manipulation for MPEG. On
> > the QuickTime front, as soon as Kevin O.'s module is part of the
> > general wxPython distribution I will make a wrapper component for it,
> > so maybe wxPython 2.5.2.9?
> 
> yes, I tried the mp3player example, but diverted to using pygame.mixer
> as I need more channels and .wav and .aif support. I have this working,
> but sound.get_length() gives an attribute error.. (mailed the issue to
> the pygame list). So when Kevin O. will have quicktime working in wx,
> that would be perfect for my app -> can we test this?
> 
> Anyway, here's the relevant -commented out- code from the mp3player,
> but that works fine for me.
> 
>          ## NOTE WE DON'T IMPORT PYGAME UNTIL NOW.  Don't put "import
> pygame" at the top of the file.
>          import pygame
>          self.movie = pygame.movie.Movie(filename)
>          self.movie.play()
> 
>          # it was a good idea at first, but mixer simply doesn't work,
> at least on the Mac
> ##        assert os.path.exists(filename)
> ##        from pygame import mixer
> ##        mixer.init(44100, 2)
> ##        mixer.music.load(filename)
> ##        mixer.music.play()
> ##        print mixer.music.get_busy()
> ##        #time.sleep(5)
> ##        #mixer.music.stop()
> 
> Why do you say in the first line pygame shouldn't be imported at an
> earlier stage in the code?
> 
> Arthur
> 
> --__--__--
> 
> Message: 2
> To: pyt...@li...
> Cc: Brad Allen <bra...@ma...>,
>         Walker Hale <wa...@ma...>
> Subject: Re: [Pythoncard-users] PythonCard suitability for a project; looking for
>  opinions
> From: bra...@om...
> Date: Mon, 13 Sep 2004 13:57:05 -0500
> 
> This is a multipart message in MIME format.
> --=_alternative 00681A5786256F0E_=
> Content-Type: text/plain; charset="US-ASCII"
> 
> Steven D'Aprano <st...@cy...> wrote on 09/13/2004 05:45:35 AM:
> 
> > On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote:
> >
> > > Here is the first question: Am I crazy for considering PythonCard for
> > > use in a production environment? PythonCard is obviously not yet
> > > mature, and still has many gaps in the feature set, not to mention
> > > bugs. On the plus side, it seems to me that when users report bugs on
> > > this mailing list, they are generally identified quickly and fixed.
> > > It also seems to me that if we run into problems or gaps in the
> > > PythonCard feature set, we can fall back on the more mature wxPython,
> > > and so have a mix of wxPython and PythonCard in our GUI logic. Also,
> > > because PythonCard is open source, we can look under the hood figure
> > > out what's wrong if we need to.  Is this a fair assessment?
> >
> > It sounds like you've already answered your own question. Perhaps you
> are
> > looking for something that you can take to your bosses and show them a
> > "real" [cough] application, something with grunt.
> 
> Well, FileMaker was ok when our needs were simpler, but it didn't scale
> well as our application grew in complexity. FileMaker 7 addresses some of
> these issues, but we'd be looking at a complete rewrite. Meanwhile, most
> of the other company databases are on SQL Server, so it makes sense to
> move in that direction. And, yes, Python has a lot more "grunt" than
> FileMaker.
> 
> > Perhaps not quite Microsoft Office written in PythonCard, but something
> > like MYOB or Quickbooks?
> 
> This is a custom in-house application; it won't have the sophistication of
> a commercial app, but it does need to be stable and have a streamlined
> user interface to allow users to work quickly (web interfaces are too slow
> and limited, and don't have access to the local filesystem on Macs).
> 
> > > Second question: Do you see PythonCard as primarily a tool for
> > > building GUIs for small, simple apps, or do you think it will scale
> > > well to more complex apps, in terms of managing that complexity ?
> > > The app I'm imagining will require many windows, many dialog boxes,
> > > dynamically changing global menus, contextual menus, keyboard
> > > shortcuts (including function keys), and validation for data entry
> > > fields. It would also be nice but not required to have search results
> > > that populate as the user types, layouts changing within a given
> > > window, tab order between fields, drag & drop of files onto fields to
> > > populate paths, user-draggable icon objects, and tabbed interface in
> > > some windows.
> >
> > That sounds less like a question about PythonCard itself and more like a
> 
> > question about your ability to design and manage the GUI. Unless I'm
> badly
> > mistaken, PythonCard can provide all of those interface objects.
> 
> Good; that's what I was hoping to hear. Over the past couple of days, I've
> found ways to do some of those things, though I didn't see a widget for a
> tabbed interface in Resource Editor, and am not clear on how to produce a
> contextual menu.
> 
> > Can PythonCard talk to your database (assuming you have one)? Knock up a
> 
> > quick test to see. If it fails, again you've saved yourself a lot of
> time.
> 
> I'm not concerned about PythonCard connecting to the database; that's a
> job for Python itself.
> 
> > The idea is, before you commit to 1000 man-hours to build the
> application,
> > commit to 30 hours to build a few test apps and run some benchmarks.
> 
> I will do as you advise, and build a test application; thanks!
> 
> --=_alternative 00681A5786256F0E_=
> Content-Type: text/html; charset="US-ASCII"
> 
> <br><font size=2><tt>Steven D'Aprano &lt;st...@cy...&gt; wrote on
> 09/13/2004 05:45:35 AM:<br>
> <br>
> &gt; On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote:<br>
> &gt; <br>
> &gt; &gt; Here is the first question: Am I crazy for considering PythonCard
> for <br>
> &gt; &gt; use in a production environment? PythonCard is obviously not
> yet <br>
> &gt; &gt; mature, and still has many gaps in the feature set, not to mention
> <br>
> &gt; &gt; bugs. On the plus side, it seems to me that when users report
> bugs on <br>
> &gt; &gt; this mailing list, they are generally identified quickly and
> fixed. <br>
> &gt; &gt; It also seems to me that if we run into problems or gaps in the
> <br>
> &gt; &gt; PythonCard feature set, we can fall back on the more mature wxPython,
> <br>
> &gt; &gt; and so have a mix of wxPython and PythonCard in our GUI logic.
> Also, <br>
> &gt; &gt; because PythonCard is open source, we can look under the hood
> figure <br>
> &gt; &gt; out what's wrong if we need to. &nbsp;Is this a fair assessment?<br>
> &gt; <br>
> &gt; It sounds like you've already answered your own question. Perhaps
> you are <br>
> &gt; looking for something that you can take to your bosses and show them
> a <br>
> &gt; &quot;real&quot; [cough] application, something with grunt.<br>
> </tt></font>
> <br><font size=2><tt>Well, FileMaker was ok when our needs were simpler,
> but it didn't scale well as our application grew in complexity. FileMaker
> 7 addresses some of these issues, but we'd be looking at a complete rewrite.
> Meanwhile, most of the other company databases are on SQL Server, so it
> makes sense to move in that direction. And, yes, Python has a lot more
> &quot;grunt&quot; than FileMaker. </tt></font>
> <br><font size=2><tt><br>
> &gt; Perhaps not quite Microsoft Office written in PythonCard, but something
> <br>
> &gt; like MYOB or Quickbooks?<br>
> </tt></font>
> <br><font size=2><tt>This is a custom in-house application; it won't have
> the sophistication of a commercial app, but it does need to be stable and
> have a streamlined user interface to allow users to work quickly (web interfaces
> are too slow and limited, and don't have access to the local filesystem
> on Macs).</tt></font>
> <br><font size=2><tt><br>
> &gt; &gt; Second question: Do you see PythonCard as primarily a tool for
> <br>
> &gt; &gt; building GUIs for small, simple apps, or do you think it will
> scale <br>
> &gt; &gt; well to more complex apps, in terms of managing that complexity
> ? <br>
> &gt; &gt; The app I'm imagining will require many windows, many dialog
> boxes, <br>
> &gt; &gt; dynamically changing global menus, contextual menus, keyboard
> <br>
> &gt; &gt; shortcuts (including function keys), and validation for data
> entry <br>
> &gt; &gt; fields. It would also be nice but not required to have search
> results <br>
> &gt; &gt; that populate as the user types, layouts changing within a given
> <br>
> &gt; &gt; window, tab order between fields, drag &amp; drop of files onto
> fields to <br>
> &gt; &gt; populate paths, user-draggable icon objects, and tabbed interface
> in <br>
> &gt; &gt; some windows.<br>
> &gt; <br>
> &gt; That sounds less like a question about PythonCard itself and more
> like a <br>
> &gt; question about your ability to design and manage the GUI. Unless I'm
> badly <br>
> &gt; mistaken, PythonCard can provide all of those interface objects.<br>
> </tt></font>
> <br><font size=2><tt>Good; that's what I was hoping to hear. Over the past
> couple of days, I've found ways to do some of those things, though I didn't
> see a widget for a tabbed interface in Resource Editor, and am not clear
> on how to produce a contextual menu.</tt></font>
> <br><font size=2><tt><br>
> &gt; Can PythonCard talk to your database (assuming you have one)? Knock
> up a <br>
> &gt; quick test to see. If it fails, again you've saved yourself a lot
> of time.<br>
> </tt></font>
> <br><font size=2><tt>I'm not concerned about PythonCard connecting to the
> database; that's a job for Python itself.</tt></font>
> <br><font size=2><tt><br>
> &gt; The idea is, before you commit to 1000 man-hours to build the application,
> <br>
> &gt; commit to 30 hours to build a few test apps and run some benchmarks.<br>
> </tt></font>
> <br><font size=2><tt>I will do as you advise, and build a test application;
> thanks! &nbsp;</tt></font>
> <br>
> <br><font size=2><tt><br>
> </tt></font>
> <br>
> --=_alternative 00681A5786256F0E_=--
> 
> --__--__--
> 
> Message: 3
> Date: Mon, 13 Sep 2004 13:04:17 -0700
> From: "Kevin Altis" <al...@se...>
> To: bra...@om...
> Cc: "Walker Hale" <wa...@ma...>, pyt...@li...,
>   "Brad Allen" <bra...@ma...>
> Subject: Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions
> 
> --Apple-Mail-7-834540175
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
>         charset=US-ASCII;
>         delsp=yes;
>         format=flowed
> 
> On Sep 13, 2004, at 11:57 AM, bra...@om... wrote:
> 
> > Good; that's what I was hoping to hear. Over the past couple of days,
> > I've found ways to do some of those things, though I didn't see a
> > widget for a tabbed interface in Resource Editor, and am not clear on
> > how to produce a contextual menu.
> >
> There is no built-in support for the wx.Notebook class right now, which
> is what you would use to do a real tabbed interface. This is mostly due
> to PythonCard having a "flat" layout model rather than supporting a
> generic container model where you could have a different layout in each
> notebook tab/page. This has been discussed a number of times on the
> mailing list and is obviously a big missing feature, but I don't really
> know how to support it correctly. There was one attempt to incorporate
> this into the framework and resourceEditor, but it was never
> incorporated into the main cvs code or updated for release 0.8.
> 
> It is probably time for a separate discussion thread on the issues and
> possible solutions such as treating each page as a type of child window
> where only the components of the child window resource are used. I'm
> just brainstorming here. You would end up with a separate source and
> resource file for each tab/page. I guess the references to each tab
> layout would end up being something like
> self.components.notebook[0].components.field1, etc. where each page
> (window) of the notebook is referenced via a list.
> 
> You'll also need to do the context (popup) menu yourself. For that you
> just create a wx.Menu in a on_somecomponent_mouseContextUp event
> handler or mouseContextClick in the case of a MultiColumnList. If you
> look at the fpop.py code in cvs you'll see an example of this
> 
> http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/
> fpop/fpop.py
> 
> The relevant methods are initContextMenu and
> on_mclHeaders_mouseContextClick. fpop is not included as part of the
> normal PythonCard releases because it is too rough to allow out in the
> wild and people could end up deleting email accidentally.
> 
> ka
> 
> --Apple-Mail-7-834540175
> Content-Transfer-Encoding: 7bit
> Content-Type: text/enriched;
>         charset=US-ASCII
> 
> On Sep 13, 2004, at 11:57 AM, bra...@om... wrote:
> 
> <excerpt><fixed><smaller>Good; that's what I was hoping to hear. Over
> the past couple of days, I've found ways to do some of those things,
> though I didn't see a widget for a tabbed interface in Resource
> Editor, and am not clear on how to produce a contextual
> menu.</smaller></fixed>
> 
> </excerpt>There is no built-in support for the wx.Notebook class right
> now, which is what you would use to do a real tabbed interface. This
> is mostly due to PythonCard having a "flat" layout model rather than
> supporting a generic container model where you could have a different
> layout in each notebook tab/page. This has been discussed a number of
> times on the mailing list and is obviously a big missing feature, but
> I don't really know how to support it correctly. There was one attempt
> to incorporate this into the framework and resourceEditor, but it was
> never incorporated into the main cvs code or updated for release 0.8.
> 
> It is probably time for a separate discussion thread on the issues and
> possible solutions such as treating each page as a type of child
> window where only the components of the child window resource are
> used. I'm just brainstorming here. You would end up with a separate
> source and resource file for each tab/page. I guess the references to
> each tab layout would end up being something like
> self.components.notebook[0].components.field1, etc. where each page
> (window) of the notebook is referenced via a list.
> 
> You'll also need to do the context (popup) menu yourself. For that you
> just create a wx.Menu in a on_somecomponent_mouseContextUp event
> handler or mouseContextClick in the case of a MultiColumnList. If you
> look at the fpop.py code in cvs you'll see an example of this
> 
> http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/fpop/fpop.py
> 
> The relevant methods are initContextMenu and
> on_mclHeaders_mouseContextClick. fpop is not included as part of the
> normal PythonCard releases because it is too rough to allow out in the
> wild and people could end up deleting email accidentally.
> 
> ka
> 
> --Apple-Mail-7-834540175--
> 
> --__--__--
> 
> Message: 4
> Date: Mon, 13 Sep 2004 13:47:18 -0700 (PDT)
> From: Donnal Walter <don...@ya...>
> To: pyt...@li...
> Cc: Kevin Altis <al...@se...>
> Subject: [Pythoncard-users] generic container model
> 
> Kevin Altis" <al...@se...>
> > There is no built-in support for the wx.Notebook class
> > right now, which is what you would use to do a real tabbed
> > interface. This is mostly due to PythonCard having a "flat"
> > layout model rather than supporting a generic container
> > model ...
> 
> <delurking>
> Aha! A critical insight. If I understand correctly this "flat"
> model also explains (at least in part) why sizers are problematic
> to implement in the framework. Ideally, each container should have
> a built-in sizer to which components are automatically added as
> they are added to the container. The kind of sizer should be
> determined by the container, and the parameters for each component
> should be passed like 'size' and 'pos' are now. (Another useful
> parameter for each component would be a data model from some kind
> of abstraction layer.)
> 
> > ... where you could have a different layout in each notebook
> > tab/page. This has been discussed a number of times on the
> > mailing list and is obviously a big missing feature, but I
> > don't really know how to support it correctly. There was one
> > attempt to incorporate this into the framework and
> > resourceEditor, but it was never incorporated into the main
> > cvs code or updated for release 0.8.
> >
> > It is probably time for a separate discussion thread on the
> > issues and possible solutions such as treating each page as
> > a type of child window where only the components of the child
> > window resource are used. I'm just brainstorming here. ...
> 
> Brainstorming further, I would suggest that for PythonCard *2.0* a
> class-based rather than an instance-based framework be considered.
> Each container would be defined as a *class* (with an appropriate
> resource-file notation, something other than a dictionary), such
> that multiple instances could be created if so desired. In either
> case, however, as the class is instantiated (initialized) the
> parent-child relationships are established as well as sizer
> relationships.
> 
> > ... You would end up with a separate source and resource file
> > for each tab/page. I guess the references to each tab layout
> > would end up being something like
> > self.components.notebook[0].components.field1, etc. where
> > each page (window) of the notebook is referenced via a list.
> 
> In a class-based framework, the top-level resource file would
> import component resource files as they are needed. Just a thought.
> </delurking>
> 
> Regards,
> Donnal Walter
> Arkansas Children's Hospital
> 
> --__--__--
> 
> Message: 5
> Date: Mon, 13 Sep 2004 22:40:47 +0100
> To: Donnal Walter <don...@ya...>,
>  pyt...@li...
> From: Alex Tweedly <al...@tw...>
> Subject: Re: [Pythoncard-users] generic container model
> Cc: Kevin Altis <al...@se...>
> 
> --=======45E481F=======
> Content-Type: text/plain; x-avg-checked=avg-ok-444150A3; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 8bit
> 
> At 13:47 13/09/2004 -0700, Donnal Walter wrote:
> ><delurking>
> >Aha! A critical insight. If I understand correctly this "flat"
> >model also explains (at least in part) why sizers are problematic
> >to implement in the framework. Ideally, each container should have
> >a built-in sizer to which components are automatically added as
> >they are added to the container. The kind of sizer should be
> >determined by the container, and the parameters for each component
> >should be passed like 'size' and 'pos' are now.
> 
> If PythonCard had a non-flat model, then it would be easier to change it to
> have explicit containers (each being a sizer of one kind or another).
> 
> But I think there's a more fundamental problem: it would require a
> different approach to laying out your GUI.  Using sizers kind of requires
> that you have a plan for the layout of controls, and can then describe a
> hierarchy of sizers and place controls within them. This is, I think,
> rather contrary to the freedom that PythonCard gives you to rapidly
> prototype and play with different controls and arrangements of them.
> 
> There's certainly a contradiction between the idea that you "place"
> controls (as in Pythoncard) versus "arrange the order and relative
> position" of controls, and let sizers shuffle them into their final (but
> dynamic) positions.
> 
> I've been playing around with sizers in Pythoncard; I've built a couple of
> "auto-sizer" functions that take a component layout as found in a resource
> file, and generate a reasonable first-cut at arranging those into sizers.
> 
> Basic idea is that it should take the component positions (and use some
> default assumptions about different components) to build a default set of
> sizers. This can be aided by some "hints" added to the component data
> (currently using "custom data" in the components, but if the idea ever gets
> anywhere, it might be possible to add something to the resource editor to
> support this more directly) to guide its actions.  The auto-sizer can then
> either just operate, or it can spit out the source code that will make
> equivalent simple sizer calls, and can therefore be the starting point for
> custom programming.
> 
> I was feeling quite optimistic about it a couple of weeks ago - and then
> got side-tracked. I'll work on it a bit more, and if I can come up with
> something that works well enough, and is easy to explain, I'll make it
> available to anyone who wants to play around with sizers.
> 
> -- Alex.
> 
> --=======45E481F=======--
> 
> --__--__--
> 
> Message: 6
> Date: Tue, 14 Sep 2004 00:08:43 +0200
> From: normanwinn <nor...@on...>
> Reply-To: nor...@on...
> To: pyt...@li...
> Subject: [Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions
> 
> Kevin Altis asked:
> 
> >In particular, I would like to
> >hear about features that products like FileMaker Pro provide that are
> >needed for an OS tool that users could transition to without feeling
> >like they are taking a step backwards.
> >
> 
> I'd like to start more positively. My major client would forgive a great
> deal if he got more speed. And I'm pretty sure he will get it if I go
> down this, the Python/PythonCard, road. I start with this comment as
> much of what Filemaker does is probably not worth reproducing providing
> the user experience in the new environment is perceived as positive.
> 
> Filemaker 7 has just come out and it is much slower than version 6. On
> moving to OS X we already took a speed hit so, in the four years I have
> been working on this thing, instead of hardware improvements making
> things slick it has all got slower. On top of this, FM7 requires
> relearning much of what one has done + obliges a rewrite. Hence the
> reason my search is on.
> 
> I looked at many possibilities, some commercial, some open source. The
> reasons my quest has brought me here are:
> 
> 1) I liked python from the moment I started to play with it.
> 2) one of the wx demos (then on OS X - now working mainly on a PC)
> showed some really rapid responsiveness to events.
> 
> Here is what Filemaker gives:
> 
> No need to define field lengths for any type of field. This seems
> trivial but gives an amazing freedom in database design.
> 
> Pretty maintenance free. Most sites have no database expert. I have
> never lost data (have come pretty close). However, no rollback.
> 
> Almost transparently cross platform - some font and printing issues. But
> client (as opposed to FM Server) not available on Linux. This latter is
> political as, now that the Mac is Unix based, doing the port would
> involve little work.
> 
> No connection hassles. FM mixes data, scripts, layouts and stuff all in
> one file per database (in FM7 this become per table).
> 
> An integrated form designer that, being designed for the purpose of
> databases, is pretty easy to use.
> Same tool is used to design reports.
> 
> A relationship model that makes one to one, one to many, many to many,
> many to one relationships pretty easy to get a grasp of. (At least
> that's how it seems now, looking back).
> 
> Where SQL would use scripts (I believe) to select a group of records, FM
> frequently uses calculation fields as part of the relationship.
> 
> Calculations can appear in scripts as well as field definitions. These
> make great use of an extensive set of 'Status' functions.
> 
> FM is responsive to what is showing on the screen. If you haven't seen
> this it needs some explanation. If you go to a layout that contains
> references to another file(file = table in version < 7) then that file
> gets opened. If you open that layout in a small window only what is
> showing and referenced gets opened.
> 
> Pretty neat pop-up lists that can be up to 64k characters (much more in
> v7). On clicking in a field that has a pop-up the list becomes live to
> the keyboard i.e. typing 'be' takes one to entries beginning with 'be'.
> These lists can be based on
> a) custom values
> b) a value list from another file
> c) the values from a field
> d) the values from a field via a relationship.
> One pretty neat thing here is that a relationship can be defined from
> virtually anywhere - deep withing the creation of a value list or during
> field definition or script creation.
> 
> However, there is no inbuilt type-ahead searching.
> 
> What is horrible and nasty:
> 
> No event based scripting.
> 
> No automated field or layout creation. Nothing of this type can be done
> on the fly.
> 
> Can't get at the controls when some speed tweaks are needed.
> 
> Incremental back ups are difficult to implement. Built in back up method
> can be slow as much more than the raw data is getting backed up. Can
> export fields and specify just data fields. Problem is that this process
> cannot be dynamically scripted.
> 
> Wide area network performance is lamentable as, at start up, the whole
> caboodle has to be dragged over the wires before anything happens. (This
> is another one that would lead my client to accept re-learning an interface)
> 
> Every user has to have a full copy of FM - form designer, script maker
> et al included. This is expensive and adds unnecessary security risks
> (there is a so-called kiosk version but these are not net workable).
> 
> Limited ability to produce dynamic dialogues.
> 
> Poor documentation once above novice level. Poor response to bugs and
> queries from FM, the company. (Happily, there are a couple of good lists).
> 
> Can't save or access scripts as text so can't cut and past chunks.
> 
> Until v7, no application wide globals, no parameters for scripts (a
> nightmare).
> 
> Oh, I forgot - no variables. Filemaker uses what it call 'global fields'
> for this. A real pain.
> 
> No regular expression searches. No wildcards.
> 
> __________________-
> 
> Apologies if I have been too detailed or not enough.
> 
> With all those downers some of you must be wondering why there is
> hesitation. It is worth noting that most Filemaker developers are doing
> quite nicely. FM, once mainly a Mac thing, now has 80% of new sales on
> Windows. And sales are (or at least, were, up till v7) growing fast.
> Many of these new users are tempted in by the ease with which
> rudimentary databases can be produced. They then come searching for guys
> like me when things get more complicated (as they inevitably do),
> 
> Norman Winn
> 
> --__--__--
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> End of Pythoncard-users Digest
>

[Pythoncard-users] wrapping wx.Notebook

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

 From an earlier message:
"It is probably time for a separate discussion thread on the issues and 
possible solutions such as treating each page as a type of child window 
where only the components of the child window resource are used. I'm 
just brainstorming here. You would end up with a separate source and 
resource file for each tab/page. I guess the references to each tab 
layout would end up being something like 
self.components.notebook[0].components.field1, etc. where each page 
(window) of the notebook is referenced via a list."

I sat down after the earlier posts about Notebook and did some 
experiments. I created a Notebook component and made a simple sample 
that uses the Notebook component and then manually adds a Panel with a 
TextCtrl to the notebook. That worked fine and the resourceEditor 
worked with the Notebook component too on the first try, though of 
course there weren't any page attributes to complicate matters. Then I 
started trying to add existing backgrounds as pages in the 
on_initialize method. You can't add a wx.Frame as a notebook page and 
PythonCard backgrounds subclass wx.Frame so that didn't work.

I was able to get it to work by making a PageBackground class that is 
almost identical to Background except that instead of a wx.Frame it 
subclasses wx.Panel. Of course, many of the features of a Background 
don't make any sense for a notebook page, so I commented out the 
menubar, statusBar, and all of the events except idle. I had to make 
some further tweaks to the event binding and dispatch to correctly deal 
with the notebook pages without breaking events in Background and 
CustomDialogs, but it all seems to be working now. I made a sample that 
uses the minimal and widgets backgrounds without any changes except 
that instead of model.Background, the Minimal and WidgetsTest 
background subclass model.PageBackground.

Since this was a fairly quick "hack" I hesitate to check it into cvs 
without some discussion on the subject.

If we went with a solution like this I would probably modify the 
resourceEditor to support a new PageBackground template type. A 
PageBackground is basically going to be like a Background, but there 
won't be any menus, statusBar, etc., otherwise the .rsrc.py files will 
be almost identical to keep things simple. You would edit each page of 
the notebook separately just like you do different backgrounds today. 
If and when the resourceEditor is changed to allow editing of multiple 
windows at once that would be a little less clunky.

The notebook component wouldn't have an attribute list for all the 
pages, instead you would add those manually by calling addPage, most 
likely in your on_initialize method. I made a pageWindow function that 
is almost identical to the childWindow function so that adding a page 
looks something like this:

page = model.pageWindow(self.components.notebook, minimal.Minimal)
self.components.notebook.AddPage(page, 'minimal', True)

Since I didn't hide the wxPython methods behind a list interface, 
accessing a elements of the child pages look like:

print self.components.notebook.GetPage(0).components.field1.text

So, will people be happy with this kind of solution? Any alternative 
suggestions? If I check this into cvs does anyone have a app or dialog 
they've been wanting to do that needs a wx.Notebook so we would have a 
decent test case to flesh out other issues?

ka

[Pythoncard-users] Calendar component will use datetime

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

This is just an FYI that I plan to have the Calendar component support  
the new wxPython datetime methods that will be in wxPython 2.5.2.9 and  
later. I've already checked in some changes so that calendar events now  
have a date attribute and there is also a date attribute. If you have  
one of the wxPython 2.5.2.9 daily builds installed then you can see the  
methods at work in the widgets sample:

 >>> comp.calCalendar.date
datetime.date(2004, 9, 13)
 >>> import datetime
 >>> comp.calCalendar.date = datetime.date(2004, 9, 20)

http://starship.python.net/crew/robind/wxPython/daily/20040910/ 
CHANGES.html

"Extended the wx.calendar.CalendarCtrl class with methods that get/set  
a Python datetime or date object. (These will only work with Python  
2.3+) The methods are PySetDate, PyGetDate, PySetLowerDateLimit,  
PySetUpperDateLimit, PySetDateRange, PyGetLowerDateLimit, and  
PyGetUpperDateLimit. Also, CalendarEvent was extended with PySetDate  
and PyGetDate methods."

http://docs.python.org/lib/module-datetime.html

ka

[Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions

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

Kevin Altis asked:

>In particular, I would like to 
>hear about features that products like FileMaker Pro provide that are 
>needed for an OS tool that users could transition to without feeling 
>like they are taking a step backwards.
>
 
I'd like to start more positively. My major client would forgive a great 
deal if he got more speed. And I'm pretty sure he will get it if I go 
down this, the Python/PythonCard, road. I start with this comment as 
much of what Filemaker does is probably not worth reproducing providing 
the user experience in the new environment is perceived as positive.

Filemaker 7 has just come out and it is much slower than version 6. On 
moving to OS X we already took a speed hit so, in the four years I have 
been working on this thing, instead of hardware improvements making 
things slick it has all got slower. On top of this, FM7 requires 
relearning much of what one has done + obliges a rewrite. Hence the 
reason my search is on.

I looked at many possibilities, some commercial, some open source. The 
reasons my quest has brought me here are:

1) I liked python from the moment I started to play with it.
2) one of the wx demos (then on OS X - now working mainly on a PC) 
showed some really rapid responsiveness to events.


Here is what Filemaker gives:

No need to define field lengths for any type of field. This seems 
trivial but gives an amazing freedom in database design.

Pretty maintenance free. Most sites have no database expert. I have 
never lost data (have come pretty close). However, no rollback.

Almost transparently cross platform - some font and printing issues. But 
client (as opposed to FM Server) not available on Linux. This latter is 
political as, now that the Mac is Unix based, doing the port would 
involve little work.

No connection hassles. FM mixes data, scripts, layouts and stuff all in 
one file per database (in FM7 this become per table).

An integrated form designer that, being designed for the purpose of 
databases, is pretty easy to use.
Same tool is used to design reports.

A relationship model that makes one to one, one to many, many to many, 
many to one relationships pretty easy to get a grasp of. (At least 
that's how it seems now, looking back).

Where SQL would use scripts (I believe) to select a group of records, FM 
frequently uses calculation fields as part of the relationship.

Calculations can appear in scripts as well as field definitions. These 
make great use of an extensive set of 'Status' functions.

FM is responsive to what is showing on the screen. If you haven't seen 
this it needs some explanation. If you go to a layout that contains 
references to another file(file = table in version < 7) then that file 
gets opened. If you open that layout in a small window only what is 
showing and referenced gets opened.

Pretty neat pop-up lists that can be up to 64k characters (much more in 
v7). On clicking in a field that has a pop-up the list becomes live to 
the keyboard i.e. typing 'be' takes one to entries beginning with 'be'. 
These lists can be based on
a) custom values
b) a value list from another file
c) the values from a field
d) the values from a field via a relationship.
One pretty neat thing here is that a relationship can be defined from 
virtually anywhere - deep withing the creation of a value list or during 
field definition or script creation.

However, there is no inbuilt type-ahead searching.


What is horrible and nasty:

No event based scripting.

No automated field or layout creation. Nothing of this type can be done 
on the fly.

Can't get at the controls when some speed tweaks are needed.

Incremental back ups are difficult to implement. Built in back up method 
can be slow as much more than the raw data is getting backed up. Can 
export fields and specify just data fields. Problem is that this process 
cannot be dynamically scripted.

Wide area network performance is lamentable as, at start up, the whole 
caboodle has to be dragged over the wires before anything happens. (This 
is another one that would lead my client to accept re-learning an interface)

Every user has to have a full copy of FM - form designer, script maker 
et al included. This is expensive and adds unnecessary security risks 
(there is a so-called kiosk version but these are not net workable).

Limited ability to produce dynamic dialogues.

Poor documentation once above novice level. Poor response to bugs and 
queries from FM, the company. (Happily, there are a couple of good lists).

Can't save or access scripts as text so can't cut and past chunks.

Until v7, no application wide globals, no parameters for scripts (a 
nightmare).

Oh, I forgot - no variables. Filemaker uses what it call 'global fields' 
for this. A real pain.

No regular expression searches. No wildcards.

__________________-

Apologies if I have been too detailed or not enough.

With all those downers some of you must be wondering why there is 
hesitation. It is worth noting that most Filemaker developers are doing 
quite nicely. FM, once mainly a Mac thing, now has 80% of new sales on 
Windows. And sales are (or at least, were, up till v7) growing fast. 
Many of these new users are tempted in by the ease with which 
rudimentary databases can be produced. They then come searching for guys 
like me when things get more complicated (as they inevitably do),

Norman Winn

Re: [Pythoncard-users] generic container model

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

At 13:47 13/09/2004 -0700, Donnal Walter wrote:
><delurking>
>Aha! A critical insight. If I understand correctly this "flat"
>model also explains (at least in part) why sizers are problematic
>to implement in the framework. Ideally, each container should have
>a built-in sizer to which components are automatically added as
>they are added to the container. The kind of sizer should be
>determined by the container, and the parameters for each component
>should be passed like 'size' and 'pos' are now.

If PythonCard had a non-flat model, then it would be easier to change it to 
have explicit containers (each being a sizer of one kind or another).

But I think there's a more fundamental problem: it would require a 
different approach to laying out your GUI.  Using sizers kind of requires 
that you have a plan for the layout of controls, and can then describe a 
hierarchy of sizers and place controls within them. This is, I think, 
rather contrary to the freedom that PythonCard gives you to rapidly 
prototype and play with different controls and arrangements of them.

There's certainly a contradiction between the idea that you "place" 
controls (as in Pythoncard) versus "arrange the order and relative 
position" of controls, and let sizers shuffle them into their final (but 
dynamic) positions.

I've been playing around with sizers in Pythoncard; I've built a couple of 
"auto-sizer" functions that take a component layout as found in a resource 
file, and generate a reasonable first-cut at arranging those into sizers.

Basic idea is that it should take the component positions (and use some 
default assumptions about different components) to build a default set of 
sizers. This can be aided by some "hints" added to the component data 
(currently using "custom data" in the components, but if the idea ever gets 
anywhere, it might be possible to add something to the resource editor to 
support this more directly) to guide its actions.  The auto-sizer can then 
either just operate, or it can spit out the source code that will make 
equivalent simple sizer calls, and can therefore be the starting point for 
custom programming.

I was feeling quite optimistic about it a couple of weeks ago - and then 
got side-tracked. I'll work on it a bit more, and if I can come up with 
something that works well enough, and is easy to explain, I'll make it 
available to anyone who wants to play around with sizers.

-- Alex.

[Pythoncard-users] generic container model

[Donnal W. <don...@ya...>]

Kevin Altis" <al...@se...>
> There is no built-in support for the wx.Notebook class
> right now, which is what you would use to do a real tabbed
> interface. This is mostly due to PythonCard having a "flat"
> layout model rather than supporting a generic container
> model ...

<delurking>
Aha! A critical insight. If I understand correctly this "flat"
model also explains (at least in part) why sizers are problematic
to implement in the framework. Ideally, each container should have
a built-in sizer to which components are automatically added as
they are added to the container. The kind of sizer should be
determined by the container, and the parameters for each component
should be passed like 'size' and 'pos' are now. (Another useful
parameter for each component would be a data model from some kind
of abstraction layer.)

> ... where you could have a different layout in each notebook
> tab/page. This has been discussed a number of times on the
> mailing list and is obviously a big missing feature, but I
> don't really know how to support it correctly. There was one
> attempt to incorporate this into the framework and
> resourceEditor, but it was never incorporated into the main
> cvs code or updated for release 0.8.
>
> It is probably time for a separate discussion thread on the
> issues and possible solutions such as treating each page as
> a type of child window where only the components of the child
> window resource are used. I'm just brainstorming here. ...

Brainstorming further, I would suggest that for PythonCard *2.0* a
class-based rather than an instance-based framework be considered.
Each container would be defined as a *class* (with an appropriate
resource-file notation, something other than a dictionary), such
that multiple instances could be created if so desired. In either
case, however, as the class is instantiated (initialized) the
parent-child relationships are established as well as sizer
relationships.

> ... You would end up with a separate source and resource file
> for each tab/page. I guess the references to each tab layout
> would end up being something like  
> self.components.notebook[0].components.field1, etc. where
> each page (window) of the notebook is referenced via a list.

In a class-based framework, the top-level resource file would
import component resource files as they are needed. Just a thought.
</delurking>

Regards,
Donnal Walter
Arkansas Children's Hospital

Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions

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

On Sep 13, 2004, at 11:57 AM, bra...@om... wrote:

> Good; that's what I was hoping to hear. Over the past couple of days,  
> I've found ways to do some of those things, though I didn't see a  
> widget for a tabbed interface in Resource Editor, and am not clear on  
> how to produce a contextual menu.
>
There is no built-in support for the wx.Notebook class right now, which  
is what you would use to do a real tabbed interface. This is mostly due  
to PythonCard having a "flat" layout model rather than supporting a  
generic container model where you could have a different layout in each  
notebook tab/page. This has been discussed a number of times on the  
mailing list and is obviously a big missing feature, but I don't really  
know how to support it correctly. There was one attempt to incorporate  
this into the framework and resourceEditor, but it was never  
incorporated into the main cvs code or updated for release 0.8.

It is probably time for a separate discussion thread on the issues and  
possible solutions such as treating each page as a type of child window  
where only the components of the child window resource are used. I'm  
just brainstorming here. You would end up with a separate source and  
resource file for each tab/page. I guess the references to each tab  
layout would end up being something like  
self.components.notebook[0].components.field1, etc. where each page  
(window) of the notebook is referenced via a list.

You'll also need to do the context (popup) menu yourself. For that you  
just create a wx.Menu in a on_somecomponent_mouseContextUp event  
handler or mouseContextClick in the case of a MultiColumnList. If you  
look at the fpop.py code in cvs you'll see an example of this

http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/ 
fpop/fpop.py

The relevant methods are initContextMenu and  
on_mclHeaders_mouseContextClick. fpop is not included as part of the  
normal PythonCard releases because it is too rough to allow out in the  
wild and people could end up deleting email accidentally.

ka

Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions

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

Steven D'Aprano <st...@cy...> wrote on 09/13/2004 05:45:35 AM:

> On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote:
> 
> > Here is the first question: Am I crazy for considering PythonCard for 
> > use in a production environment? PythonCard is obviously not yet 
> > mature, and still has many gaps in the feature set, not to mention 
> > bugs. On the plus side, it seems to me that when users report bugs on 
> > this mailing list, they are generally identified quickly and fixed. 
> > It also seems to me that if we run into problems or gaps in the 
> > PythonCard feature set, we can fall back on the more mature wxPython, 
> > and so have a mix of wxPython and PythonCard in our GUI logic. Also, 
> > because PythonCard is open source, we can look under the hood figure 
> > out what's wrong if we need to.  Is this a fair assessment?
> 
> It sounds like you've already answered your own question. Perhaps you 
are 
> looking for something that you can take to your bosses and show them a 
> "real" [cough] application, something with grunt.

Well, FileMaker was ok when our needs were simpler, but it didn't scale 
well as our application grew in complexity. FileMaker 7 addresses some of 
these issues, but we'd be looking at a complete rewrite. Meanwhile, most 
of the other company databases are on SQL Server, so it makes sense to 
move in that direction. And, yes, Python has a lot more "grunt" than 
FileMaker. 

> Perhaps not quite Microsoft Office written in PythonCard, but something 
> like MYOB or Quickbooks?

This is a custom in-house application; it won't have the sophistication of 
a commercial app, but it does need to be stable and have a streamlined 
user interface to allow users to work quickly (web interfaces are too slow 
and limited, and don't have access to the local filesystem on Macs).

> > Second question: Do you see PythonCard as primarily a tool for 
> > building GUIs for small, simple apps, or do you think it will scale 
> > well to more complex apps, in terms of managing that complexity ? 
> > The app I'm imagining will require many windows, many dialog boxes, 
> > dynamically changing global menus, contextual menus, keyboard 
> > shortcuts (including function keys), and validation for data entry 
> > fields. It would also be nice but not required to have search results 
> > that populate as the user types, layouts changing within a given 
> > window, tab order between fields, drag & drop of files onto fields to 
> > populate paths, user-draggable icon objects, and tabbed interface in 
> > some windows.
> 
> That sounds less like a question about PythonCard itself and more like a 

> question about your ability to design and manage the GUI. Unless I'm 
badly 
> mistaken, PythonCard can provide all of those interface objects.

Good; that's what I was hoping to hear. Over the past couple of days, I've 
found ways to do some of those things, though I didn't see a widget for a 
tabbed interface in Resource Editor, and am not clear on how to produce a 
contextual menu.

> Can PythonCard talk to your database (assuming you have one)? Knock up a 

> quick test to see. If it fails, again you've saved yourself a lot of 
time.

I'm not concerned about PythonCard connecting to the database; that's a 
job for Python itself.

> The idea is, before you commit to 1000 man-hours to build the 
application, 
> commit to 30 hours to build a few test apps and run some benchmarks.

I will do as you advise, and build a test application; thanks! 

[Pythoncard-users] Re: [Pythonmac-SIG] quicktime info?

[Arthur E. <ar...@ia...>]

On Sep 13, 2004, at 18:08, Kevin Altis wrote:

>>> looked around the archives and documentation, but can't find 
>>> information on how to use some very limited quicktime functionality.
>>>
>>> The main functionality I need are the movieplayer to load a sound 
>>> file, duration and position information.
>>>
>>> I like to add this an existing pythoncard application, so I suspect 
>>> a PyObjC solution is out the door?
>>
>> Well, I'm in the process of developing wxQtMovie for wxPython, which 
>> should already do what you need. (There's also wxSound, though I 
>> don't think you can get duration or position information with it.) 
>> Since pythoncard uses wxPython underneath, I think all that's needed 
>> is for Kevin A. to make the class accessible from pythoncard itself. 
>> I'm forwarding this to wxPython developer's list so that we can 
>> discuss this further and work out a solution.
>>
> PythonCard already wraps wx.Sound with its own Sound class in 
> PythonCard/sound.py that is demonstrated by the sound sample 
> application. There is another sample application, mp3player that uses 
> the PyGame movie module to play MP3 files and the PyGame movie module 
> definitely lets you do all the positional manipulation for MPEG. On 
> the QuickTime front, as soon as Kevin O.'s module is part of the 
> general wxPython distribution I will make a wrapper component for it, 
> so maybe wxPython 2.5.2.9?

yes, I tried the mp3player example, but diverted to using pygame.mixer 
as I need more channels and .wav and .aif support. I have this working, 
but sound.get_length() gives an attribute error.. (mailed the issue to 
the pygame list). So when Kevin O. will have quicktime working in wx, 
that would be perfect for my app -> can we test this?

Anyway, here's the relevant -commented out- code from the mp3player, 
but that works fine for me.

         ## NOTE WE DON'T IMPORT PYGAME UNTIL NOW.  Don't put "import 
pygame" at the top of the file.
         import pygame
         self.movie = pygame.movie.Movie(filename)
         self.movie.play()

         # it was a good idea at first, but mixer simply doesn't work, 
at least on the Mac
##        assert os.path.exists(filename)
##        from pygame import mixer
##        mixer.init(44100, 2)
##        mixer.music.load(filename)
##        mixer.music.play()
##        print mixer.music.get_busy()
##        #time.sleep(5)
##        #mixer.music.stop()

Why do you say in the first line pygame shouldn't be imported at an 
earlier stage in the code?

Arthur

Re: [Pythoncard-users] MultiColumnList questions

[Arthur E. <ar...@ia...>]

On Sep 13, 2004, at 16:54, Kevin Altis wrote:

> Sorry, I forgot to tell you that you also need a file named 
> __init__.py in the appcomponents directory in order for the 
> appcomponents directory to act as a package; that's how Python works. 
> Just make a new blank file or copy the one that is already in the 
> components directory.

that worked fine, thanks.

There's one observation, probably a wxPython issue. When the heading is 
disabled, suddenly the scollbar at the right of the control becomes 
fully visible. Before, the lower button was just partly visible. I 
suspect the length of the scrollbar is wrongly calculated, the vertical 
size of the heading, when the heading is enabled. (on OS X)

Another visual anomaly, a StaticText control doesn't clip the length of 
text beyond it's horizontal size.

So far, start to like PythonCard as a replacement for my RealBasic 
development. When over time more of wxPython is incorporated and the 
IDE will be improved, it will be a terrific replacement for Rb. No more 
suffering the realbasic language, python is far superior imo.

Thanks for your efforts!

Arthur

Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions

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

A long message deserved a long reply, so...

The primary benefit of Open Source (OS) is not the cost of the 
frameworks, tools and applications. The key issue on whether to use OS 
or proprietary tools is control. In terms of Python you know that the 
language isn't going to go away and it will continue to work on all 
major platforms for a long time, which you can't say for some of the 
smaller proprietary company solutions. wxWidgets and wxPython are 
getting better and much better supported financially each year, 
especially with large OS projects like Chandler funding development; 
Robin Dunn is a full-time employee of the OSAF. Whether you need all 
the control that an OS solution gives you is a business decision that I 
can't answer for you, but in general I think it is the right direction.

On Sep 11, 2004, at 10:59 AM, Brad Allen wrote:

> Hi. I've been spending the last few days taking a look at PythonCard, 
> and I really like it. Kudos to Kevin, Dan, and the rest of you guys 
> for your generosity in building such a nifty open-source tool and 
> continuing to plug away at improving it. I'm a Python newbie of about 
> six months, but I found PythonCard .8 to be very approachable.  It 
> didn't take long to install and get the samples working. The tutorial 
> walkthroughs were essential to helping me learn the basics, even 
> though there were some bumps along the way (some small changes are 
> needed to update the tutorials for .8, such as the reference to 
> on_openBackground).
>
> I was looking at PythonCard as a prospective GUI tool for a project at 
> work. This project is a client-server-database application designed to 
> replace an aging FileMaker solution with a MS SQL Server solution for 
> the IT dept database. We need a full client app, not just a web 
> interface, and it needs to be cross-platform so it can run the GUI on 
> all the computers we manage. We also don't want to spend a million 
> years building it, so a scripting approach makes sense rather than 
> trying to do it in C++ or Java. So, that leaves us with choices like 
> Runtime Revolution, RealBasic, Omnis Studio, etc. Or, we could go with 
> open source tools like Perl, Python, Ruby, etc. For a variety of 
> reasons, we really like Python the best among these choices, and a 
> pure Python solution is likely to be a fairly practical and scalable 
> approach as our app grows in complexity. We've used Python shell 
> scripts in our environment to great success; it seems like a very 
> approachable cross-platform language with many virtues.
>
> The only trouble with Python is that it's not so easy to build GUIs. 
> At least, not as easy as in proprietary platforms like RunRev, 
> FileMaker, and RealBasic. We have a serious learning curve to climb on 
> that front. At least, that's what I thought until I tried PythonCard. 
> I've already been able to make a little headway prototyping the client 
> app in PythonCard, though I have a long ways to go in really 
> understanding the capabilities available in PythonCard. So, I have a 
> number of questions, but before I dig in too much deeper, I'd like to 
> get some opinions on a couple of basic questions.

You are correct that the proprietary tools still have the edge on 
integration of the the IDE/design environment and that is unlikely to 
change in the short-term, say the next six months to a year. There is 
simply more money and manpower, project Q&A, feedback from customers, 
etc. There are quite a few people that work part-time on PythonCard, 
but it isn't like anyone is full-time or working towards a specific 
project feature set or ship date, it just evolves as people get time 
and their interests motivate them to contribute.

"Customer feedback" on PythonCard is actually pretty minimal 
considering that there are 260+ people on the mailing list. Most of the 
discussions on this list are support-related, either bugs or people 
trying to figure out how to do something within PythonCard. I think I'm 
generally pretty responsive to issues that people bring up, but if 
nobody is talking about design, UI features or other things they want 
to see in the project, then I just move at my own pace and treat myself 
as the customer :)

I would love for us to get to the point that PythonCard had a really 
nice environment so that someone could write a book "PythonCard for 
Visual Basic Users" or something like that, but realistically the 
environment is just too clunky right now, so maybe we'll get there in 
2005.

> Here is the first question: Am I crazy for considering PythonCard for 
> use in a production environment? PythonCard is obviously not yet 
> mature, and still has many gaps in the feature set, not to mention 
> bugs. On the plus side, it seems to me that when users report bugs on 
> this mailing list, they are generally identified quickly and fixed. It 
> also seems to me that if we run into problems or gaps in the 
> PythonCard feature set, we can fall back on the more mature wxPython, 
> and so have a mix of wxPython and PythonCard in our GUI logic. Also, 
> because PythonCard is open source, we can look under the hood figure 
> out what's wrong if we need to.  Is this a fair assessment?

That's pretty fair. I've said that the current goal is to have a 
PythonCard 1.0 release not long after wxPython 2.6 is released, 
hopefully by the end of this year or early 2005, depending on 
wxWidgets/wxPython. Until then, every release of PythonCard will track 
the latest wxPython release and you can expect some API or resource 
file format changes between releases. All of the changes will be 
documented, but you should expect to have to update your code with each 
release. That shouldn't be a big deal for a single project given that I 
keep all the samples and tools up-to-date with each release and that is 
probably a lot more code to manage than your own project <wink> By 1.0, 
I mean that the framework API will be "done" and future 1.x releases 
won't break backwards compatibility. The tools will continue to change 
and improve with future 1.x releases since that doesn't impact user 
code.

> Second question: Do you see PythonCard as primarily a tool for 
> building GUIs for small, simple apps, or do you think it will scale 
> well to more complex apps, in terms of managing that complexity ? The 
> app I'm imagining will require many windows, many dialog boxes, 
> dynamically changing global menus, contextual menus, keyboard 
> shortcuts (including function keys), and validation for data entry 
> fields. It would also be nice but not required to have search results 
> that populate as the user types, layouts changing within a given 
> window, tab order between fields, drag & drop of files onto fields to 
> populate paths, user-draggable icon objects, and tabbed interface in 
> some windows.

At a minimum, you will be able to bang out a hell of a prototype that 
works on Linux, Mac OS X, and Windows. You will almost certainly have 
to resort to using raw wxPython code for your project, but everything 
you describe above is doable within wxPython and most with plain 
PythonCard. PythonCard definitely has a target audience and type of 
application that is generally smaller than what you're describing. It 
is difficult to simplify wxPython, as PythonCard attempts to do, and 
not lose some functionality at the same time. You may find at some 
point that you simply want to move to using pure wxPython, but then the 
transition from PythonCard to that should be relatively easy. People on 
the wxPython-users mailing list are working on much more complicated 
app solutions, including database apps. You will probably want to take 
a look at things like:

http://dabodev.com/about
http://www.gnuenterprise.org/

as well as evaluate Boa, wxGlade, wxDesigner, etc.

On the topic of database solutions, I'm extremely interested in that 
application space, though I don't really do much with databases, 
especially SQL databases day-to-day. In particular, I would like to 
hear about features that products like FileMaker Pro provide that are 
needed for an OS tool that users could transition to without feeling 
like they are taking a step backwards.

> I'd be grateful for any thoughts you can provide on this.
>
> Thanks!
>
> Brad Allen
> Omnicom Management Services
> Dallas, TX

ka

Re: [Pythoncard-users] MultiColumnList questions

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

On Sep 13, 2004, at 5:38 AM, Arthur Elsenaar wrote:

>
> On Sep 12, 2004, at 19:08, Kevin Altis wrote:
>
>> In general, if the PythonCard component doesn't support one of the 
>> styles supported by the underlying wxPython control, you'll have to 
>> subclass the PythonCard component or just modify it to suit your 
>> purposes. PythonCard will look for components in a directory called 
>> appcomponents in your main application directory before it loads from 
>> the default component list, so that can be used to override which 
>> version of a component is used if you want something 
>> application-specific. If you decide to provide you're own about the 
>> only thing you need to provide in the subclass is a replacement 
>> __init__ method, so just copy that from the original and change the 
>> style.
>>
>> In the case of this style, it is something that PythonCard really 
>> should support, so I'll make appropriate modifications to the 
>> multicolumnlist component and post something here once that is done.
>
> ok, added a directory 'appcomponents' next to my script, copied a 
> modified version of multicolumnlist.py in there. In the __init__ of 
> multicolumnlist.py, in line 92 I have added | wx.LC_NO_HEADER to the 
> rules.
>
> I still have headings, so I suspect the modified version is not 
> loaded. Any ideas what goes wrong here?
>
> Thanks, Arthur.
>

Sorry, I forgot to tell you that you also need a file named __init__.py 
in the appcomponents directory in order for the appcomponents directory 
to act as a package; that's how Python works. Just make a new blank 
file or copy the one that is already in the components directory.

There are logging messages in the PythonCard framework to show what 
components are loaded and from where, so if you run your application 
with the -l command-line option you'll get a pythoncard.log file or 
output to stdout with a line that looks something like:

DEBUG: : Mon Sep 13 07:48:07 2004: imported appcomponent multicolumnlist


PythonCard customization note:
Whether the output goes to stdout (the default) or not is controlled by 
a line in your pythoncard_config.txt file in 
~/pythoncard_config/pythoncard_config.txt on *nix systems, including 
Mac OS X or your My Documents/pythoncard_config/pythoncard_config.txt 
or similar user directory on Windows systems, which is roughly 
equivalent to the home directory on *nix. The relevant lines are:

    'logfile':'pythoncard.log',
    'logToStdout':True,

ka

Re: [Pythoncard-users] MultiColumnList questions

[Arthur E. <ar...@ia...>]

On Sep 12, 2004, at 19:08, Kevin Altis wrote:

> In general, if the PythonCard component doesn't support one of the 
> styles supported by the underlying wxPython control, you'll have to 
> subclass the PythonCard component or just modify it to suit your 
> purposes. PythonCard will look for components in a directory called 
> appcomponents in your main application directory before it loads from 
> the default component list, so that can be used to override which 
> version of a component is used if you want something 
> application-specific. If you decide to provide you're own about the 
> only thing you need to provide in the subclass is a replacement 
> __init__ method, so just copy that from the original and change the 
> style.
>
> In the case of this style, it is something that PythonCard really 
> should support, so I'll make appropriate modifications to the 
> multicolumnlist component and post something here once that is done.

ok, added a directory 'appcomponents' next to my script, copied a 
modified version of multicolumnlist.py in there. In the __init__ of 
multicolumnlist.py, in line 92 I have added | wx.LC_NO_HEADER to the 
rules.

I still have headings, so I suspect the modified version is not loaded. 
Any ideas what goes wrong here?

Thanks, Arthur.