From: Schollnick, B. <Ben...@xe...> - 2005-04-04 13:16:12
|
> > Python and Pythoncard/wxPython/insert favourite GUI toolkit here are > > *never* going to make a huge impact on the Visual Basic=20 > market. IMHO,=20 > > though, that's not a valid reason to stop using them. >=20 > growing number of VFP/VB users who are unhappy with Microsoft for the=20 > way they've been brushed aside in lieu of the latest Flavor of the=20 > Month. These people are looking to pick up something new to=20 > develop in,=20 > and many of them would prefer not to commit to another=20 > Microsoft tool.=20 Which is sensible.... I have not used or purchased another Microsoft language since they sold QuickPascal v1.0. They promised features that did not exist in v1.0 and I never forgot that lesson. > Cool tools such as PythonCard help to increase the chance that they=20 > move to Python instead of remaining on the Dark Side. ;-) True. > That's why if you're looking to grow your user base,=20 > it's important to=20 > make things as familiar as possible to those folk.=20 Not necessarily. What we need to supply is something that is overall better than what they were using. Yes, it should be a usable and productive User Interface and Design... =20 But familiar does not necessarily mean better. Can you give us a few examples? =20 For example, the Windows Registry. That's familiar to Windows programmers, but would you suggest that we a need a registry like component in Python or PythonCard? I think I can safely say that 90% of Python/PythonCard developers would say "NO".... Yes, it's absurd comparison... But you did not include any examples... As I mentioned, familiar does not necessarily equal better. Just familiar. > They're leaving=20 > their former comfort zone for something foreign, and the fewer hoops=20 > they have to jump through, the more likely they might stick with your=20 > product, and evangelize it to others.=20 Yes, but it also is a situation where a better product may have a small learning curve, but is worth the investment. I think PythonCard needs better documentation, but for 90% of the situations, the documentation is more than enough.... > So while the things you mention=20 > are not valid reasons for an existing PythonCard developer to *stop*=20 > using the tool, they would be sufficient for a new PythonCard=20 > developer coming from the VB world to never *start*. The Pythoncard tutorial that I used to evaluate PythonCard was enough to convince me to use the software. I would assume that anyone that was thinking of using it would attempt to use the tutorial and start basing a decision on that. I am unclear on what you are suggesting they are basing their decisions on? (The quote does not include it) Presumably on the fact that they need to instead Python, WxPython, and PythonCard? Windows programmers are fully aware of dependencies... .Net anyone? =20 - Benjamin |
From: Schollnick, B. <Ben...@xe...> - 2005-04-04 17:27:08
|
> >I am unclear on what you are suggesting they are basing=20 > their decisions=20 > >on? (The quote does not include it) Presumably on the fact=20 > >need to instead Python, WxPython, and PythonCard? Windows=20 > programmers=20 > >are fully aware of dependencies... .Net anyone? > True - they are aware of them - but that doesn't mean they=20 > like them. I=20 > think it would be pretty cool to have the *option* of a=20 > single download=20 > and install to do Python, wxPython and Pythoncard in one easy=20 > operation.=20 > I have no idea how easy it would be to create that - but I suspect it=20 > would overcome some people's concerns about the complexity of getting=20 > started with Pythoncard. The option might be nice.... But is it a reasonable option? That's at least 6+ different archives.... (Windows, *Nix, MacIntosh) ... That Kevin would have to maintain. I don't even know if Kevin has all of those systems.... Plus just python alone (without Source code) is 10 MB. And that's a dedicated installer (.MSI).... It will be larger in this combined installer.... WxPython is another 6 MB, and PythonCard is another 2... SubTotal roughly 20Mb. That is not including Python Source code, nor Win32 Extensions... And is consists of 3 different installers.... 1) This will be at least a 20 Mb download.... 2) Who is liable for this? If a problem occurs with <fill in the blank> is Kevin going to be forced to Fix it? (WxPython Developer: It's=20 not a bug in our code, your installer goofed...) 3) How is all of this going to be packaged? We have a .MSI installer, two .EXE installers... Prepackage/ZIP everything up? What if the person installing wants a non-standard path or library? It maybe a good idea, but I think it is safer and smarter to use=20 approved installers directly from the authors... A better suggestion, IMHO, is to suggest to Kevin to have a quick link at the top pointing to each installer... =20 ie. ----------------------------------------------------------------- PythonCard is currently at Version v0.81. =20 Pythoncard requires the following software: * Python v2.3.x or later Tested with Version v2.3.888 (download Installer) on xx/xx/xx * WxPython v2.x.x or later (Unicode and Non-Unicode versions) Tested with Version v2.3.888 (download Installer) on xx/xx/xx ------------------------------------------------------------------- Each development environment is going to be different, some people will want WxPython with Unicode support, some without... Some will need WxPython vxx.yy.zz and some want to be using the CVS nightly builds... There is no sensible way to allow of that to be bundled without a huge amount of effort. - Benjamin |
From: normanwinn <nor...@on...> - 2005-04-05 07:48:20
|
ka wrote: > Secondly, once we have a viable 1.x release, I would like to have a > single installer option for Python, wxPython, and PythonCard on the > Windows platform The very fact that you should need to contemplate this demonstrates the severity of the problem. I already have versions of Python that came with Zope, with Open Office, then I'll have another with PythonCard and another with Dabo. Where will this stop? Each time I want to upgrade I end up upgrading n versions of Python? This is folly. What is the alternative? I can't have an answer as I am not at the interior of an open source effort. Perhaps a standard test suite for Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over the standard Python library? Then the exe tools. With py2exe I ended up with the tcl library in my 'exe' package when compiling a command line tool! I don't know how many megabytes I had to distribute. I didn't bother. I then found exemaker: http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README but this, while being very handy on a system that has Python, is not a standalone exe so can't be distributed. Please accept that I am not knocking (does that translate into American). I hope my observations can contribute to a process that will make Python tools available to all, Norman Winn -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005 |
From: Phil E. <ph...@li...> - 2005-04-05 08:50:20
|
On Tue, 2005-04-05 at 08:48, normanwinn wrote: > ka wrote: > > Secondly, once we have a viable 1.x release, I would like to have a > > single installer option for Python, wxPython, and PythonCard on the > > Windows platform > hmmm...not sure I can fully see the benefit of this. You only need to install these if you are planning to write your own apps, in which case downloading and installing them individually wouldn't present any kind of technical challenge. For distributing finished applications, then I would contend that you explicitly *don't* want to have to install Python/wxPython/PythonCard - you should be using the existing tools to bundle up your program into an installer. > The very fact that you should need to contemplate this demonstrates the > severity of the problem. I already have versions of Python that came > with Zope, with Open Office, then I'll have another with PythonCard and > another with Dabo. Where will this stop? Each time I want to upgrade I > end up upgrading n versions of Python? This is folly. > > What is the alternative? I can't have an answer as I am not at the > interior of an open source effort. Perhaps a standard test suite for > Python? Perhaps co-ordinated upgrade days? Perhaps sterner control over > the standard Python library? > No, no, no, absolutely not. There is *no reason whatsoever* to have multiple versions of Python on a machine, unless that is specifically what you want for development purposes, etc. > Then the exe tools. With py2exe I ended up with the tcl library in my > 'exe' package when compiling a command line tool! I don't know how many > megabytes I had to distribute. I didn't bother. I then found exemaker: > > http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README > If py2exe is anything like McMillan Installer, then whether to include Tcl/TK is simply a command line option - it's set to 'on' by default due to TkInter being the de-facto GUI library for Python for a long, long time. You've have made a number of valid and well-reasoned points in your posts on this thread, but IMHO this one is just nit-picking. I think you're just going to have to accept that the process of developing, distributing and maintaining software to a 'professional' standard is damned hard work, and then just make a decision as to whether to live with that or not. I must say, though, that I am enjoying this thread - it's probably the most vigorous and refreshing discussion we've had on here for months, well done Norman! ;-) -- Regards Phil Edwards Brighton, UK |
From: Kevin A. <al...@se...> - 2005-04-05 18:21:49
|
On Apr 5, 2005, at 12:48 AM, normanwinn wrote: > ka wrote: >> Secondly, once we have a viable 1.x release, I would like to have a >> single installer option for Python, wxPython, and PythonCard on the >> Windows platform > > The very fact that you should need to contemplate this demonstrates > the severity of the problem. I already have versions of Python that > came with Zope, with Open Office, then I'll have another with > PythonCard and another with Dabo. Where will this stop? Each time I > want to upgrade I end up upgrading n versions of Python? This is > folly. > > What is the alternative? I can't have an answer as I am not at the > interior of an open source effort. Perhaps a standard test suite for > Python? Perhaps co-ordinated upgrade days? Perhaps sterner control > over the standard Python library? > > Then the exe tools. With py2exe I ended up with the tcl library in my > 'exe' package when compiling a command line tool! I don't know how > many megabytes I had to distribute. I didn't bother. I then found > exemaker: > > http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README > > but this, while being very handy on a system that has Python, is not a > standalone exe so can't be distributed. > > Please accept that I am not knocking (does that translate into > American). I hope my observations can contribute to a process that > will make Python tools available to all, > > Norman Winn > Actually, what I was talking about was more like an uber installer that would install Python, wxPython, and PythonCard in one shot, so people didn't have to download up to 3 different EXEs and run each installer separately. Another way to think of it would be Python that included wxPython and PythonCard as part of the distribution. This wouldn't be a special copy of Python like you have with some Zope/Plone and OpenOffice installs. Furthermore, the individual PythonCard release zip, tar.gz, and EXE installer would still be there. I'll be adding a Mac disk image installer of the PythonCard distribution as soon as I figure that one out. :) This is a separate issue from building standalones for end-users. py2exe and py2app both do their best to figure out required modules. In the case of PythonCard, there is an import of the Image (PIL) module to support easy display of PIL images in PythonCard apps, so a generic standalone build using py2exe will bring in PIL and thus tkinter and its Tcl code. But it is simple enough to exclude modules and libraries that you know you're app doesn't use and this is even documented in the minimalStandalone example. The standaloneBuilder tool will likely have options for excluding common extra libs that most apps wouldn't use. One of the biggest problems with all standalone applications is simply the size of the distribution. It is definitely nicer if you're able to just distribute the plain Python code of a normal PythonCard application, so in a controlled environment I would recommend that people go ahead and install the base Python, wxPython, and PythonCard packages, especially in a computer lab or enterprise installation. On Windows, if there is a security concern over people double-clicking a .py, .pyw, .pyc, .pyo, etc. file then it is simple enough to remove that file association. A lnk file can be used to provide a full path to Python and the executable script with any command-line args, so that can be used instead of a double-clickable exe. ka |
From: Alex T. <al...@tw...> - 2005-04-04 17:03:10
|
Schollnick, Benjamin wrote: > >I am unclear on what you are suggesting they are basing their decisions >on? (The quote does not include it) Presumably on the fact that they >need to instead Python, WxPython, and PythonCard? Windows programmers >are fully aware of dependencies... .Net anyone? > True - they are aware of them - but that doesn't mean they like them. I think it would be pretty cool to have the *option* of a single download and install to do Python, wxPython and Pythoncard in one easy operation. I have no idea how easy it would be to create that - but I suspect it would overcome some people's concerns about the complexity of getting started with Pythoncard. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005 |
From: Kevin A. <al...@se...> - 2005-04-04 17:25:41
|
On Apr 4, 2005, at 10:03 AM, Alex Tweedly wrote: > Schollnick, Benjamin wrote: > >> >> I am unclear on what you are suggesting they are basing their >> decisions >> on? (The quote does not include it) Presumably on the fact that they >> need to instead Python, WxPython, and PythonCard? Windows programmers >> are fully aware of dependencies... .Net anyone? > True - they are aware of them - but that doesn't mean they like them. > I think it would be pretty cool to have the *option* of a single > download and install to do Python, wxPython and Pythoncard in one easy > operation. I have no idea how easy it would be to create that - but I > suspect it would overcome some people's concerns about the complexity > of getting started with Pythoncard. > First of all, I just want to make sure everyone actually found the install instructions at: http://pythoncard.sourceforge.net/installation.html Those are step by step and are supposed to be bullet proof. If there is a problem with them, like needing more images, more explanation at a particular step, please provide specifics on the needed changes. Secondly, once we have a viable 1.x release, I would like to have a single installer option for Python, wxPython, and PythonCard on the Windows platform; Robin Dunn and I talked about doing this almost four years ago, but it doesn't make any sense until the parts of the big package are at a stable point like the combo of Python 2.3.5, wxPython 2.6, PythonCard 1.0, etc. On the Mac, it will just be wxPython and PythonCard, since Macs already include Python. Given the various versions and combinations of Python and wxPython, the single installer will only support one combination. If possible, we'll do the same for Linux. The installer scripts for py2exe (Windows) and py2app (Mac) are almost identical, in fact, Bob Ippolito sent me a script variation to deal with both in a single script. So, once the new standaloneBuilder tool is updated to support py2exe and py2app creating PythonCard standalones should be relatively painless. At Pycon, Bob fixed an earlier problem with how py2app renames the startup module, so people that have had problems with py2app should find that the latest version in cvs works correctly now with PythonCard; I don't know if/when he will have a new release of that outside of cvs. ka |
From: Phil E. <ph...@li...> - 2005-04-05 08:21:45
|
On Mon, 2005-04-04 at 18:25, Kevin Altis wrote: > The installer scripts for py2exe (Windows) and py2app (Mac) are almost > identical, in fact, Bob Ippolito sent me a script variation to deal > with both in a single script. So, once the new standaloneBuilder tool > is updated to support py2exe and py2app creating PythonCard standalones > should be relatively painless. At Pycon, Bob fixed an earlier problem I'll need some help with this, as I have no experience with py2exe - my current code relies entirely on McMillan Installer and Inno Setup. I'm still working on adding the finishing touches to standaloneBuilder and I expect to be checking in the finished version towards the end of this week. I'm just about to go off and sign up to the Pythoncard-devel mailing list, so I'll post an announcement there when I think it's ready. -- Regards Phil Edwards Brighton, UK |
From: Steve C. <stn...@xm...> - 2005-04-04 22:24:42
|
Alex Tweedly wrote: > Schollnick, Benjamin wrote: > > > > >I am unclear on what you are suggesting they are basing their decisions > >on? (The quote does not include it) Presumably on the fact that they > >need to instead Python, WxPython, and PythonCard? Windows programmers > >are fully aware of dependencies... .Net anyone? > > > True - they are aware of them - but that doesn't mean they like them. I > think it would be pretty cool to have the *option* of a single download > and install to do Python, wxPython and Pythoncard in one easy operation. > I have no idea how easy it would be to create that - but I suspect it > would overcome some people's concerns about the complexity of getting > started with Pythoncard. So, something similar to the Enthought Python distribution? http://www.enthought.com/downloads/downloads.htm I'm not sure how much work was required to bundle all those into a single distribution, or how often they update the entire package. As someone mentioned down-thread, tracking all the options and dependencies and creating distributions will be a big job. What about some sort of wizard interface that would step the user through the process? Sort of like the cygwin setup script. e.g. a tool written in PythonCard that'd allow the user to select versions of python/wxPython, unicode flavors, etc. Rather than PythonCard distributing a huge bundle, the PythonCard website would distribute a URLs to the 'good' installers, download the binaries via urllib and launch the install process for python/wxpython/pythoncard. Still a big job, but it might be more managable than the alternative. -Steve |
From: Ed L. <ed...@le...> - 2005-04-04 22:43:51
|
On Apr 4, 2005, at 6:24 PM, Steve Christensen wrote: > I'm not sure how much work was required to bundle all those into a > single > distribution, or how often they update the entire package. It's pretty straightforward in Windows, using py2exe and InnoSetup - that's how I created the standalone runtime for Dabo. Ieven bundle the Dabo code seperately, so that it isn't compiled into the DLLs, so that people can update the Dabo classes as often as we do. It's much harder under Linux, due to dynamic libraries. I've tried building everything statically, and it simply doesn't seem possible. Fortunately most Linux users aren't too afraid of compiling stuff on their own. I haven't spent much time trying this for the Mac yet, but from what I've read, it's somewhere in between, given that you can assume certain base installs (Panther, Jaguar, etc.) and build for these. FWIW, the Dabo runtime for Windows will run nearly any wxPython program, including PythonCard. Feel free to use it as base for PythonCard distribution, if you like. ___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://dabodev.com/ |