pythoncard-users

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

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

>
>
>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.
>
>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?
>
>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.
>
>I'd be grateful for any thoughts you can provide on this.
>

I'm a little disappointed you didn't get a reply. I, like you, am 
playing with Python with almost the same hopes and intentions. I have a 
large Filemaker project which I could probably sell if I knocked it into 
shape. I understand that others have not replied as they are interested 
in the nitty-gritty of PythonCard. However, your questions, while 
directed at the PythonCard list, are at the heart of whether and when 
the big move from Windows and Mac platforms will take place. I have just 
been playing with Delphi as a magazine I bought had a screen capture 
project using it. I found, just like when I used Delphi previously, that 
when I want to add functionality, it invites me in. Why? There is 
extensive help, there are legion examples to be cut and paste. The IDE 
is consistent. The app builder just works. It is fast.

Now comes the difficult bit. Difficult as it feels wrong to criticise, 
however gently, those who give of their time and expertise freely. 
First, why is Python so good? The simple answer is that there is a 
controlling influence. Guido the guide (who has a sword up his sleeve).  
I think in this surmise lies the reason that going about using Python 
for large, professional projects does not just 'invite you in'. In this 
area there is no arbitrator, no coordinator. I expect there are strong 
reasons that there is a 'Boa Constructor' project, a 'PythonCard' 
project, a 'Glade' project and many, many others. It feels, from the 
outside looking in, that all these riches combined could give us better 
than Delphi. And if we had that the world would move to Python and the 
writing would be on the wall for the evil empire. Instead the latter are 
issuing free versions of the .net tools, Novell fosters mono.net making 
it cross platform - the empire is fighting back and has formidable weapons.

There may be an answer at hand. What could unite the Python forces is 
money. Money to free the developers from other constraints. Where would 
the money come from? I would suggest the EU. They throw large sums of 
money around for much less useful things. If Guido the guide could be 
enrolled to take on not just the language but a standardised tool set 
and project builder then the EU would get an unheard of return on 
capital invested,

Norman Winn

[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

[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] 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 suitability for a project; looking for opinions

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

On Sep 15, 2004, at 6:07 AM, normanwinn wrote:

>
> A pretty neat design trick in Filemaker might be easily added to the=20=

> PythonCard resource editor. When an object is selected the arrow=20
> buttons move the object a pixel (or grid position) at a time.

Yeah that was on the to do list, so I just added it and checked the=20
change into cvs. It supports 1 pixel movement right now. I didn't feel=20=

like grappling with the calculation to figure the right relative grid=20
jump before I had some coffee, but I'll look at that later ;-)

> If I manage to get my Python up to speed I'd like to try to generate=20=

> the function definition header directly in the code by double clicking=20=

> the item or event in the resource editor - =E0 la Delphi. Good or bad=20=

> idea?
>

This is another topic that has been brought up before. Since the=20
resourceEditor doesn't deal with actually editing the code yet, events=20=

are not part of the attribute list since the assumption is that people=20=

will be using the codeEditor or some other editor to manipulate the=20
source code.

There is a codeEditorR.py program based on the codeEditor that has an=20
additional experimental feature. When you are editing a source file, it=20=

reads the associated .rsrc.py file and provides a dropdown menu of all=20=

the components. When you select one of the components from the menu, it=20=

populates the second dropdown menu with a list of all the events for=20
the component type. The events that are already defined have a + in=20
front of the name. If you select an item with a + in front, the cursor=20=

jumps to that event handler in the code. If you select an event that=20
isn't in your code, then an event handler stub for that event is=20
inserted at the current cursor location.

ka

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

[<gre...@co...>]

Kevin Altis wrote:

> On Sep 15, 2004, at 6:07 AM, normanwinn wrote:
> 
>>
>> A pretty neat design trick in Filemaker might be easily added to the 
>> PythonCard resource editor. When an object is selected the arrow 
>> buttons move the object a pixel (or grid position) at a time.
> 
> 
> Yeah that was on the to do list, so I just added it and checked the 
> change into cvs. It supports 1 pixel movement right now. I didn't feel 
> like grappling with the calculation to figure the right relative grid 
> jump before I had some coffee, but I'll look at that later ;-)
> 
>> If I manage to get my Python up to speed I'd like to try to generate 
>> the function definition header directly in the code by double clicking 
>> the item or event in the resource editor - à la Delphi. Good or bad idea?
>>
> 
> This is another topic that has been brought up before. Since the 
> resourceEditor doesn't deal with actually editing the code yet, events 
> are not part of the attribute list since the assumption is that people 
> will be using the codeEditor or some other editor to manipulate the 
> source code.

I'd love to have that feature.  Visual Basic does that too.  Where do I 
get this codeEditorR.py program?  Was it already installed with pyCard?

-Greg

> 
> There is a codeEditorR.py program based on the codeEditor that has an 
> additional experimental feature. When you are editing a source file, it 
> reads the associated .rsrc.py file and provides a dropdown menu of all 
> the components. When you select one of the components from the menu, it 
> populates the second dropdown menu with a list of all the events for the 
> component type. The events that are already defined have a + in front of 
> the name. If you select an item with a + in front, the cursor jumps to 
> that event handler in the code. If you select an event that isn't in 
> your code, then an event handler stub for that event is inserted at the 
> current cursor location.
> 
> ka
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
> Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
> Camcorder. More prizes in the weekly Lunch Hour Challenge.
> Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 

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

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

At 14:17 15/09/2004 -0400, Gregory Pi=F1ero wrote:

>I'd love to have that feature.  Visual Basic does that too.  Where do I=20
>get this codeEditorR.py program?  Was it already installed with pyCard?

It's in Pythoncard/tools/codeEditor

-- Alex.

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

[John <joh...@jo...>]

On Wed, 15 Sep 2004, Kevin Altis wrote:

> On Sep 15, 2004, at 6:07 AM, normanwinn wrote:
>
> >
> > A pretty neat design trick in Filemaker might be easily added to the
> > PythonCard resource editor. When an object is selected the arrow
> > buttons move the object a pixel (or grid position) at a time.
>
> Yeah that was on the to do list, so I just added it and checked the
> change into cvs. It supports 1 pixel movement right now. I didn't feel
> like grappling with the calculation to figure the right relative grid
> jump before I had some coffee, but I'll look at that later ;-)
>
> > If I manage to get my Python up to speed I'd like to try to generate
> > the function definition header directly in the code by double clicking
> > the item or event in the resource editor - =E0 la Delphi. Good or bad
> > idea?
> >
>
> This is another topic that has been brought up before. Since the
> resourceEditor doesn't deal with actually editing the code yet, events
> are not part of the attribute list since the assumption is that people
> will be using the codeEditor or some other editor to manipulate the
> source code.
>
> There is a codeEditorR.py program based on the codeEditor that has an
> additional experimental feature. When you are editing a source file, it
> reads the associated .rsrc.py file and provides a dropdown menu of all
> the components. When you select one of the components from the menu, it
> populates the second dropdown menu with a list of all the events for
> the component type. The events that are already defined have a + in
> front of the name. If you select an item with a + in front, the cursor
> jumps to that event handler in the code. If you select an event that
> isn't in your code, then an event handler stub for that event is
> inserted at the current cursor location.
>
> ka
>
Kevin this works on the samples but not on a project I converted by hand
fomr Pyhoncard prototype.

Is there something else I need to add to my source or resource to enable
this? Thanks.

-john
---------------------------------------------------------
Everything should be made as simple as possible, but not one bit
simpler.
Albert Einstein (attributed)