Menu
▾
▴
pythoncard-users
|
From: Kevin A. <al...@se...> - 2001-10-18 03:14:23
|
We're approaching the four month mark since the start of the PythonCard mailing list. This seems like a good time to evaluate where the project currently stands, whether we're on track, and what direction we should head in the future. Even the lurkers out there should respond in some fashion to this message if they're interested in the future direction of PythonCard. Issues in no particular order: Is anyone using the current prototype? We've had a reasonable number of downloads, but the list is very quiet. The apps I know about are the samples included with each release, some experiments of my own and Simon's blogger app. I'm probably forgetting something. Ron posted some source to the list and I'm assuming he is still experimenting with PythonCard. Is anyone else playing with PythonCard? Based on the current samples, is the current framework too complex or too limiting or just right? What elements need to be added to the current framework before you would use PythonCard for your own work? Is the most important thing having an environment like HyperCard? Project Roles The last update to the roles list was on July 12th, so it is out-of-date http://aspn.activestate.com/ASPN/Mail/Message/676720 At this point, I'm doing most of the work on the framework and samples. Patrick is working on PyCrust, which we use for our shell and namespace viewer. Andy is still active, but not on the framework. Both Neil and Robin answer questions, but otherwise are not currently involved in PythonCard code. Rowland is not active either, though we owe a debt to him for the original framework, ideas, etc. Rowland and I mostly chat about PythonCard outside the list. Roman helped start the distutils work, but Andy took that over. There have been a few people offering to get involved, but real life, work, etc. has overridden most of the good intentions. There is a limited amount we can accomplish without more developers. This will have an impact on the scope of the project, so if you're interested in a particular area please speak up. Documentation Suggestions for getting some docs done? Anything in particular you want in terms of documentation? The project name Is everyone happy with the name PythonCard? I wouldn't bring this up except that recently I learned a number of people had never even bothered to look at PythonCard because of the implied similarity to HyperCard. There are a lot of people out there that have never used a Mac and even if they have, a lot of people never liked HyperCard and considered it a toy for building apps. On the other hand, a lot of HyperCard users expect PythonCard to provide a complete environment, so the name doesn't reflect so much what we have today, but what we hope to achieve. It doesn't help that wxPython doesn't run on the Mac yet. Should we move beyond the prototype and make the next major release an alpha version of the real framework? How thin should the framework layer be over wxPython? That's a loaded question. The implication is that we will only be able to achieve our goals with wxPython instead of alternative GUI toolkits for Python. That may or may not be true. What do we want to achieve with our framework sitting on top of wxPython that wxPython doesn't provide? What parts of the framework are most important to you? Some possibilities: Layout descriptions in resource files Automatic widget creation and event binding Dot notation for widgets and other framework items on_widget_event style handlers runtime tools such as the shell, message watcher, property editor Are the samples useful? What do you want PythonCard to be? I definitely pushed PythonCard in the direction I thought it should go back in July and I'm going to continue to pursue PythonCard in some form, but it may be time to revise some of the original goals. I'll give other people a chance to respond before stating some of my own preferences. This is an open-ended post, so feel free to bring up any topic you think relates to the current state of PythonCard or its future even if I didn't touch on the topic above. ka --- Kevin Altis al...@se... |
|
From: Andy T. <an...@ha...> - 2001-10-18 12:08:09
|
Kevin, A stimulating post, my thoughts and suggestions are interspersed below but, in summary, I'm not giving up and I would hope the other subscribers to this list can spare enough time and/or brain cells to keep this project going. I think we have built something pretty great and would like to keep it going. Kevin Altis wrote: > We're approaching the four month mark since the start of the PythonCard > mailing list. This seems like a good time to evaluate where the project > currently stands, whether we're on track, and what direction we should head > in the future. Even the lurkers out there should respond in some fashion to > this message if they're interested in the future direction of PythonCard. > > Issues in no particular order: > > Is anyone using the current prototype? We've had a reasonable number of > downloads, but the list is very quiet. The apps I know about are the samples > included with each release, some experiments of my own and Simon's blogger > app. I'm probably forgetting something. Ron posted some source to the list > and I'm assuming he is still experimenting with PythonCard. Is anyone else > playing with PythonCard? I'm using it. I'm trying to test and stress it but am very happy to report that I haven't found any problems yet. Maybe I'm not looking in the right places, or maybe I'm just lucky. Whatever the reason I shall keep trying. > > Based on the current samples, is the current framework too complex or too > limiting or just right? It is a little complex to understand at first but once it all slots together I think we have a great operating model. My initial problems are probably due to my inexperience and no doubt some documentation would help. See my to do list at the end of this message. > > What elements need to be added to the current framework before you would use > PythonCard for your own work? 1. Multiple windows 2. Multiple windows 3. Multiple windows 4. Timers 5. There is no item number 5 6. Multiple windows > > Is the most important thing having an environment like HyperCard? I would say it is multiple windows ;-) > > Project Roles > The last update to the roles list was on July 12th, so it is out-of-date > http://aspn.activestate.com/ASPN/Mail/Message/676720 > At this point, I'm doing most of the work on the framework and samples. > Patrick is working on PyCrust, which we use for our shell and namespace > viewer. Andy is still active, but not on the framework. Both Neil and Robin > answer questions, but otherwise are not currently involved in PythonCard > code. Rowland is not active either, though we owe a debt to him for the > original framework, ideas, etc. Rowland and I mostly chat about PythonCard > outside the list. Roman helped start the distutils work, but Andy took that > over. There have been a few people offering to get involved, but real life, > work, etc. has overridden most of the good intentions. There is a limited > amount we can accomplish without more developers. This will have an impact > on the scope of the project, so if you're interested in a particular area > please speak up. > > Documentation > Suggestions for getting some docs done? Anything in particular you want in > terms of documentation? A users guide would be good I think, also a reference guide. I have started on the first steps towards a reference guide. Specifically I'm trying to generate the widget types and their valid attributes from spec.py into some form of HTML (first, then XML perhaps) but it isn't ready for public consumption yet. I'm really interested in generating large parts of documentation automatically but I'm not a huge fan of the complex solutions they are talking about over on the Doc-Sig (http://www.python.org/sigs/doc-sig), yet. > > The project name > Is everyone happy with the name PythonCard? I wouldn't bring this up except > that recently I learned a number of people had never even bothered to look > at PythonCard because of the implied similarity to HyperCard. There are a > lot of people out there that have never used a Mac and even if they have, a > lot of people never liked HyperCard and considered it a toy for building > apps. On the other hand, a lot of HyperCard users expect PythonCard to > provide a complete environment, so the name doesn't reflect so much what we > have today, but what we hope to achieve. It doesn't help that wxPython > doesn't run on the Mac yet. I'm happy with the name. As for the link with HyperCard turning people off, we do say on the project web page (http://pythoncard.sf.net) "This is a project to build a HyperCard like tool in, and using, the Python language" Maybe we could stress it more but the second sentence on our home page should be enough shouldn't it? My only suggestion would be to emphasise as often as possible that HyperCard is an inspiration, not a specification. Failing that, I believe the name 'Monty' was suggested back when this list was on Yahoo! and checking on sourceforge that project name isn't taken yet ;-) > > Should we move beyond the prototype and make the next major release an alpha > version of the real framework? That depends on what we decide the alpha release should include. I know thats a circular argument but what I think we need to do before anything else is state what we are trying to achieve. I know Kevin has an idea, as do I, of what we want from PythonCard (see below) and so probably does everyone else reading this list. What we haven't done recently is check whether we are all on the same page. Lack of posts to this list don't help of course, so shout out please everyone. > > How thin should the framework layer be over wxPython? That's a loaded > question. The implication is that we will only be able to achieve our goals > with wxPython instead of alternative GUI toolkits for Python. That may or > may not be true. What do we want to achieve with our framework sitting on > top of wxPython that wxPython doesn't provide? Simplicity. I looked briefly at wxPython (and tkinter, etc.) when I started to learn Python and ran away - very quickly. Necessarily these toolkits are very close to the os/hardware, which is great if you are writing Word or Mozilla but not if you are writing an order entry application (like I want to do). The decision to use wxPython was a pragmatic (and I think correct) one when we started out on the prototype and still holds true for me. Once we have a working framework with a consistent API we could look at the applicability of different backends but let us build the horse first before selecting a different cart. > > What parts of the framework are most important to you? Some possibilities: > Layout descriptions in resource files > Automatic widget creation and event binding > Dot notation for widgets and other framework items > on_widget_event style handlers > runtime tools such as the shell, message watcher, property editor In order; resource files, runtime tools, dot notation, modular architecture. Oh, and multiple windows. > > Are the samples useful? They are, but then I would say that wouldn't I. > > What do you want PythonCard to be? I want to be able to easily build small to medium sized GUI applications with as little (or as much as necessary) coding as possible. I only briefly used HyperCard but I've also used VB, Delphi, Oracle Forms, Powerbuilder, etc. and an easy to use version of those kind of app builders is what I am after. I'm mindful of the other tools under development as well though (specifically Boa and wxDesigner) and suggest we try and complement them rather than compete. I am also a fan of CP4E and think that PythonCard could address this requirement as well. Is it in line with my first requirement? Possibly, if you consider the shell and the resource editor. Ease of use should be our aim, 'kiss' (keep it simple stupid) our motto. > > I definitely pushed PythonCard in the direction I thought it should go back > in July and I'm going to continue to pursue PythonCard in some form, but it > may be time to revise some of the original goals. I'll give other people a > chance to respond before stating some of my own preferences. I hope I've added some fuel to the fire. I'd like to take this opportunity to thank Kevin, Patrick, Rowland, Neil, Robin, Roman (and anyone else I've forgotten) who have built something pretty wonderful in a few short months. I for one am not giving up on it. Even if we stopped work on the framework tomorrow we still have a valuable body of code to work with and on. As I've said to Kevin privately I don't feel qualified to play with the framework code but one of my aims whilst participating in this project is to acquire the knowledge to be able to do so. It would be easier if the folks who wrote the code are around to help me understand it though ;-) > > This is an open-ended post, so feel free to bring up any topic you think > relates to the current state of PythonCard or its future even if I didn't > touch on the topic above. > > ka > --- > Kevin Altis > al...@se... > As I promised at the top of this mail, here are the tasks I'm currently working on (or thinking about); Documentation. I'm trying to write some routines to automatically generate components of a reference guide. I think we also need to revise and expand the getting started guide that Kevin wrote and perhaps add a guide to how the framework is structured for people who wish to examine it (like me). Data store support. I'm trying to add support for CSV files and more varieties of relational databases (Gadfly, PostrgeSQL, Oracle) to the dbBrowser sample. My next step would be to try and fit one of these (probably Gadfly) into some kind of persistent storage layer for the framework as a whole. This slightly overlaps Patrick's investigations with ZODB but I think they don't overlap. I got a bit side tracked here as Gadfly doesn't operate 'out of the box' with Python 2.0+ and have started a thread on the DB-SIG mailing list about upgrading it. That has distracted me a bit but should benefit the wider Python community as well as, eventually, PythonCard. Improve the dbBrowser application. My target is to produce a useful general purpose RDMBS tool like TOAD (http://www.quest.com/toad). That's probably a little ambitous but I am shooting high. If I continue this application I may have to move it to wxPython but PythonCard is giving me a valuable head start. If I didn't have PythonCard I wouldn't have started on this path, reason enough for me to be thankful for PythonCard. Statement of requirements. We need one. If we know what we want, we know how far we have to go to get there. We started with a broad idea of which widgets and events we wanted to support when the prototype kicked off but now is a good time to more properly define our requirements. I've put my broad thoughts in this mail and am happy to discuss them with you all. Packaging. We have used distutils to create the packages which can be downloaded from SourceForge. Most of the good work was Roman's, most of the head scratching was mine. The documentation for distutils is bad, it provides a very limited example but never explains how it works or what its limitations are. I think we need to dig a little deeper into the structure of the standard utilities to make them more usable for PythonCard (subclassing is apparently the way to go but I haven't tried that yet). I also think some new documentation is required and I've started on that too. The activity level on the distutils-sig mail list makes this one look quite lively so I don't think we will step on any toes if we start to produce some more understandable documentation for a part of the standard library ;-) Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday |
|
From: Rowland S. <ro...@we...> - 2001-10-18 18:00:39
|
As Kevin indicated, I haven't been able to participate in the actual development of PythonCard since our code-fest way back in July. I'm very intrigued with the concept of building an extremly high level programming environment with a set of seamlessly integrated visual development tools. I liked HyperCard back in the day, at least up to a point. It was very easy to build simple to somewhat complex apps with HC. But I really believe that HC dropped the ball in re providing a truly OO programming environment ( you couldn't define classes with attributes and methods ) and also in not providing a component object model that allowed HC to be extensible with both visual and non-visual components. I'm no component expert, but for me that's definitely one of the requirements of an application development environment like PythonCard. Personally, I think the idea of saying we want to build something that is all that HyperCard was and more was too ambitious. Stepping back, maybe we should be saying something like: Let's build a framework that is powerful and flexible, yet doable by a small number of people, that we can then build upon to produce even more powerful and flexible apps like HyperCard, or a skinnable app builder, or an IDE, etc. My feeling is that the way to proceed is to step back and define less ambitious but more focused requirements, with an eye toward the future. Since this is an object-oriented software project, we're going to have to take those requirements and build a robust object model. The model needs to be very well defined before we even write a line of code to implement it. We know we can build whatever we can design - the protoytpe is proof of that. The next phase needs to be about stating exactly what we want to do, and then using the requirements to define very independent subsystems. So, what would I want in an application development environment? 1. A well defined component model that allows for flexible extension of the overall framework. 2. A high-level, well defined gui component model that can be implemented using one or more underlying gui toolkits - wxPython, GTK, Aqua, etc. The gui wrappers take a lot of time, but they make us think about how we really want to interact with gui components and give us the freedom to expose those behaviors and attributes that we feel are valuable in our own way. 3. A component communication model. The prototype uses events to communicate between components ( Widget objects ) and user scripts. But we really don't have a way for components to communicate with components - I'm not sure how to do that, but it seems important. 4. A flexible scripting framework that allows us to plug in different scripting models for different classes of application. We currently use a scripting model similar to VB ala method naming conventions. It's possible we could have multiple scripting models - one could be more Model-view-controller based. One could be based on action objects, etc. Oh yea, and Multiple Windows ( seriously ). Andy Todd wrote: > Kevin, > > A stimulating post, my thoughts and suggestions are interspersed below > but, in summary, I'm not giving up and I would hope the other > subscribers to this list can spare enough time and/or brain cells to > keep this project going. I think we have built something pretty great > and would like to keep it going. > > Kevin Altis wrote: > >> We're approaching the four month mark since the start of the PythonCard >> mailing list. This seems like a good time to evaluate where the project >> currently stands, whether we're on track, and what direction we should >> head >> in the future. Even the lurkers out there should respond in some >> fashion to >> this message if they're interested in the future direction of PythonCard. >> >> Issues in no particular order: >> >> Is anyone using the current prototype? We've had a reasonable number of >> downloads, but the list is very quiet. The apps I know about are the >> samples >> included with each release, some experiments of my own and Simon's >> blogger >> app. I'm probably forgetting something. Ron posted some source to the >> list >> and I'm assuming he is still experimenting with PythonCard. Is anyone >> else >> playing with PythonCard? > > > > I'm using it. I'm trying to test and stress it but am very happy to > report that I haven't found any problems yet. Maybe I'm not looking in > the right places, or maybe I'm just lucky. Whatever the reason I shall > keep trying. > >> >> Based on the current samples, is the current framework too complex or too >> limiting or just right? > > > > It is a little complex to understand at first but once it all slots > together I think we have a great operating model. My initial problems > are probably due to my inexperience and no doubt some documentation > would help. See my to do list at the end of this message. > >> >> What elements need to be added to the current framework before you >> would use > > >> PythonCard for your own work? > > > > 1. Multiple windows > 2. Multiple windows > 3. Multiple windows > 4. Timers > 5. There is no item number 5 > 6. Multiple windows > >> >> Is the most important thing having an environment like HyperCard? > > > > I would say it is multiple windows ;-) > >> >> Project Roles >> The last update to the roles list was on July 12th, so it is out-of-date >> http://aspn.activestate.com/ASPN/Mail/Message/676720 >> At this point, I'm doing most of the work on the framework and samples. >> Patrick is working on PyCrust, which we use for our shell and namespace >> viewer. Andy is still active, but not on the framework. Both Neil and >> Robin >> answer questions, but otherwise are not currently involved in PythonCard >> code. Rowland is not active either, though we owe a debt to him for the >> original framework, ideas, etc. Rowland and I mostly chat about >> PythonCard >> outside the list. Roman helped start the distutils work, but Andy took >> that >> over. There have been a few people offering to get involved, but real >> life, >> work, etc. has overridden most of the good intentions. There is a limited >> amount we can accomplish without more developers. This will have an >> impact >> on the scope of the project, so if you're interested in a particular area >> please speak up. >> >> Documentation >> Suggestions for getting some docs done? Anything in particular you >> want in >> terms of documentation? > > > > A users guide would be good I think, also a reference guide. I have > started on the first steps towards a reference guide. Specifically I'm > trying to generate the widget types and their valid attributes from > spec.py into some form of HTML (first, then XML perhaps) but it isn't > ready for public consumption yet. > > I'm really interested in generating large parts of documentation > automatically but I'm not a huge fan of the complex solutions they are > talking about over on the Doc-Sig (http://www.python.org/sigs/doc-sig), > yet. > >> >> The project name >> Is everyone happy with the name PythonCard? I wouldn't bring this up >> except >> that recently I learned a number of people had never even bothered to >> look >> at PythonCard because of the implied similarity to HyperCard. There are a >> lot of people out there that have never used a Mac and even if they >> have, a >> lot of people never liked HyperCard and considered it a toy for building >> apps. On the other hand, a lot of HyperCard users expect PythonCard to >> provide a complete environment, so the name doesn't reflect so much >> what we >> have today, but what we hope to achieve. It doesn't help that wxPython >> doesn't run on the Mac yet. > > > > I'm happy with the name. As for the link with HyperCard turning people > off, we do say on the project web page (http://pythoncard.sf.net) "This > is a project to build a HyperCard like tool in, and using, the Python > language" > > Maybe we could stress it more but the second sentence on our home page > should be enough shouldn't it? My only suggestion would be to emphasise > as often as possible that HyperCard is an inspiration, not a specification. > > Failing that, I believe the name 'Monty' was suggested back when this > list was on Yahoo! and checking on sourceforge that project name isn't > taken yet ;-) > >> >> Should we move beyond the prototype and make the next major release an >> alpha >> version of the real framework? > > > > That depends on what we decide the alpha release should include. I know > thats a circular argument but what I think we need to do before anything > else is state what we are trying to achieve. I know Kevin has an idea, > as do I, of what we want from PythonCard (see below) and so probably > does everyone else reading this list. What we haven't done recently is > check whether we are all on the same page. Lack of posts to this list > don't help of course, so shout out please everyone. > >> >> How thin should the framework layer be over wxPython? That's a loaded >> question. The implication is that we will only be able to achieve our >> goals >> with wxPython instead of alternative GUI toolkits for Python. That may or >> may not be true. What do we want to achieve with our framework sitting on >> top of wxPython that wxPython doesn't provide? > > > > Simplicity. I looked briefly at wxPython (and tkinter, etc.) when I > started to learn Python and ran away - very quickly. Necessarily these > toolkits are very close to the os/hardware, which is great if you are > writing Word or Mozilla but not if you are writing an order entry > application (like I want to do). > > The decision to use wxPython was a pragmatic (and I think correct) one > when we started out on the prototype and still holds true for me. Once > we have a working framework with a consistent API we could look at the > applicability of different backends but let us build the horse first > before selecting a different cart. > >> >> What parts of the framework are most important to you? Some >> possibilities: >> Layout descriptions in resource files >> Automatic widget creation and event binding >> Dot notation for widgets and other framework items >> on_widget_event style handlers >> runtime tools such as the shell, message watcher, property editor > > > > In order; resource files, runtime tools, dot notation, modular > architecture. Oh, and multiple windows. > >> >> Are the samples useful? > > > > They are, but then I would say that wouldn't I. > >> >> What do you want PythonCard to be? > > > > I want to be able to easily build small to medium sized GUI applications > with as little (or as much as necessary) coding as possible. I only > briefly used HyperCard but I've also used VB, Delphi, Oracle Forms, > Powerbuilder, etc. and an easy to use version of those kind of app > builders is what I am after. I'm mindful of the other tools under > development as well though (specifically Boa and wxDesigner) and suggest > we try and complement them rather than compete. > > I am also a fan of CP4E and think that PythonCard could address this > requirement as well. Is it in line with my first requirement? Possibly, > if you consider the shell and the resource editor. Ease of use should be > our aim, 'kiss' (keep it simple stupid) our motto. > >> >> I definitely pushed PythonCard in the direction I thought it should go >> back >> in July and I'm going to continue to pursue PythonCard in some form, >> but it >> may be time to revise some of the original goals. I'll give other >> people a >> chance to respond before stating some of my own preferences. > > > > I hope I've added some fuel to the fire. I'd like to take this > opportunity to thank Kevin, Patrick, Rowland, Neil, Robin, Roman (and > anyone else I've forgotten) who have built something pretty wonderful in > a few short months. I for one am not giving up on it. Even if we stopped > work on the framework tomorrow we still have a valuable body of code to > work with and on. As I've said to Kevin privately I don't feel qualified > to play with the framework code but one of my aims whilst participating > in this project is to acquire the knowledge to be able to do so. It > would be easier if the folks who wrote the code are around to help me > understand it though ;-) > >> >> This is an open-ended post, so feel free to bring up any topic you think >> relates to the current state of PythonCard or its future even if I didn't >> touch on the topic above. >> >> ka >> --- >> Kevin Altis >> al...@se... >> > > As I promised at the top of this mail, here are the tasks I'm currently > working on (or thinking about); > > > Documentation. I'm trying to write some routines to automatically > generate components of a reference guide. I think we also need to revise > and expand the getting started guide that Kevin wrote and perhaps add a > guide to how the framework is structured for people who wish to examine > it (like me). > > Data store support. I'm trying to add support for CSV files and more > varieties of relational databases (Gadfly, PostrgeSQL, Oracle) to the > dbBrowser sample. My next step would be to try and fit one of these > (probably Gadfly) into some kind of persistent storage layer for the > framework as a whole. This slightly overlaps Patrick's investigations > with ZODB but I think they don't overlap. I got a bit side tracked here > as Gadfly doesn't operate 'out of the box' with Python 2.0+ and have > started a thread on the DB-SIG mailing list about upgrading it. That has > distracted me a bit but should benefit the wider Python community as > well as, eventually, PythonCard. > > Improve the dbBrowser application. My target is to produce a useful > general purpose RDMBS tool like TOAD (http://www.quest.com/toad). That's > probably a little ambitous but I am shooting high. If I continue this > application I may have to move it to wxPython but PythonCard is giving > me a valuable head start. If I didn't have PythonCard I wouldn't have > started on this path, reason enough for me to be thankful for PythonCard. > > Statement of requirements. We need one. If we know what we want, we know > how far we have to go to get there. We started with a broad idea of > which widgets and events we wanted to support when the prototype kicked > off but now is a good time to more properly define our requirements. > I've put my broad thoughts in this mail and am happy to discuss them > with you all. > > Packaging. We have used distutils to create the packages which can be > downloaded from SourceForge. Most of the good work was Roman's, most of > the head scratching was mine. The documentation for distutils is bad, it > provides a very limited example but never explains how it works or what > its limitations are. I think we need to dig a little deeper into the > structure of the standard utilities to make them more usable for > PythonCard (subclassing is apparently the way to go but I haven't tried > that yet). I also think some new documentation is required and I've > started on that too. The activity level on the distutils-sig mail list > makes this one look quite lively so I don't think we will step on any > toes if we start to produce some more understandable documentation for a > part of the standard library ;-) > > Regards, > Andy -- Talk to ya, Rowland "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." -- Bertrand Russell, quoted in the book A Word a Day |
|
From: Rowland S. <ro...@we...> - 2001-10-18 18:05:58
|
Oh yeah, failed to mention that I was initially one of the major
proponents of building something that does all that HyperCard can do and
more :)
--
Talk to ya,
Rowland
"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."
-- Bertrand Russell,
quoted in the book
A Word a Day
|
|
From: Patrick K. O'B. <po...@or...> - 2001-10-18 18:23:58
|
I'm confused. These goals sound more like what anygui is attempting than
what I thought PythonCard was all about. At the very least they sound like a
back-to-the-drawing-board approach. I don't think I have the energy for
that.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Rowland
Smith
Sent: Thursday, October 18, 2001 12:59 PM
To: po...@or...
Cc: pythoncard-Users
Subject: Re: [Pythoncard-users] the future direction of PythonCard
<snip>
So, what would I want in an application development environment?
1. A well defined component model that allows for flexible extension of
the overall framework.
2. A high-level, well defined gui component model that can be
implemented using one or more underlying gui toolkits - wxPython, GTK,
Aqua, etc. The gui wrappers take a lot of time, but they make us think
about how we really want to interact with gui components and give us the
freedom to expose those behaviors and attributes that we feel are
valuable in our own way.
3. A component communication model. The prototype uses events to
communicate between components ( Widget objects ) and user scripts. But
we really don't have a way for components to communicate with components
- I'm not sure how to do that, but it seems important.
4. A flexible scripting framework that allows us to plug in different
scripting models for different classes of application. We currently use
a scripting model similar to VB ala method naming conventions. It's
possible we could have multiple scripting models - one could be more
Model-view-controller based. One could be based on action objects, etc.
Oh yea, and Multiple Windows ( seriously ).
--
Talk to ya,
Rowland
"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."
-- Bertrand Russell,
quoted in the book
A Word a Day
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users
|
|
From: Rowland S. <ro...@we...> - 2001-10-18 18:34:39
|
Patrick K. O'Brien wrote: > I'm confused. These goals sound more like what anygui is attempting than > what I thought PythonCard was all about. At the very least they sound like a > back-to-the-drawing-board approach. I don't think I have the energy for > that. Good point. I know Kevin is in need of scaling things back so he can make more progress producing something that will allow him to write the kind of apps he's interested in. I'm definetely looking for something that's going to take a lot more time than anyone has right now. And I can't say exactly what I'd like to see as an end product. I still think we should treat the prototype as just that, and at least come up with some minimal model that will let just a few people make some good progress without burning too much time. Kevin, what's the biggest problem with the wrappers slowing you down? > > --- > Patrick K. O'Brien > Orbtech > "I am, therefore I think." > > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Rowland > Smith > Sent: Thursday, October 18, 2001 12:59 PM > To: po...@or... > Cc: pythoncard-Users > Subject: Re: [Pythoncard-users] the future direction of PythonCard > > <snip> > > So, what would I want in an application development environment? > > 1. A well defined component model that allows for flexible extension of > the overall framework. > > 2. A high-level, well defined gui component model that can be > implemented using one or more underlying gui toolkits - wxPython, GTK, > Aqua, etc. The gui wrappers take a lot of time, but they make us think > about how we really want to interact with gui components and give us the > freedom to expose those behaviors and attributes that we feel are > valuable in our own way. > > 3. A component communication model. The prototype uses events to > communicate between components ( Widget objects ) and user scripts. But > we really don't have a way for components to communicate with components > - I'm not sure how to do that, but it seems important. > > 4. A flexible scripting framework that allows us to plug in different > scripting models for different classes of application. We currently use > a scripting model similar to VB ala method naming conventions. It's > possible we could have multiple scripting models - one could be more > Model-view-controller based. One could be based on action objects, etc. > > Oh yea, and Multiple Windows ( seriously ). > > -- > Talk to ya, > Rowland > > "The whole problem with the world is > that fools and fanatics are always so > certain of themselves, and wiser people > so full of doubts." > > -- Bertrand Russell, > quoted in the book > A Word a Day > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > > > > -- Talk to ya, Rowland "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." -- Bertrand Russell, quoted in the book A Word a Day |
|
From: Neil H. <ne...@sc...> - 2001-10-18 12:18:46
|
Kevin: > Is anyone using the current prototype? We've had a reasonable number of > downloads, but the list is very quiet. I'm not currently using PythonCard. Much of my UI code is still done in low level C++ but that is just because of my context. If I wanted to do something at a high level, either as a mock-up or for-real I'd use browser based technologies. > Based on the current samples, is the current framework too complex or too > limiting or just right? The framework appears OK to me but ultimately, its not the framework that I'd expect to be the appealing feature but the development environment built on top. > What elements need to be added to the current framework before you would use > PythonCard for your own work? It is unlikely PythonCard could have been used for any of the work I have done recently or expect to do in the near future. Client needs often constrain technology choices. For the open source projects that I mostly control, Scintilla and SciTE, PythonCard does not appear to fit any need in a sensible way. SciTE (a text editor) could be written as a PythonCard application but it is already written in C++ so there is not much point. I have been thinking about building a demonstration web oriented development environment but that would be housed inside a web browser. A finished and high quality PythonCard would, for me, be useful in prototyping applications that are shown to clients and then reimplemented in C++ or Java. One enquiry that could have been demoed with PythonCard but didn't get anywhere near that far was to build a diagram editor for software design. > Is the most important thing having an environment like HyperCard? That is a very important aspect but another important aspect will be deployability. For big budget work, even complex deployment can be viable. For the sort of rapidly developed small tools that PythonCard could be used for, deployment should be very simple. > Project Roles [...] > Both Neil and Robin > answer questions, but otherwise are not currently involved in PythonCard > code. That is about as much as I can offer now. I can also do some small pieces of code to demonstrate techniques but can't really sign up for anything significant. > What do you want PythonCard to be? Cross-platform HyperCard with Python. Neil |
|
From: Patrick K. O'B. <po...@or...> - 2001-10-18 14:33:52
|
Having never used HyperCard, I don't feel particularly qualified to point in any particular direction and say "go that way." But I do think the current direction, however vague or grand, has produced some very nice results. It certainly motivated me to create PyCrust at a time when I was itching to prove that it was quite possible to create a wxPython-based shell using Scintilla in a reasonable timeframe and with competitive features[1]. Now my interest is in creating applications using ZODB as the persistence mechanism. Between Andy working on relational storage and me working on object storage we should be able to meet the PythonCard requirement of multiple windows and transparent saves. The work on ZODB has been slow, because not many people are using it outside of Zope. Therefore, I'm having to build up a toolkit as I go[2]. Whatever I come up with should be usable within PythonCard in some fashion. Personally, I think it might be easier to get momentum going if we defined the minimum set of features required to release a version of PythonCard that people could commit to and start using. Then we can add features and rework things as we go. For me, my pet project right now is creating one or two simple sample applications using ZODB for storage. The first one I'm working on is called NoteKeeper, and will probably be a simple outliner/PIM/organizer. It will likely have just two classes at first, Folder and Note. A folder can contain other folders in your basic hierarchy. A folder can also contain any number of notes, which are just text blobs. With this foundation, it should be possible to store todo lists, calendars, projects, outlines of any sort, etc. We'll see where it goes beyond that. So for me, the focus will be on getting this app created. Anything PythonCard has that makes this easier will make me happy. Anything that PythonCard is missing will make me mad. If I get mad enough, I end up writing code that makes me happy. Lather, rinse, repeat. <wink> That's my two bits. I'm in this for the long haul. Pat [1] The CVS version of PyCrust now has full support for multi-line commands. You can scroll back to any line of a multi and the whole command is copied down where it can be modified, including adding and deleting lines. The command history retrieval functions (Ctrl-Up or Alt-P, Ctrl-Down or Alt-N, F8) all retrieve entire multi-line commands as well. The retrieval method has been modified as well so that retrieved commands are inserted into the existing command (and highlighted), making it easier to build new commands that make use of old commands. Give it a try and let me know if anything breaks. [2] My ZODB toolkit and sample applications are available at http://sourceforge.net/projects/orbtech/. At this time they are only available in CVS, and are in a state of constant modification as I figure out what I'm doing with ZODB. --- Patrick K. O'Brien Orbtech "I am, therefore I think." |
|
From: Ronald D S. <rd...@ea...> - 2001-10-18 23:36:42
|
I am not qualified technically to have an opinion, so please disregard evrything I say if it does not apply or if it annoys. Still I admire what you all are doing, especially Kevin, and I wish you the best. I'd lvoe to see PythonCard do great things, but I know I probably can't contibute anything to it. With those caveats, here goes: My interest has always been to see a very easy to learn and easy to use event driven GUI builder. When I was trying to choose between wxPython and Tkinter, someone brought up the idea of HyperCard. Although I never owned a Mac and therefore never used HyperCard, I was generally aware of it and had a good impression of it. PythonCard seemed like a great idea. I have used the PythonCard prototype, primarily to try to create a GUI version of a simple program I wrote in Python called Decision Analysis, which can be found at http://www.awaretek.com/Decision_Analysis_Beta27.py but which I have updated and cleaned up a lot but not posted yet to my webswite, so I will attach that code at the end of this message. Well, in playing around with PythonCard in order to create a GUI version of Decison Analysis, I began to study wxPython and then Tkinter a little more, to the point where I think I could now do a gui version of Decision Analysis in Tkinter easier than I could in PythonCard (at this stage of PythonCard). The reason being that, to me, at its current stage, PythonCard seems more complicated than wxPython or Tkinter. And with Tkinter being so well documented, it would be the easiest for me. And I wouldn't have to use resource files at all, which to me only complicate things. I assume that when PythonCard is finished, including documentation of some sort and an "environment" it will be easier and better for me. On top of that for now, I am all of a sudden consumed in my hobby-dom more by writing an "major " ;-))) extension of Decision Analysis that answers questions of fact by making web queries using Pythons url libraries and the re module for regular expressions. Which brings up a point: The reason I love programming in Python is becauase I can remember the syntax more or less completely, even as a weekend duffer, and just code things that are interesting to me. I think there are potentially millions (OK , at least hundreds of thousands) of folks like me, in that they will program for the love of it, but not if the programming tools require more "drudge" work than they are worth. So what the world needs, I think, is a "python" for gui event driven programs. I hope PythonCard can be that. I have never really used VB, although I did buy version 1.0 years ago; but it was not all that inviting at that time. I have never used Delphi/Kylix. So I guess you can say that I have almost no gui programming experience at all. I have played around with Boa and I like it; but it does not yet meet my desire for a "python" like gui programming expereince. Can PythonCard be a "python" like easy to learn and use gui programming tool? I can't resist showing my ignorance by speculating: 1. Visual Basic and Delphi and even Boa Constructor are one class of very visual gui programming tools, let's say. But Boa is already attempting this for Python, so why should anyone duplicate it? Besides, Kevin, your stated dislike for code generators tends to work against this sort of approach. Besides, Boa seems over complicated anyway. 2. HyperCard, as I imagine, in my ignorance, it must be, seems to be another kind of visual programming tool. An awful lot of folks who used it loved it, so it had something going for it. While I never used it, I find the general idea of a card like metaphor appealing. (As an aside, I still use an old M$ windows 3.0 applet called cardfile as a roll o dex type database of business contacts, phone numbers etc. Everybody knows how to use a rolodex) How would a HyperCard like PythonCard work? a. Could it use a metaphor in which each card was an object? That seems simple and appealing to me, but I have no idea if it make sense; and would it require mixing data with code? Not necessarily, because each card could contain its own widgets, including their associated event-handlers; but the whole stack of cards comprising a program could be scripted by one master Python program. b. Alternately, could each card be a Class? I guess I like (a.) better, but anyway using a HyperCard like metaphor would sure be nice. 3. Or, one could avoid the visual metaphor entirely. After all, Python itself is not Visual and it certainly meets my criteria for ease of learning/use. Who says a command-line gui programming tool could not be the easiest and best of all? Truthfully, in my ignorance, I don't see why this could not be done. Just give me simple widget names, event names and definitons, etc. Ideally, I could envison a PythonCard that used both (2) and (3) of my above options in combination; that is, a hyperCard like visual metaphor combined with a truly good command line python-like tool. Most of all, it should be consistent and make sense intuitively. But, if there is no HyperCard like metaphor at all, maybe the name should be change. I do think names are important, by the way. But if a card like metaphor of any kind is used, I would suggest keeping the PythonCard name, which I really like. Finally, I am sure you are going to create somethng great, Kevin. If the great thing you create happens to be an easier to learn/use gui creator than wxPython, I am pretty sure I'll be using it and enjoying it. Oh, one other thing; I think wxPython is the right base for PythonCard. It was the best choice. Why ry to support more than one gui foundation, it will only create alot of extra work? Finally, and most importanly to me, if there is any one idea I would like to contribute or endorse or back up, it is this. I hope that Kevin can get a lot of help. And I think one best way, I am hoping anyway, is for some one or few coders can join in to focus on the highest level programming environment or IDE aspect of PythonCard. cp...@em... (Chris Ryland) spoke up recently and expressed an interest in possibly coding a Real Basic like Python tool. If he could be coaxed into joining up with PythonCard and focus almost exclusively on the high end environment, wouldn't that be great? Why do another visual tool like Boa. Maybe Cris Barker could also join in. Most of all, it should be consistent and make sense intuitively. A Tall order, no doubt!!! ;-))))) Ron Stephens P.S. What one thing would I most like to see done next? ...a High End easy to use programming environment of some sort. Decision Analysis: print "A General Decision Analysis Program." print print "Have You Ever Had to Make Up Your Mind?" print import sys def get_number(prompt, lower=sys.maxint * -1, upper=sys.maxint): """ get_number(prompt) -> float This function prompts for a number. If the user enters bad input, such as 'cat' or '3l', it will prompt again. Now checks for upper and lower bounds. """ res = None while res is None: try: res = float(raw_input(prompt)) try: assert lower <= res <= upper except AssertionError: print "Value must be between", lower, \ "and", upper res = None except ValueError: pass return res def get_list(heading, prompt): print heading print print "(enter a blank line to end the list)" ret = [] i = 1 while 1: line = raw_input(prompt % i) if not line: break ret.append(line) i=i+1 print return ret def get_user_rankings(criteria): # Next, get the user to rank his criteria. I use a system where higher # is better, so that an undesirable characteristic can be given a negative # weight. # # {} is a dictionary, it can be indexed by (nearly) any expression, # and we will index it with the names of the criteria. rankings = {} print print "Enter relative importance of criteria (higher is more important)" print for c in criteria: rankings[c] = get_number("Criterion %s: " % c) return rankings def get_user_scores(options, criteria): # Next, get the user to score each option on all the criteria. # Scores are stored as a two-dimensional dictionary, like so: # {'option1': {'criteria1': 100, 'criteria2': 10}, # 'option2': {'criteria1': 50, 'criteria2': 10} # } scores = {} print print "Enter score for each option on each criterion" print for o in options: scores[o] = {} print print "Scores for option %s" % o print for c in criteria: scores[o][c] = get_number("Criterion %s: " % c) return scores def calculate_results(options, scores, rankings): # Calculate the resulting score for each option. This equation # is different from Rod Stephen's original program, because I # make more important criteria have higher rankings, and even let # bad criteria have negative rankings. # The "result" dictionary is indexed with the names of the options. result = {} # Criteria can be found automatically, doesn't need to be # passed as an argument. criteria = scores[options[0]].keys() for o in options: value = 0 for c in criteria: # print o, c, rankings[c], scores[o][c] value = value + rankings[c] * scores[o][c] result[o] = value return result def ranked_list(results): # Now, I want to take the dictionary result, and turn it into a ranked list results = results.items() # A list of tuples (key, value) results.sort(lambda x, y: -cmp(x[1], y[1])) # Sort the list using the reverse of the # "value" of the entry, so that higher # values come first return results def generic_decision_analyzer(options, criteria): pass def decisionanalysis(): # This code is placed in the public domain print print "This is a general decision program, and you can define your choices and criteria." print print "When prompted, please enter the options or choices that you need to decide amongst." print print "Then, when prompted, enter the criteria for making this decision." # First, ask the user to enter the lists options = get_list("Enter your options:", "Option %d: ") criteria = get_list("Now, enter your criteria:", "Criterion %d: ") print "A program to help you make decisions." rankings = get_user_rankings(criteria) scores = get_user_scores(options, criteria) results = ranked_list(calculate_results(options, scores, rankings)) print print "Results, in order from highest to lowest score" print print "%5s\t%s" % ("Score", "Option") # Take the pairs out of results in order, and print them out for option, result in results: print "%5s\t%s" % (result, option) # Here's the scores used by the language-choice functions. language_scores = {"Python": {"ease of learning":100, "ease of use":100, "speed of program execution":10, "quality of available tools":70, "popularity":50, "power & expressiveness":100, "cross platform?":100, "cost":100}, "Perl": {"ease of learning":50, "ease of use":60, "speed of program execution":20, "quality of available tools":50, "popularity":85, "power & expressiveness":70, "cross platform?":100, "cost":100}, "Ruby": { "ease of learning":50, "ease of use":100, "speed of program execution":20, "quality of available tools":20, "popularity":10, "power & expressiveness":100, "cross platform?":80, "cost":100}, "Tcl": {"ease of learning":100, "ease of use":100, "speed of program execution":10, "quality of available tools":50, "popularity":40, "power & expressiveness":10, "cross platform?":100, "cost":100}, "JavaScript": {"ease of learning":70, "ease of use":75, "speed of program execution":10, "quality of available tools":50, "popularity":100, "power & expressiveness":40, "cross platform?":50, "cost":100}, "Visual Basic": {"ease of learning":50, "ease of use":100, "speed of program execution":20, "quality of available tools":100, "popularity":100, "power & expressiveness":50, "cross platform?":1, "cost":1}, "Java": {"ease of learning":15, "ease of use":50, "speed of program execution":50, "quality of available tools":100, "popularity":90, "power & expressiveness":100, "cross platform?":100, "cost":100}, "C++": {"ease of learning":10, "ease of use":25, "speed of program execution":90, "quality of available tools":90, "popularity":80, "power & expressiveness":100, "cross platform?":90, "cost":100}, "C": {"ease of learning":15, "ease of use":20, "speed of program execution":100, "quality of available tools":80, "popularity":80, "power & expressiveness":80, "cross platform?":110, "cost":100}, "Lisp": {"ease of learning":40, "ease of use":50, "speed of program execution":80, "quality of available tools":60, "popularity":25, "power & expressiveness":110, "cross platform?":80, "cost":90}, "Delphi": {"ease of learning":50, "ease of use":110, "speed of program execution":85, "quality of available tools":100, "popularity":30, "power & expressiveness":100, "cross platform?":80, "cost":10} } def ProgramLanguageFinal(): print "This is a program to help give you an idea which programming languages you should consider learning." print "While there are any number of languages you might consider, this program considers only 11 of the most popluar ones." print print "The program will ask you to input a ranking or weighting for a number of criteria that may be of importance" print "in choosing your next programming language." # First look up the criteria listed in the scores. # To do that, we need a language name, which can also # be looked up from the scores. languages = language_scores.keys() some_language = languages[0] criteria = language_scores[some_language].keys() rankings = get_user_rankings(criteria) results = ranked_list(calculate_results(languages, language_scores, rankings)) # Take the pairs out of results in order, and print them out for option, result in results: print "%5s\t%s" % (result, option) def ProgramLanguageScript(): print print "This is a program to help you choose a scripting language." print print "You will be asked to rank some important criteria as to their relative importance to you." print "These criteria are 'ease of learning', 'ease of use', 'speed of program execution'" "'quality of available tools', 'popularity', and 'power & expressiveness'" print print "Please rank each of the criteria with a number from 1 to 100 when prompted." print print "100 means of highest relative importance, 1 means of least importance." # This time we want a subset of languages, so I'm going to specify them. options = ["Python", "Perl", "Ruby", "Tcl", "JavaScript", "Visual Basic"] criteria = language_scores[options[0]].keys() rankings = get_user_rankings(criteria) results = ranked_list(calculate_results(options, language_scores, rankings)) # Take the pairs out of results in order, and print them out for option, result in results: print "%5s %s" % (result, option) def Basketball(): print "This is a program to help you decide which team will win a basketball game" print print "When prompted, enter a number ranking each team on the prompted team skill" print "on a scale from 1 to 100, with 1 being terrible and 100 being the best imaginable" print team_one = raw_input ("What is the name of team one: ") team_two = raw_input ("What is the name of team two: ") teams = (team_one, team_two) rankings = {"speed":100, "size":66, "jumping_ability":50, "defense":60, "shooting":75, "ballhandling":50, "rebounding":50} criteria = rankings.keys() scores = {team_one: {}, team_two: {}} for c in criteria: for team in (team_one, team_two): scores[team][c] = get_number("rank the team %s of %s on a scale of 1 to 100: " % (c, team), 1, 100) results = calculate_results(teams, scores, rankings) for team in teams: print "%s has a power ranking of %d" % (team, results[team]) # Now, who won? ranked_results = ranked_list(results) # Compare the scores. if ranked_results[0][1] == ranked_results[1][1]: print "the two teams are a toss-up!!!" else: print "%s wins!!" % ranked_results[0][0] def YesNo(): print "Program to help you make a Yes or No decision." options = ["Yes", "No"] criteria = get_list("Enter your criteria ...", "Criterion %d: ") rankings = get_user_rankings(criteria) scores = get_user_scores(options, criteria ) print `scores` results = ranked_list(calculate_results(options, scores, rankings)) print print "The results are" print print "%5s %s" % ("Score", "Option") for option, result in results: print "%5s %s" % (result, option) if results[0] > results[1]: print "You should decide Yes!!!" else: print print "You should decide No!!!" print ###### MAIN LOOP ############ while 1: # loop forever print "Please enter the number for the type of decision you wish to analayze:" print "1. General Decision Analysis, you choose the options, criteria, etc." print "2. Help in Choosing Programming Language amongst 11 popular languages" print "3. Help in choosing scripting programming language amongst 6 scripting languages" print "4. Which Basketball Team will win the Game???" print "5. Questions with Yes or No type answers" choice = get_number("Please type in the number of the type of decision-program you wish to run from above and hit enter:", 1, 5) if choice ==1: decisionanalysis() elif choice ==2: ProgramLanguageFinal() elif choice ==3: ProgramLanguageScript() elif choice ==4: Basketball() elif choice ==5: YesNo() elif choice =="quit": break # exit from infinite loop else: print "Invalid operation" |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X