Menu
▾
▴
pythoncard-users
|
From: Brad A. <bra...@ma...> - 2004-09-11 17:59:04
|
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. Thanks! Brad Allen Omnicom Management Services Dallas, TX |
|
From: Steven D'A. <st...@cy...> - 2004-09-13 11:41:36
|
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. Perhaps not quite Microsoft Office written in PythonCard, but something like MYOB or Quickbooks? So how about it guys, what's the biggest, most complicated application you know of written in PythonCard? > 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. > I'd be grateful for any thoughts you can provide on this. It seems to me that if you want some reassurance that PythonCard will have the grunt needed, perhaps you should knock up a quick and dirty application as proof of concept. For instance, suppose you decide that your application might have at most 5 windows with 10 text fields and 10 buttons each open at any one time. Write yourself a quick application that creates 25 windows with 50 text fields and 50 buttons each. It doesn't need to do anything except let you move from window to window clicking on buttons, cutting and pasting text, etc. That will give you some idea of the performance of PythonCard under your hardware, with a fairly high safety factor. (A factor of five.) If PythonCard fails that test, then maybe you look elsewhere, or maybe you reduce your safety factor and accept the higher risk. If it passes, then it is no guarantee that it will do what you want, but at least you now have some idea of what sort of performance you can expect. Oh, and by the way: you aren't testing your app on your shiny new dual-processor Pentium4 with 512MB of RAM, oh no, you are testing it on an old P2 with 128MB. 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. 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. Good luck! -- Steven D'Aprano Operations Manager Cybersource Pty Ltd, ABN 13 053 904 082 Level 4, 10-16 Queen St, Melbourne VIC 3000 Tel: +61 3 9621 2377 Fax: +61 3 9621 2477 Web: http://www.cybersource.com.au |
|
From: <bra...@om...> - 2004-09-13 18:58:14
|
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! |
|
From: Kevin A. <al...@se...> - 2004-09-13 20:04:22
|
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 |
|
From: Kevin A. <al...@se...> - 2004-09-13 15:49:43
|
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 |
|
From: Brad A. <bra...@ma...> - 2004-09-14 03:55:27
|
>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. |
|
From: Ruben M. <rmc...@ya...> - 2004-09-20 20:30:59
|
--- Brad Allen <bra...@ma...> wrote: > 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. There is a tool called Rekall that tries to do that. By definition it sounds like what you are looking for. It even uses Python. However, I am not sure of MAC support. And, although it is licensed under the GPL, there seems to be a strong push to make you buy the commercial version. If you want to investigate it start by looking here: RekallRevealed.Org. -Ruben __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
×
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