Re: Wheel-reinvention with Python
David E. Konerding DSD staff wrote: Actually, the real problem with the wxWidgets documentation is that it doesn't tell you *how* to do things. It does only a barely adequate job as an API reference, but what it lacks is an extensive howto. I waste too much of my time dinking around deep in wxPython demos trying to figure out what is the 'right way' to do things. Robin Dunn does an amazing job in answering questions on the mailing list, but the fact that it's Robin himself who responds to so many questions does suggest a problem. I guess it would be really good if someone (not me ;^) would wade through his postings to the mailing list and turn that into some kind of documents. The fact that his excellent, more or less daily postings are so badly needed does indicate a problem, either with the design of the toolkit, or with the docs. I'm not sure which. When will that wxpython book appear? -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tuesday 16 August 2005 05:48, Magnus Lycka wrote: The fact that his excellent, more or less daily postings are so badly needed does indicate a problem, either with the design of the toolkit, or with the docs. I'm not sure which. I htink that there is such an overwhelming amount of stuff in a UI toolkit that it is impossible to create a how-to. Instead, what is needed is a whole series of smaller how-tos for various situations. I mean, there are literally thousands upon thousands of UI behaviors to work with, and no way to describe how to work with low-level drawing primitives in the same document as how to process a menu selection. When will that wxpython book appear? According to one of the authors, Noel Rappin: It'll be called _wxPython In Action_ by Noel Rappin and Robin Dunn. I was told to expect that it would be released in November, but the exact date will depend on how quickly we can turn around the production. So while it's still a little ways off, it's certainly within sight! -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. Aye. Couldn't agree more. PyGTK and PyQt may have their own advantages and disadvantages. I like PyGTK because the calls are C-based and not as confusing as C++-based ones. It looks pretty good too... just a bit slow, but that was about a year ago. Speed may have improved since. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. You will want to take a look at Fredrik Lundh's Tkinter 3000 and Widget Construction Kit: http://www.effbot.org/downloads/ http://www.effbot.org/zone/wck.htm I believe it deserves to be much more well-known that it currently is. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
[EMAIL PROTECTED] wrote: Torsten Bronger wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. Aye. Couldn't agree more. You know, whenever someone mentions wxPython being badly documented, I have to wonder whether they know about the nearly 2000 page PDF of wxWidgets documentation, which is available in html at http://www.wxwidgets.org/manuals/2.6.1/wx_contents.html wxPython has the same API as wxWidgets, except where indicated in that manual. If in doubt, you can also consult http://wxpython.org/docs/api/ And of course, the gaps are filled in by the wxPython wiki: http://wiki.wxpython.org/ I apologize if you already know about these things, but I find myself continually surprised that wxPython is badly documented has become conventional wisdom when I have never found that to be the case. -- Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Brian Victor [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Torsten Bronger wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. Aye. Couldn't agree more. You know, whenever someone mentions wxPython being badly documented, I have to wonder whether they know about the nearly 2000 page PDF of wxWidgets documentation, which is available in html at http://www.wxwidgets.org/manuals/2.6.1/wx_contents.html All of which is oriented toward C++ programmers, with all the language assumptions inherent to that. wxPython has the same API as wxWidgets, except where indicated in that manual. If in doubt, you can also consult http://wxpython.org/docs/api/ That being part of the problem. Putting pieces together in C++ is quite a different mindset to putting them together in Python. I apologize if you already know about these things, but I find myself continually surprised that wxPython is badly documented has become conventional wisdom when I have never found that to be the case. Quantity of documentation doesn't equal quality. That said, the wxPython 2.6 release saw a renewed push toward getting comprehensive API documentation online; it's coming together, slowly. It still feels like wxPython is a second-class citizen in the wx world. -- \ I was the kid next door's imaginary friend. -- Emo Philips | `\ | _o__) | Ben Finney http://www.benfinney.id.au/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
In article [EMAIL PROTECTED], Ben Finney wrote: Brian Victor [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Torsten Bronger wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. Aye. Couldn't agree more. You know, whenever someone mentions wxPython being badly documented, I have to wonder whether they know about the nearly 2000 page PDF of wxWidgets documentation, which is available in html at http://www.wxwidgets.org/manuals/2.6.1/wx_contents.html All of which is oriented toward C++ programmers, with all the language assumptions inherent to that. Actually, the real problem with the wxWidgets documentation is that it doesn't tell you *how* to do things. It does only a barely adequate job as an API reference, but what it lacks is an extensive howto. I waste too much of my time dinking around deep in wxPython demos trying to figure out what is the 'right way' to do things. See: http://www.async.com .br/faq/pygtk/index.py?req=index for an example of what's needed. The wxPython Wiki is poorly organized (like nearly all wikis). It's mandatory reading (all of it) but mainly because it's not obvious where important hints are hidden. Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Dennis Lee Bieber [EMAIL PROTECTED] writes: On 06 Aug 2005 17:27:33 -0700, Paul Rubin http://[EMAIL PROTECTED] declaimed the following in comp.lang.python: Mike Meyer [EMAIL PROTECTED] writes: Is there a free language you consider successful? I can't think of any that are a lot more (i.e. - an order of magnitude) successful than Python that aren't derived from C. SQL Now /I'm/ getting confused... As far as I'm concerned neither Python, SQL, REXX, that OTHER P language, and lots of can be said to be derived from C... The original question was asked of an OP who doesn't consider those languages successful. I don't agree with him, and was asking *his* opinion. He didnt' answer the first time, and I gave up the conversation after that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] I notice that the Wikipedia doesn't have a definition for special purpose language, instead preferring the phrase Domain Specific Langauge. That matches the definition that agrees with what I think is common usage, which is: Trade some of the flexibility of a general purpose language for capabilities that are more tailored to a specific task Fortran certainly meets the requirements the wikipedia has for being a general purpose language. As does TeX. I don't think that this adds anything to the argumentation. [...] Just like some C/C++ applications are legacy code, and some aren't. Which contradicts your earlier assertion that C/C++ applications were all legacy code. Reference? See URL: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/c52d3c17f1ea9ec5/d2013c3f1eef49b9?q=wheel+reinventionrnum=1#d2013c3f1eef49b9 , where you dismiss all C applications a legacy code. This URL points to an article by Paul McNett. Probably you mean [...] By which measure C is still immensely popular, because of the large number of older applications that are written in it that are available - Python being one such. Legacy code is not a sign of success IMO because it implies a difficult future. Calling older applications legacy code is very different from calling C/C++ a legacy code language. [...] [...] I just want to use a popular langauge amongst the ones that have free success (free in the sense of Free Software). These leaves me with three questions for you: Is there a free language you consider successful? Before the quibbling starts again: What do you mean with free language? For me, that's every language that I can use using exclusively Free Software tools. [...] Are there any free language that have the GUI/IDE toolkit you want? I don't know. I haven't seen it yet. Maybe Eclipse + SWT? Have you noticed that languages with really cool features aren't very popular? This is probably true, but really cool features tend to become exotic features. I don't need them, neither the masses. A good GUI toolkit is a nice cool thing to have. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Fri, 05 Aug 2005 21:59:28 -0400, Mike Meyer [EMAIL PROTECTED] wrote: Is there a free language you consider successful? I can't think of any that are a lot more (i.e. - an order of magnitude) successful than Python that aren't derived from C. How about Postscript? (I believe that Postscript was developed as a proprietary language, but it has since become sufficiently Free that there is a Free interpreter that renders Postscript code, and a lot of Free programs generate Postscript code as output.) Stretching (but not too far) language, how about HTML? Except for toasters, almost every computing device sold these days contains an HTML interpreter, and a great deal of embedded systems create HTML and use HTTP as an administrative interface. Regards, Dan -- Dan Sommers http://www.tombstonezero.net/dan/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer [EMAIL PROTECTED] writes: Is there a free language you consider successful? I can't think of any that are a lot more (i.e. - an order of magnitude) successful than Python that aren't derived from C. SQL Have you noticed that languages with really cool features aren't very popular? Unification, prototypes, real macros, and dataflow variables all come to mind. Lisp, except I'm not sure what you mean by dataflow variables. Does that mean logic variables like in Oz? Some of the languages that sport these features even come with an integrated GUI/IDE, but they have at most 99 projects mentioning them on sourceforge - assuming they are listed at all. You could have said the same thing for dynamic types and GC not that long ago. Users are couthing up. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. That doesn't seem to match the common defintion of agile when it comes to programming. Then again, you have a habit of using words to mean whatever you want, without much reference to how they're used by the rest of the industry. I'm not part of the industry. That's no excuse for not learning the terminology, or at least avoiding using phrases which already have a common meaning. Granted, I didn't pay enough attention to the fact that for industry people agile has a much stronger connotation. Nevertheless, it's an ordinary English word, too, so that's no excuse for not trying to understand what I *mean*. Since nobody has any chance to see which programming strategy the projects uses, you must deliberatly misunderstand me for assuming that I meant agile programming. [...] [...] The difference is ther are a lot of other choices, so it gets chosen less often. But I note that at least one of the 155 projects on SourceForge that list FORTRAN as a language is a GUI application for Windows. I see no difference to special-purpose language then. [...] [...] Just like some C/C++ applications are legacy code, and some aren't. Which contradicts your earlier assertion that C/C++ applications were all legacy code. Reference? [...] Earlier, you said you wanted a popular language because they get cool features faster. You hold up two proprietary VC++ (which is just an development environment) and VB as popular languages. If you've been watching software development long enough, you'd realize that cool things usually come from open source projects first. That's right (or rather, I believe you). I just want to use a popular langauge amongst the ones that have free success (free in the sense of Free Software). I used VB and VC++ for my assertion -- that you don't share -- that GUI abilities are the only way to get much popularity, which is in my opinion necessary for cool things. If you say it's not sufficient, okay. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. That doesn't seem to match the common defintion of agile when it comes to programming. Then again, you have a habit of using words to mean whatever you want, without much reference to how they're used by the rest of the industry. I'm not part of the industry. That's no excuse for not learning the terminology, or at least avoiding using phrases which already have a common meaning. Granted, I didn't pay enough attention to the fact that for industry people agile has a much stronger connotation. Nevertheless, it's an ordinary English word, too, so that's no excuse for not trying to understand what I *mean*. Since nobody has any chance to see which programming strategy the projects uses, you must deliberatly misunderstand me for assuming that I meant agile programming. No, I didn't (mis)understand you to mean agile programming. I didn't understand what you said at all - which is why I asked how you define an agile project. [...] The difference is ther are a lot of other choices, so it gets chosen less often. But I note that at least one of the 155 projects on SourceForge that list FORTRAN as a language is a GUI application for Windows. I see no difference to special-purpose language then. Difference to what? I notice that the Wikipedia doesn't have a definition for special purpose language, instead preferring the phrase Domain Specific Langauge. That matches the definition that agrees with what I think is common usage, which is: Trade some of the flexibility of a general purpose language for capabilities that are more tailored to a specific task Fortran certainly meets the requirements the wikipedia has for being a general purpose language. [...] Just like some C/C++ applications are legacy code, and some aren't. Which contradicts your earlier assertion that C/C++ applications were all legacy code. Reference? See URL: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/c52d3c17f1ea9ec5/d2013c3f1eef49b9?q=wheel+reinventionrnum=1#d2013c3f1eef49b9 , where you dismiss all C applications a legacy code. Earlier, you said you wanted a popular language because they get cool features faster. You hold up two proprietary VC++ (which is just an development environment) and VB as popular languages. If you've been watching software development long enough, you'd realize that cool things usually come from open source projects first. That's right (or rather, I believe you). I just want to use a popular langauge amongst the ones that have free success (free in the sense of Free Software). These leaves me with three questions for you: Is there a free language you consider successful? I can't think of any that are a lot more (i.e. - an order of magnitude) successful than Python that aren't derived from C. Are there any free language that have the GUI/IDE toolkit you want? Have you noticed that languages with really cool features aren't very popular? Unification, prototypes, real macros, and dataflow variables all come to mind. Some of the languages that sport these features even come with an integrated GUI/IDE, but they have at most 99 projects mentioning them on sourceforge - assuming they are listed at all. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer wrote: Mike Meyer [EMAIL PROTECTED] writes: I think you'll find that wxPython installs perfectly on Tiger using the package provided. Indeed, the only really painful platform to install wxPython on is Linux, where you pretty much need to build from source if you want the latest and greatest. FWIW, Tiger ships with wxPython pre-installed. Yes, but it's an older version... isn't it 2.4? -- Paul McNett http://paulmcnett.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Paul McNett wrote: Mike Meyer wrote: Mike Meyer [EMAIL PROTECTED] writes: I think you'll find that wxPython installs perfectly on Tiger using the package provided. Indeed, the only really painful platform to install wxPython on is Linux, where you pretty much need to build from source if you want the latest and greatest. FWIW, Tiger ships with wxPython pre-installed. Yes, but it's an older version... isn't it 2.4? 2.5.something.pretty.close.to.2.6.but.not.quite. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Dennis Lee Bieber [EMAIL PROTECTED] writes: On Thu, 04 Aug 2005 00:53:28 -0400, Mike Meyer [EMAIL PROTECTED] declaimed the following in comp.lang.python: No, it's not a discussion about estimates. The average household in a G8 country has more computers that don't run Windows - and in fact don't have GUIs at all - than otherwise. This is a fact of life. Maybe one needs to have an itemization to understand? G Digital clocks, Digital watches, cellphones, digital radio/TV tuners, DVD and CD players, Microwave ovens, VCRs, printers, the more modern monitors with on-screen menus... (my dozen or so amateur, MURS, GMRS, FRS radios), cordless telephones, my heater thermostat, answering machine, pedometer... I did understand, however, my MP3 player makes one whole computer in Mike's statistics but it contains at most 5000 lines of own code. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Thu, 2005-08-04 at 01:04 -0400, Mike Meyer wrote: Right. Let's go back to the original question: What's the app I use on Unix that acts like py2exe on Windows and py2app on Unix? Any archiving system can be coerced into collecting all the parts together. None of them do it automatically. That automatically makes them *not* an answer to the question. Nothing. Since it isn't all written for you it can't be done. Have a nice day. -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
In [EMAIL PROTECTED], Cliff Wells [EMAIL PROTECTED] typed: On Thu, 2005-08-04 at 01:04 -0400, Mike Meyer wrote: Right. Let's go back to the original question: What's the app I use on Unix that acts like py2exe on Windows and py2app on Unix? Here's where I ask *you* to stop being an ass. I've explained how you do it on Unix. It doesn't do it automatically, so you're not happy. No, you've explained how to distribute software for Unix. You haven't explained how to do what I asked about. Well, tough. In the time you've spent complaining you could have actually written it. Well, if you'd simply admitted that the tool I was looking for didn't exist in the first place, you would have saved us both a bunch of time. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. That doesn't seem to match the common defintion of agile when it comes to programming. Then again, you have a habit of using words to mean whatever you want, without much reference to how they're used by the rest of the industry. I'm not part of the industry. That's no excuse for not learning the terminology, or at least avoiding using phrases which already have a common meaning. Sorry, but now the arguments are getting destructive. Agile programming is a fixed phase, which I've never used. (And which makes no sense in this discussion.) Sorry, but you're wrong. FORTRAN is very much a general purpose language. [...] It's not about the potential use of a language, but its actual use. Of course it's not about potential uses. All languages are equivalent at that level. What it's about is the features and facilities of the language, and how well they support general-purpose alternatives. FORTRAN has always been a bit behind other alternatives, but not so far behind that it doesn't get used for real work. That's as true today as it was in 1955. The difference is ther are a lot of other choices, so it gets chosen less often. But I note that at least one of the 155 projects on SourceForge that list FORTRAN as a language is a GUI application for Windows. You can't have it both ways. Either C/C++ is all legacy code, or it's not. ... is wrong in my opinion. Why should this be? Because any given proposition is either true or false. If I say most people are right-handed, then this means neither that all people are right-handed nor that none is. Right. It means that *some* people are right-handed, and some people aren't. Just like some C/C++ applications are legacy code, and some aren't. Which contradicts your earlier assertion that C/C++ applications were all legacy code. There are *lots* of applications areas that don't need GUIs, and don't run on Windows. This becomes a discussion about estimates we both don't know exactly, and weight differently, so I'll leave it here. No, it's not a discussion about estimates. The average household in a G8 country has more computers that don't run Windows - and in fact don't have GUIs at all - than otherwise. [...] However, it's about the types of software which is being produced today. Ok, let's talk about the kinds of software being produced, and where it's coming from? All those computers need software. The embedded software market is pretty active - and is hiring a lot of C (specifically C, not C++) programmers. They may be hiring C++ programmers as well; I don't examine those ads. Could those people be using VC++? I suspect not, but can't say for sure. Earlier, you said you wanted a popular language because they get cool features faster. You hold up two proprietary VC++ (which is just an development environment) and VB as popular languages. If you've been watching software development long enough, you'd realize that cool things usually come from open source projects first. There are a number of reasons for this. One is that most of the software written isn't written for commercial sale: it's developed to make some product or employee more effective. Most of that is developed by or for various governments, which in the US means it's either PD (though possibly undistributed) or classified. People working on such software are every bit as likely to come up with cool things as people developing software for sale. The other reason is that if you want to experiment with some cool thing, it's a lot easier to take an open source project and add that feature than it is to get sources to a proprietary product or write the thing from scratch. Once you do that, there's an incentive to give the feature back to the community, in that you dont have to patch every release of the product to include your feature. These two things play off of each other. People working on inhouse products don't have the legal headaches with open source software that people working on proprietary products do. So they don't have problems with making their business depend on them - and once they've done that, they tend to let employees spend time working on those products. I think this is a lot of open source development comes form - developers getting paid to fix the software because their employer needs it, not people working in their spare time. Hmm. I seem to have gotten on a soapbox. Sorry about that... mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. --
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: Cliff, please quit being an ass. You keep assuming that because some tool isn't the answer to my question that I don't know about it. That's simply rude. It would be *much* more polite to ask What's wrong with distutils rather than saying So you don't know about distutils. http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. I've very familiar with distutils. It doesn't do what I asked for, in that it only bundles up *my* code. It doesn't bundle the things I depend on the way py2exe does. It's patently *not* the answer to the question I asked. For those who want .deb's out of distutils, there's a PR on sourceforge that includes a patch to make it generate .debs that works quite well. Of course, anyone who built a .deb (or an RPM, or a port, or whatever) that bundled up everything it needed would be doing *the wrong thing*. Those formats are designed for packaging single distributions, not applications. They include dependency information that is used to fetch the dependencies and install them. From my standpoint, the problem here is that you then have to get the dependencies into the repository before you can put your application there and have it work. For instance, my port of bicyclerepairman is stuck at an old version because I haven't gotten a port PyMac accepted yet (it also has to do with bugs in the xemacs port, but that's another story). I'm surprised you haven't mentioned eggs yet. Those work across all the platforms I named. Of course, they aren't the answer to my question either, because, like PRMs et al, they only reference external dependencies, they don't include them. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Wed, 2005-08-03 at 09:47 -0400, Mike Meyer wrote: Cliff Wells [EMAIL PROTECTED] writes: On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: Cliff, please quit being an ass. You keep assuming that because some tool isn't the answer to my question that I don't know about it. That's simply rude. It would be *much* more polite to ask What's wrong with distutils rather than saying So you don't know about distutils. Since you said please. I'll try to forget about the wonders of X comment you made that I found just as rude. http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. I've very familiar with distutils. It doesn't do what I asked for, in that it only bundles up *my* code. It doesn't bundle the things I depend on the way py2exe does. It's patently *not* the answer to the question I asked. It can. It isn't terrifically easy, but distutils can be used to package up 3rd party libraries, including binary libs. It can, in fact, package up any file you so desire. For those who want .deb's out of distutils, there's a PR on sourceforge that includes a patch to make it generate .debs that works quite well. I wasn't aware of that. Nice. Of course, anyone who built a .deb (or an RPM, or a port, or whatever) that bundled up everything it needed would be doing *the wrong thing*. Those formats are designed for packaging single distributions, not applications. They include dependency information that is used to fetch the dependencies and install them. From my standpoint, the problem here is that you then have to get the dependencies into the repository before you can put your application there and have it work. For instance, my port of bicyclerepairman is stuck at an old version because I haven't gotten a port PyMac accepted yet (it also has to do with bugs in the xemacs port, but that's another story). I'm surprised you haven't mentioned eggs yet. Those work across all the platforms I named. Of course, they aren't the answer to my question either, because, like PRMs et al, they only reference external dependencies, they don't include them. While this describes the general use case of RPM, you can most certainly include external dependencies. You do it by not making them external. If you need wxPython included with your app, you can build wxPython as a subtree of your project and package it that way. While wasteful of space, it is also the only sure way to make sure that your app has the correct version and all needed dependencies. This is how py2exe does it on Windows and py2app does it on Mac (they just make it automatic). People find Linux more difficult to distribute binary apps on because they try to follow the typical Linux pattern for distributing packages versus using the one used elsewhere. For binaries this doesn't work very well. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Because such projects attract the greatest number of developers, many of them being amongst the most diligent developers, too. I expect this to have a positive influence of the language. You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. That doesn't seem to match the common defintion of agile when it comes to programming. Then again, you have a habit of using words to mean whatever you want, without much reference to how they're used by the rest of the industry. Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Invented today, they would be niche languages. This is patently absurd. C and C++ were born as general-purpose languages. Changing the environment around them isn't going to change that. In 1955 people would have told you that Fortran is general-purpose. It's not the case any more. Sorry, but you're wrong. FORTRAN is very much a general purpose language. Modern version don't resemble the version from 1955 very much, but that's true for most languages that are that old. Legacy code is not a sign of success IMO because it implies a difficult future. So you're saying that Python, Perl, Linux, the various BSD et. al. will have a difficult future? [...] No. All I said was that if a language's success relies almost exclusively on the heavy presence of legacy code, its future is difficult. I see this for C and C++ excluding VC++. Well, you lumped all C/C++ code a legacy code. No because ... Yes, you did do that. I objected to you doing that, because it isn't so. You can't have it both ways. Either C/C++ is all legacy code, or it's not. ... is wrong in my opinion. Why should this be? Because any given proposition is either true or false. The truth may not be know (or even knowable), but the proposition is still either true or false. There are *lots* of applications areas that don't need GUIs, and don't run on Windows. This becomes a discussion about estimates we both don't know exactly, and weight differently, so I'll leave it here. No, it's not a discussion about estimates. The average household in a G8 country has more computers that don't run Windows - and in fact don't have GUIs at all - than otherwise. This is a fact of life. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: On Wed, 2005-08-03 at 09:47 -0400, Mike Meyer wrote: Cliff Wells [EMAIL PROTECTED] writes: On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: Cliff, please quit being an ass. You keep assuming that because some tool isn't the answer to my question that I don't know about it. That's simply rude. It would be *much* more polite to ask What's wrong with distutils rather than saying So you don't know about distutils. Since you said please. I'll try to forget about the wonders of X comment you made that I found just as rude. I made one comment that you found rude - which wasn't intended to be - and you feel that's justification for intentionally insulting me in pretty much every reply? http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. I've very familiar with distutils. It doesn't do what I asked for, in that it only bundles up *my* code. It doesn't bundle the things I depend on the way py2exe does. It's patently *not* the answer to the question I asked. It can. It isn't terrifically easy, but distutils can be used to package up 3rd party libraries, including binary libs. It can, in fact, package up any file you so desire. So can tar. That doesn't make it a solution to the problem, either. I'm surprised you haven't mentioned eggs yet. Those work across all the platforms I named. Of course, they aren't the answer to my question either, because, like PRMs et al, they only reference external dependencies, they don't include them. While this describes the general use case of RPM, you can most certainly include external dependencies. You do it by not making them external. If you need wxPython included with your app, you can build wxPython as a subtree of your project and package it that way. While wasteful of space, it is also the only sure way to make sure that your app has the correct version and all needed dependencies. This is how py2exe does it on Windows and py2app does it on Mac (they just make it automatic). Right. Let's go back to the original question: What's the app I use on Unix that acts like py2exe on Windows and py2app on Unix? Any archiving system can be coerced into collecting all the parts together. None of them do it automatically. That automatically makes them *not* an answer to the question. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer [EMAIL PROTECTED] writes: I think you'll find that wxPython installs perfectly on Tiger using the package provided. Indeed, the only really painful platform to install wxPython on is Linux, where you pretty much need to build from source if you want the latest and greatest. FWIW, Tiger ships with wxPython pre-installed. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer [EMAIL PROTECTED] writes: No, it's not a discussion about estimates. The average household in a G8 country has more computers that don't run Windows - and in fact don't have GUIs at all - than otherwise. This is a fact of life. Most of those computers aren't programmable in Python ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. That doesn't seem to match the common defintion of agile when it comes to programming. Then again, you have a habit of using words to mean whatever you want, without much reference to how they're used by the rest of the industry. I'm not part of the industry. Sorry, but now the arguments are getting destructive. Agile programming is a fixed phase, which I've never used. (And which makes no sense in this discussion.) [...] Sorry, but you're wrong. FORTRAN is very much a general purpose language. [...] It's not about the potential use of a language, but its actual use. [...] You can't have it both ways. Either C/C++ is all legacy code, or it's not. ... is wrong in my opinion. Why should this be? Because any given proposition is either true or false. If I say most people are right-handed, then this means neither that all people are right-handed nor that none is. [...] There are *lots* of applications areas that don't need GUIs, and don't run on Windows. This becomes a discussion about estimates we both don't know exactly, and weight differently, so I'll leave it here. No, it's not a discussion about estimates. The average household in a G8 country has more computers that don't run Windows - and in fact don't have GUIs at all - than otherwise. [...] However, it's about the types of software which is being produced today. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] I'm interested in a language with a big community. This is my definition of success. [...] GUI applications seem to be the most attractive application type. This is not only true for commercial programming. When I look at the most agile projects on Sourceforge, almost all of them have a GUI. Why restrict yourself to agile projects? Because such projects attract the greatest number of developers, many of them being amongst the most diligent developers, too. I expect this to have a positive influence of the language. [...] I won't argue that most of the projects on Sourceforge have GUIs - that's certainly true. I will argue that most of the projects are done in languages that aren't what you call GUI-aware. Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Invented today, they would be niche languages. However, even C++ is really successful only when used as a GUI-aware dialect. Additionally, Python does not have this legacy bonus. Therefore, GUI-aware languages attract much larger user bases, and so they cater my definition of being successful. Since you haven't stated what that definition is, I can't really say anything about this. Yes, I did. [...] Legacy code is not a sign of success IMO because it implies a difficult future. So you're saying that Python, Perl, Linux, the various BSD et. al. will have a difficult future? [...] No. All I said was that if a language's success relies almost exclusively on the heavy presence of legacy code, its future is difficult. I see this for C and C++ excluding VC++. They will always be there, but cool new things will be made available firstly (or only) for Java, C#, Python etc. [...] Or maybe you could switch to Jython, and just use swing? Actually I'm very happy with CPython. Besides, I don't like the Java world. When I left C++ last winter, I dithered between C#, Ruby, and Python. BTW this thread was extremely interesting for me. I've learnt a lot. (Unfortunately, two weeks ago I opted for wxPython, after a long and tough time of thorough pondering, and today this thread informed be about progress on the Tk front. *cry* ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 02 Aug 2005 00:42:53 -0400, Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (phil hunt) writes: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Not necessarily. My window manger is Python all the way down Your X server is written in Python? :-) - it uses the Python Xlib implementation - and is plenty fast. Of course, it doesn't do a lot of graphics work, even for a window manager. That's what I mean: painting the individual pixels on the screen. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 09:45 +0200, Torsten Bronger wrote: Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Unfortunately your assertion is patently false. C and C++ are very much general-purpose languages. It is a logical contradiction to assert that Java, C#, VB and Python are general-purpose languages while C and C++ are not when the former were implemented using the latter. Being implemented in C, Python can do nothing that C cannot. It can certainly make it *easier* to do things, but it conveys no new abilities other than that of meeting deadlines ;) As an aside, I don't disagree with what I think is your main point: higher-level abstractions make more advanced ideas feasible. You simply state it far too strongly. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells [EMAIL PROTECTED] writes: On Tue, 2005-08-02 at 09:45 +0200, Torsten Bronger wrote: Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Unfortunately your assertion is patently false. C and C++ are very much general-purpose languages. This is true in the sense that you can realise an arbitrary program with them, and you can use the full power of the computer. But in my opinion the era of such programming is over. Already today but even more in the future programs of all kind are coded in the higher-level languages (including VC++), limiting C(++) to the field of system programming. Probably quibbling, but this is how I meant it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: Regardless, when you say Unix, what do you mean? You may as well say OS as this term has little meaning. Linux (which flavor)? BSD? SCO? HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils hacking would solve your problem. I think the post I replied to covered the OS X case - there's an application bundler available for it already. Yes, I've used it to bundle wxPython apps on 10.3. I want distributions that will work on all three major BSD variants and most Linux distrubtions - in particular, anything that uses deb's, rpm's or emerge. If you want to choose one in particular, try ubuntu Linux. OpenBSD: in portage FreeBSD: in portage 386BSD: don't know... does anyone still use this? NetBSD: included AFAICT Fedora: rpms available Debian: debs available Ubuntu: included Gentoo: in portage OS/X: available on wxpython.org Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Jorge Godoy [EMAIL PROTECTED] writes: Mike Meyer wrote: In fact this sounds more like a joke I've heard a while ago: standards, if you don't like the ones out there, create your own. Works for me. What works for you? You believe that chaos is better than having standards? I believe that flexibility is good, but not chaos. I believe that multiple competing options is better than an externally enforced standard, or a single option with a near-monopoly position. If none of the options are good enough for the job at hand, you create your own. won't recap the thread, but other languages have been *very* successful without having a GUI as part of the language, all they had was one development environment distributed with a GUI. One IDE, you mean? I believe the freedom to choose from multiple IDEs is also good. Some code on VI, others on Emacs, others on Eclipse, others on ... IDE is short for integrated development environment. I chose a slightly broader phrase. The languages had more options than one specific distribution, but that one dominated at least one market. BTW, in answer to your rhetorical question about GUI's for Linux, the answer is plwm. :-) And does it integrate well with common business apps, such as a mail client, note taking apps, addressbooks (with personal and shared entries), calendar with ability to share appointments, etc.? Of course. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
[EMAIL PROTECTED] (phil hunt) writes: On Tue, 02 Aug 2005 00:42:53 -0400, Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (phil hunt) writes: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Not necessarily. My window manger is Python all the way down Your X server is written in Python? :-) I see the smiley, but just to make sure no one is confused, the answer is no. My window manager is written in Python. Unlike monolithic programs in proprietary OS's, X seperates the window manager from the thing that actually paints pixels on the screen. It's possible to run the window manager on another computer entirely, and people used to sell boxes that ran in that configuration out of the box. - it uses the Python Xlib implementation - and is plenty fast. Of course, it doesn't do a lot of graphics work, even for a window manager. That's what I mean: painting the individual pixels on the screen. Well, no X graphics package will get any closer to that than my python window manager. The python code sends packets to the X server, and parses what comes back from it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] I'm interested in a language with a big community. This is my definition of success. [...] GUI applications seem to be the most attractive application type. This is not only true for commercial programming. When I look at the most agile projects on Sourceforge, almost all of them have a GUI. Why restrict yourself to agile projects? Because such projects attract the greatest number of developers, many of them being amongst the most diligent developers, too. I expect this to have a positive influence of the language. You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. I won't argue that most of the projects on Sourceforge have GUIs - that's certainly true. I will argue that most of the projects are done in languages that aren't what you call GUI-aware. Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Invented today, they would be niche languages. This is patently absurd. C and C++ were born as general-purpose languages. Changing the environment around them isn't going to change that. However, even C++ is really successful only when used as a GUI-aware dialect. Additionally, Python does not have this legacy bonus. The only dialect that might be considered GUI-aware is C#. Or maybe you mean they're only succesfull when coupled with a GUI library? I'd say that's due to your warped definition of success, and I'm not going to argue with your definition. Therefore, GUI-aware languages attract much larger user bases, and so they cater my definition of being successful. Since you haven't stated what that definition is, I can't really say anything about this. Yes, I did. No, you agreed with my definition, with the proviso that you had to consider how important the application area was. Which leaves it undefined. Legacy code is not a sign of success IMO because it implies a difficult future. So you're saying that Python, Perl, Linux, the various BSD et. al. will have a difficult future? [...] No. All I said was that if a language's success relies almost exclusively on the heavy presence of legacy code, its future is difficult. I see this for C and C++ excluding VC++. Well, you lumped all C/C++ code a legacy code. The most successful distribution of Python is the one written in C, so it's success relies almost exclusively on legacy code. Ditto for Perl, Linux, etc. You can't have it both ways. Either C/C++ is all legacy code, or it's not. If it is, the building products in Python/Perl/Java (and probably most of the others) is building in a dependence on a legacy code base. If they *aren't* legacy code, then your premise that C/C++ only has legacy code is false. Personally, I think your premise is false. There are lots of projects still under active development using C/C++. There are new ones starting every day. Contrary to your assertion about VC++, they are starting in environments where VC++ doesn't run. I think you need to come out from behind your Windows box for a while. There are *lots* of applications areas that don't need GUIs, and don't run on Windows. I'll bet most of the computers in your house are running software that falls into that category. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Paul McNett [EMAIL PROTECTED] writes: project I've found, but still doable. Well, I've got a long history of installing things from source - going back to v6. On OS X, I like the darwin ports stuff, so I tried that: % sudo port install wxpython It blew up trying to compile wxpython. The multitude of dependencies all seemed to build find. Building wxpython from the source distribution by hand doesn't seem to fair any better. To build wxPython from source, you really need to follow Robin's detailed instructions in BUILD.txt, located somewhere in the source tree (I have to look for it every time, but I think it is in wxSrc/wxPython/docs/BUILD.txt). It isn't difficult but there's more to it than the standard ./configure;make;make install. I found BUILD.txt. I followed it to the letter. It still blew up. There may be a problem with Tiger that hasn't been reported yet (yeah, I know - I really ought to report it...). Then again, it could be a problem with trying to install it on the darwin ports Python 2.4 package instead of the 2.3.5 that Tiger ships with. I think you'll find that wxPython installs perfectly on Tiger using the package provided. Indeed, the only really painful platform to install wxPython on is Linux, where you pretty much need to build from source if you want the latest and greatest. Well, it built just fine on my FreeBSD box. Then again, I've generally found installing from source on FreeBSD to be easier than installing RPM's on Linux. I'll probably copy THE over to my FreeBSD box and try it there. thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] Because such projects attract the greatest number of developers, many of them being amongst the most diligent developers, too. I expect this to have a positive influence of the language. You didn't answer the question about how you define agile project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. [...] Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Invented today, they would be niche languages. This is patently absurd. C and C++ were born as general-purpose languages. Changing the environment around them isn't going to change that. In 1955 people would have told you that Fortran is general-purpose. It's not the case any more. [...] Legacy code is not a sign of success IMO because it implies a difficult future. So you're saying that Python, Perl, Linux, the various BSD et. al. will have a difficult future? [...] No. All I said was that if a language's success relies almost exclusively on the heavy presence of legacy code, its future is difficult. I see this for C and C++ excluding VC++. Well, you lumped all C/C++ code a legacy code. No because ... [...] You can't have it both ways. Either C/C++ is all legacy code, or it's not. ... is wrong in my opinion. Why should this be? [...] I think you need to come out from behind your Windows box for a while. But you did read my headers? ;-) There are *lots* of applications areas that don't need GUIs, and don't run on Windows. This becomes a discussion about estimates we both don't know exactly, and weight differently, so I'll leave it here. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin http://[EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: I can't really understand your hostility towards non-Tkinter toolkits. In the case of wxPython, it's part of SUSE, which is probably also true for Fedora and Mandriva. Installing is as easy as selecting a checkbox. This covers a very great deal of Linux users. On Windows you have to call an exe file. No it's not on Fedora, at least FC3. It may not be on a DVD but the RPMs are avaiable where Fedora should look for them. I had huge trouble trying to build it and gave up. It's perfectly okay if you are used to build everything yourself but this is a quite untypical approach. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells [EMAIL PROTECTED] writes: On Sun, 2005-07-31 at 23:46 +0200, Torsten Bronger wrote: Cliff Wells [EMAIL PROTECTED] writes: [...] Well, I think this exposes one of the more interesting sides of open source software in general. For better or worse, you get choices. If you don't like choice, you won't like open source. On the other hand, the GUI package bundled with Python is a regular decision of some sort of committee. No, it's a decision made by Guido some years ago that remains in place because it's more pain to remove than to simple leave there. http://wiki.python.org/moin/TkInter suggests that it's a more or less regular decision. Besides, define bundled with. Described in the standard library documentation. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: No it's not on Fedora, at least FC3. It may not be on a DVD but the RPMs are avaiable where Fedora should look for them. I had huge trouble trying to build it and gave up. It's perfectly okay if you are used to build everything yourself but this is a quite untypical approach. I think my approach is in some sense completely typical: I don't want to install ANYTHING, EVER. I've described this before. I want to buy a new computer and have all the software I'll ever need already on the hard drive, and use it from that day forward. By the time the software is obsolete and I want new stuff, the hardware is also obsolete, so I buy another new computer and start over. This is the way most non-technical use their computers (Wintel boxes with MS Office pre-installed), but then I don't get Python or much other development stuff Buying a Macintosh would maybe accomplish the above for me better than wintel (i.e. it comes with dev stuff including Python), but somewhat less typically, I also want access to all the source code, so I run Linux on an x86 box. That means I approximate my zero-install desire by starting with an empty hard drive and plopping in the FC3 (or now FC4) DVD and clicking install everything just once at setup time. After that, if I absolutely have to install anything, I consider it an exceptional situation and so I want to compile from source, not unpack a binary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 23:47 -0700, Paul Rubin wrote: snip commentary about how Paul wants to both not install *anything* and if he does have to install something he must compile it from source because he shouldn't have had to do it in the first place therefore he needs to make it as difficult as possible and if something doesn't fit this bizarre pattern then it sucks and we should just use tkinter instead. /snip I think you are one of a kind and that any suggestions you make about what should or shouldn't be standard in Python (i.e what would be of the most use to the largest number of people) are to be taken with an extremely large grain of salt. Nothing wrong with being unique, but you just need to realize that no one else in their right mind wants to do things your way and any attempts you make to get them to do so are doomed to failure at best and ridicule at worst. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 31 Jul 2005 08:02:43 -0400, Ed Leafe [EMAIL PROTECTED] wrote: On Sunday 31 July 2005 01:02, phil hunt wrote: You mightn't have, but I suspect more Python programers who've written GUI apps have used Tkinter than any of the other APIs. Not that I'm a particular fan of it, it's just I like standardisation, because then you get network effects. At PyCon DC 2004, Guido was asked about wxPython: wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first. I was under the impression -- from reading this ng -- that wx was buggy on some platforms and less portable than Tkinter. Not true? -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 31 Jul 2005 10:07:52 -0700, Kay Schluehr [EMAIL PROTECTED] wrote: Ed Leafe wrote: On Sunday 31 July 2005 01:02, phil hunt wrote: You mightn't have, but I suspect more Python programers who've written GUI apps have used Tkinter than any of the other APIs. Not that I'm a particular fan of it, it's just I like standardisation, because then you get network effects. At PyCon DC 2004, Guido was asked about wxPython: wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first. Maybe. But Guidos intention with Python was to create a secondary language originally - an extension language of C - ( unlike Java that was concepted as a radically platform independent language and a successor of C++ ). These days you can almost think of C++ as a secondary language to Python: code the app in Python and then optimise by recoding the bits that need speed in C++. Some other people already abandoned Python not for the worst reasons: http://www.kevin-walzer.com/pivot/entry.php?id=69 My objection with wrappers around wrappers around wrappers is that I have no hope ever watching the ground. If some error occurs, which layer has to be addressed? Good point. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 31 Jul 2005 14:52:58 -0400, Mike Meyer [EMAIL PROTECTED] wrote: Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Calvin Spealman [EMAIL PROTECTED] writes: The choice is GUI toolkits is largely seperate from Python. Consider that they are just bindings to libraries that are developed completely seperate of the language. GUI is should be seperate from the language, and thus not bound to same expectations and desires as elements of the language itself. I disagree. A modern language must provide a convenient and well-embedded way to write GUI applications. The tools for writing GUI applications belong in a library, not the langauge. None of us has talked about changing syntax. However, the standard library is part of the language unless you're really very petty. Or you use different Python implementations. There are four different Python implementations in the world. Not everything in the CPYthon standard library runs in all of them. I would guess that 90%+ of Python developers develop to CPython. To put this differently, it's required if you want to succeed as a language for the specific purpose of creating GUI applications. I'd agree to that. But there are *lots* of other application areas around, so limiting your definition of success to that one field is very short-sighted. GUI applications are a large area; and langauge that doesn't do them tolerably well is limiting its success. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 31 Jul 2005 12:09:48 -0700, Cliff Wells [EMAIL PROTECTED] wrote: On Sun, 2005-07-31 at 10:07 -0700, Kay Schluehr wrote: Some other people already abandoned Python not for the worst reasons: http://www.kevin-walzer.com/pivot/entry.php?id=69 Being a developer requires not only a bit of brains, but quite a bit of tenacity as well. Apparently Kevin lacks the second. My objection with wrappers around wrappers around wrappers is that I have no hope ever watching the ground. If some error occurs, which layer has to be addressed? Which developing group is reponsible? My own or that of team A, team B, team C ... ? The baroque concept is repulsive to me and only acceptable in case of legacy code that gets wrapped around old one and is dedicated to substitute it continously. Of course, Tkinter is still a wrapper around a third party library (Tk) borrowed from a different language (Tcl) and written again in a third language (C), much the same as wxPython. In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 08:53 +0100, phil hunt wrote: I was under the impression -- from reading this ng -- that wx was buggy on some platforms and less portable than Tkinter. Not true? It depends on how you define buggy and portable... also platform is up for grabs too ;) On the serious side, I expect that if you are simply counting bugs, there are probably more in wxPython. But I'd also say that when it comes to ratio of bugs to features, they are probably quite comparable, even if Tk has one bug and wxPython a hundred ;) As far as more portable, Tk probably wins hands-down. OTOH, in practice, very few people care about the platforms wxPython doesn't run on (think: GTK doesn't run there either). wxWidgets is working on a wxUniversal port which takes a similar tack that Tk does in most cases, that is, providing all of its own widgets based on drawing primitives, but I have no idea how far along that is nor how long until wxPython supports it as another target. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
phil hunt wrote: On Sun, 31 Jul 2005 12:09:48 -0700, Cliff Wells [EMAIL PROTECTED] wrote: On Sun, 2005-07-31 at 10:07 -0700, Kay Schluehr wrote: Some other people already abandoned Python not for the worst reasons: http://www.kevin-walzer.com/pivot/entry.php?id=69 Being a developer requires not only a bit of brains, but quite a bit of tenacity as well. Apparently Kevin lacks the second. My objection with wrappers around wrappers around wrappers is that I have no hope ever watching the ground. If some error occurs, which layer has to be addressed? Which developing group is reponsible? My own or that of team A, team B, team C ... ? The baroque concept is repulsive to me and only acceptable in case of legacy code that gets wrapped around old one and is dedicated to substitute it continously. Of course, Tkinter is still a wrapper around a third party library (Tk) borrowed from a different language (Tcl) and written again in a third language (C), much the same as wxPython. In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Oh, I could imagine that a MFC-like wrapper around win32gui, or another one around Xlib wouldn't be slower that wxWidgets is today. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sunday 31 July 2005 22:39, Paul Rubin wrote: import dabo app = dabo.dApp() dApp.start() Sorry, I couldn't do it in 5. ;-) Oh, and that includes a full menu, too. I get an ImportError exception when I try that. Any suggestions? Note that I don't get that exception from Tkinter. bash-3.00$ python Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type help, copyright, credits or license for more information. import dabo Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named dabo import Tkinter Oh, c'mon now Paul, now you're trolling. You know exactly what the problem is, and try to make it look like a bug. Fine: you don't want to use anything that doesn't come standard with Python. You've made your point. We get it. There is no need to repeat yourself constantly. The only point of my post was that for those without your aversion to installing useful tools, Dabo provides a ton of functionality. Also, as my partner Paul McNett pointed out, I could have done it in *two* lines: import dabo dabo.dApp().start() ;-) -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
On Sat, 30 Jul 2005 14:13:14 -0700 Cliff Wells wrote: But how stable is GTK on systems such as Windows and OS/X? That has been what has kept me from using it. Most GTK apps I've used on Windows (including the venerable GIMP) are nowhere near as stable as their Linux counterparts (although this may not be entirely the fault of GTK). Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to place on an end user. I cannot speak for Mac OS X, but I like GTK on Windows, it's better than Tkinter :D GTK unter Windows has been discussed not so long ago: http://groups.google.de/group/comp.lang.python/browse_frm/thread/308b08adce4b9794/7ca38c3d89933ce9?tvc=1#7ca38c3d89933ce9 If you already tried GIMP on Windows, better try Inkscape on Windows.. that piece of GTK software is really good. greets, Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hello! On Sun, 31 Jul 2005 13:46:55 +0200 Torsten Bronger wrote: Be that as it may, some Google postings suggest that it works at least with wxPython. Yes, it does. I hadn't done this a long time, but it is possible. In fact, afaik there are less problems with py2exe and wxPython than with PyGTK (writing the setup.py was easier). greets, Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 31 Jul 2005 16:38:45 -0700 Paul Rubin wrote: I can put up a Tk gui in about 5 lines of code from a stock Python distro without having to install anything additional. How do I do that with wxPython? It is very easy under Debian Sarge to do it. Well after installing python-tk which needs python2.3-tk which needs blt, tcl8.4, tk8.4 and likes to have tix8.1. So, for a Tkinter programm you just need to install at least five packages for a GUI toolkit which may be great for you if you like to study the history of computing. :D Not that wxPython, PyGTK, PyQt have no dependencies ;) Bug you still can't forget the dependency on Tcl/Tk. greets, Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
On Mon, 2005-08-01 at 14:20 +0200, Marek Kubica wrote: If you already tried GIMP on Windows, better try Inkscape on Windows.. that piece of GTK software is really good. I don't do any actual work under Windows any more. My Windows VMware session is purely for testing Windows apps and websites under Exploder. However my girlfriend, while hating the Gimp (she prefers Photoshop, to put it mildly), loves Inkscape and claims it is better in many ways than Illustrator. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger wrote: Hallöchen! Peter Decker [EMAIL PROTECTED] writes: On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. I had the exact same impression when I started working with wxPython: [...] I then discovered Dabo (http://dabodev.com), which is a full application framework, but whose UI layer is a very Pythonic wrapper around wxPython. I've created several apps now using Dabo, even though I haven't even looked at the data connectivity aspects of it; the UI code works fine without it. I'm aware of it (and there is Wax and maybe a third one). Actually it illustrates my point quite well: These projects are small and instable (Dabo has a developer basis of very few people, Wax has only one); they are even worse documented; they add another layer which slows down and requires the end-user to install another package; they force you to test even more GUI approaches. Wax is small enough to distribute *with* large apps. It now has several developers and part of the two 'google summer of code' projects working on it will be to generate full documentation. I find it makes writing GUI apps easier than with Tkinter and there is no speed bottleneck form the GUI code ! All the best, Fuzzy http://www.voidspace.org.uk/python == They contribute heavily to Dark Cowherd's observation that it is shambles. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Paul Rubin wrote: I think my approach is in some sense completely typical: I don't want to install ANYTHING, EVER. I've described this before. I want to buy a new computer and have all the software I'll ever need already on the hard drive, and use it from that day forward. By the time the With all due respect, if you're allergic to installing software then why are you a developer? To me, your view is somewhat akin to that of a woodworker who doesn't want to buy tools, or a painter who doesn't want to buy brushes. Computers can be merely appliances, sure, but that's wasting the general purpose part of computation. Software as separate packaging exists because we (collectively) don't always know what we want the first (or second, or third, or...) time around. And when we do know what we want, we often muck it up when we try it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 31 Jul 2005 09:03:41 -0700, Paul Rubin http://phr.cx@nospam.invalid wrote: How on earth did you decide that, since tkinter actually runs out of the box when you install Python on most platforms, and wxPython doesn't? I can't even think about trying out Dabo unless I'm willing to go through some enormous pain of getting wxPython to work. Geez, can you whine some more? Most people are running wxPython just fine, and since you don't care enough to bother to follow instructions, and have some oddball religious rule about installing binaries, it's everyone else's fault that you experience enormous pain. Gimme a break. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
This sort of intentional obtuseness grates on me too. Just to let you know, this discussion has convinced me to try Dabo, which I knew nothing about before. So your participation has not been useless. In fact, I think I will start with your two-liner below so I can see what I get by default and then build from there. Terry J. Reedy Ed Leafe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sunday 31 July 2005 22:39, Paul Rubin wrote: import dabo app = dabo.dApp() dApp.start() Sorry, I couldn't do it in 5. ;-) Oh, and that includes a full menu, too. I get an ImportError exception when I try that. Any suggestions? Note that I don't get that exception from Tkinter. bash-3.00$ python Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type help, copyright, credits or license for more information. import dabo Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named dabo import Tkinter Oh, c'mon now Paul, now you're trolling. You know exactly what the problem is, and try to make it look like a bug. Fine: you don't want to use anything that doesn't come standard with Python. You've made your point. We get it. There is no need to repeat yourself constantly. The only point of my post was that for those without your aversion to installing useful tools, Dabo provides a ton of functionality. Also, as my partner Paul McNett pointed out, I could have done it in *two* lines: import dabo dabo.dApp().start() ;-) -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Monday 01 August 2005 10:35, Terry Reedy wrote: This sort of intentional obtuseness grates on me too. Just to let you know, this discussion has convinced me to try Dabo, which I knew nothing about before. So your participation has not been useless. In fact, I think I will start with your two-liner below so I can see what I get by default and then build from there. We have two Dabo-specific email lists: Dabo-dev is for following the latest and greatest developments in Dabo, including notifications of all commits to the repository; Dabo-users is for developers using the framework who have questions/problems/comments about Dabo. http://leafe.com/mailman/listinfo/dabo-dev http://leafe.com/mailman/listinfo/dabo-users -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Ed Leafe wrote: On Sunday 31 July 2005 22:39, Paul Rubin wrote: import dabo app = dabo.dApp() dApp.start() Sorry, I couldn't do it in 5. ;-) Oh, and that includes a full menu, too. I get an ImportError exception when I try that. Any suggestions? Note that I don't get that exception from Tkinter. bash-3.00$ python Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type help, copyright, credits or license for more information. import dabo Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named dabo import Tkinter Oh, c'mon now Paul, now you're trolling. You know exactly what the problem is, and try to make it look like a bug. Fine: you don't want to use anything that doesn't come standard with Python. You've made your point. We get it. There is no need to repeat yourself constantly. The only point of my post was that for those without your aversion to installing useful tools, Dabo provides a ton of functionality. Also, as my partner Paul McNett pointed out, I could have done it in *two* lines: import dabo dabo.dApp().start() ;-) -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com If you're creating a new instance of your dApp(I assume its a class) with no arguments, then effectively your just creating a default program which is already defined in the dabo module. If you could write it in a few, short lines of code by defining a new class, then you might have something there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Devan L wrote: If you're creating a new instance of your dApp(I assume its a class) with no arguments, then effectively your just creating a default program which is already defined in the dabo module. If you could write it in a few, short lines of code by defining a new class, then you might have something there. import dabo app = dabo.dApp() app.UI = wx class MyTextBox(dabo.ui.dTextBox): def initProperties(self): self.Width = 200 self.Value = Planet Earth is blue class MyForm(dabo.ui.dForm): def afterInit(self): self.addObject(MyTextBox) def initProperties(self): self.Caption = Ground Control To Major Tom app.MainFormClass = MyForm app.start() -- Paul McNett http://paulmcnett.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Reinhold Birkenfeld wrote: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Oh, I could imagine that a MFC-like wrapper around win32gui, or another one around Xlib wouldn't be slower that wxWidgets is today. Reinhold Hi Reinhold, did You have a look at 'venster'? http://venster.sourceforge.net/htdocs/index.html They even dropped win32gui and worked with ctypes and the Win32API reducing the C-footprint. For frameworks like Dabo, AnyGUI, PyGUI etc. this would be the right level to create an abstraction layer IMO. By the way the demo applications of venster run stable and fast on WinXP. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Ed Leafe [EMAIL PROTECTED] wrote: On Sunday 31 July 2005 12:03, Paul Rubin wrote: How on earth did you decide that, since tkinter actually runs out of the box when you install Python on most platforms, and wxPython doesn't? Because Tkinter looked like crap on OS X. Sorry, but it's hard to sell an application that looks bad. Our target for the framework is to build cross-platform apps that look native on each platform. Tkinter didn't measure up in that regard. FWIW, some people may find this page interesting, which gives you an idea what standard Tk looks like on OS X, and then with adopting the tile extension to Tk and a few other tweaks, which is on its way to becoming a standard part of Tk: http://wiki.tcl.tk/14522 There's other info and various screenshots at: http://tktable.sourceforge.net/tile/index.html I think the message is, Tk has been moving forward in a coherent and focused way (finally) in terms of look and feel, which will certainly be of great benefit to Tkinter. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
How can I embed a browser in Tk (I mean a real browser, like Mozilla, Safari, or even Exploder)? At all? On any platform? This has always been the tradeoff for Tk. Try this as one example: http://wiki.tcl.tk/4094 Tk is great for learning, easy to write small, basic interfaces, less great for deploying real world apps with sophisticated interfaces. I've often felt that Tk was the VB of GUI toolkits: terrific for knocking out simple stuff, but starts to bite you in the *** when you try to do the hard stuff. wxPython is the opposite: it has a steeper learning curve, but once you know it, you can do amazing things. For me, the long term benefits are far more important to me than how low the startup costs are. I'd respectfully disagree (having done large, real-world Tk apps). You're right that Tk has a slow learning curve, which makes it easy to knock out simple interfaces really quickly - and generally ones that are not too impressive looking. You can do more sophisticated ones, and ones that blend properly into the platforms you're working on - however, the amount of effort and learning curve increase substantially. This is because you end up needing to do a lot more fiddling, looking at or using any of a large number of add-on packages, etc.). Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Peter Decker [EMAIL PROTECTED] writes: Geez, can you whine some more? Most people are running wxPython just fine, Most people? What percentage of actual Python users do you think have wxPython installed? If you're really claiming it's over 50%, you're out of your mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Monday 01 August 2005 15:21, Mark Roseman wrote: FWIW, some people may find this page interesting, which gives you an idea what standard Tk looks like on OS X, and then with adopting the tile extension to Tk and a few other tweaks, which is on its way to becoming a standard part of Tk: http://wiki.tcl.tk/14522 That's certainly an improvement. But when we reviewed the various toolkits a year and a half ago, we just looked at the standard Tk stuff. -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 01 Aug 2005 12:58:57 -0700, Paul Rubin http://phr.cx@nospam.invalid wrote: Geez, can you whine some more? Most people are running wxPython just fine, Most people? What percentage of actual Python users do you think have wxPython installed? If you're really claiming it's over 50%, you're out of your mind. Oh, sorry, I forgot that I have to type slower so that you can follow along. We were discussing your 'enormous pain' installing wxPython. I find it interesting that you selectively quoted part of one line of my post, leaving out the remainder of the sentence that establishes context. It confirms the earlier observation that you're just trolling. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Peter Decker [EMAIL PROTECTED] writes: We were discussing your 'enormous pain' installing wxPython. I find it interesting that you selectively quoted part of one line of my post, Yes, the one line I quoted was the one that said most people have wxPython installed, which is a preposterous claim. The reason they don't have it installed is they don't have reason to go through the hassle of installing it, given (among other things) that tkinter is already there. If they don't want to go through that hassle, I don't see why I should want to go through it. As for installing from source, well, that's what I see the whole FOSS movement as being about. If I can't compile the source, why should I care about having it? And if I don't care about having it, what's the point of FOSS? Source that I can't compile is not much better than no source. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 15:26 -0400, Mark Roseman wrote: How can I embed a browser in Tk (I mean a real browser, like Mozilla, Safari, or even Exploder)? At all? On any platform? This has always been the tradeoff for Tk. Try this as one example: http://wiki.tcl.tk/4094 Okay, I figured if any, Win32 would be the one that worked, and I even recall seeing this example at one time. However, last time I checked, this bit of code wasn't actually working (although it may have been a temporary situation). Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I'd respectfully disagree (having done large, real-world Tk apps). You're right that Tk has a slow learning curve, which makes it easy to knock out simple interfaces really quickly - and generally ones that are not too impressive looking. You can do more sophisticated ones, and ones that blend properly into the platforms you're working on - however, the amount of effort and learning curve increase substantially. This is because you end up needing to do a lot more fiddling, looking at or using any of a large number of add-on packages, etc.). Yes, this was my finding with Tk. I ended up using Pmw.MegaWidgets and a few other things to make up for deficiencies in the core library, but mostly I found a need to write highly sophisticated controls myself, many of which were simply provided by wxPython. I was spending more time writing controls than writing applications. It was kind of fun and interesting, but not very productive. This is what prompted my move to wxPython several years ago. I still believe wxPython to be a much more rapidly evolving toolkit (although my tracking of Tk has fallen to almost nil since the switch so I'm willing to stand corrected or at least leave the point open to debate). The native look-and-feel across all platforms was another big motivation, but no the primary one. Mostly I found that the steeper learning curve paid off quite well in the long run. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 01 Aug 2005 13:38:21 -0700, Paul Rubin http://phr.cx@nospam.invalid wrote: Peter Decker [EMAIL PROTECTED] writes: We were discussing your 'enormous pain' installing wxPython. I find it interesting that you selectively quoted part of one line of my post, Yes, the one line I quoted was the one that said most people have wxPython installed, which is a preposterous claim. OK, troll, the above is an actual quote. Now how about if I selectively quote part of one of your sentences instead? most people have wxPython installed Wow, how could you make such a claim!? Gee, isn't it interesting how you can distort someone's intent by leaving out certain parts of what they wrote? Well, I think you've adequately displayed your integrity here in your desperate attempt to convert everyone to your One True Purist Faith. I'm done feeding the troll. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 13:38 -0700, Paul Rubin wrote: Peter Decker [EMAIL PROTECTED] writes: We were discussing your 'enormous pain' installing wxPython. I find it interesting that you selectively quoted part of one line of my post, Yes, the one line I quoted was the one that said most people have wxPython installed, which is a preposterous claim. The reason they don't have it installed is they don't have reason to go through the hassle of installing it, given (among other things) that tkinter is already there. If they don't want to go through that hassle, I don't see why I should want to go through it. I seriously hope you are being intentionally obtuse, otherwise your difficulties with wxPython have acquired a sharply illuminated source. It was quite clear that by saying most people he was not referring to the set of most Python users, but rather the set of most people who have tried wxPython. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Kay Schluehr wrote: Reinhold Birkenfeld wrote: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Oh, I could imagine that a MFC-like wrapper around win32gui, or another one around Xlib wouldn't be slower that wxWidgets is today. Reinhold Hi Reinhold, did You have a look at 'venster'? http://venster.sourceforge.net/htdocs/index.html They even dropped win32gui and worked with ctypes and the Win32API reducing the C-footprint. For frameworks like Dabo, AnyGUI, PyGUI etc. this would be the right level to create an abstraction layer IMO. By the way the demo applications of venster run stable and fast on WinXP. Ah! No, I didn't know this. I don't need it, either ;) but good to know it exists. Of course, doing such a thing for Xlib is more complicated because it doesn't know native widgets (okay, you can use Athena et al., but who wants them today...). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I actually misunderstood your question about embedding a browser and thought for a while about what it would take to write or port a serious browser to use tkinter as its graphics layer. The resulting picture wasn't pretty. I wonder whether it's feasible in wxpython. I like the idea of a browser-like portable gui toolkit. Instead of merely wrapping some other widget set, you'd write your interface as an XML file using HTML-like interface elements. You'd have callbacks on the form submit buttons and optionally on the other input elements, and you could get at the elements through the XML DOM if you were so inclined (sort of like the HTML DOM that browsers expose through Javascript). Implementations could run on top of Tk, GTK, native Windows widgets, or whatever. The language probably shouldn't be exactly HTML (e.g. it should have some additional widgets), but maybe it could be close enough that people wanting to do so could use the various wysiwyg web-layout programs that are out there, to put interfaces together. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: It was quite clear that by saying most people he was not referring to the set of most Python users, but rather the set of most people who have tried wxPython. That wasn't clear to me. If that's what he meant, he should have said so. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 14:13 -0700, Paul Rubin wrote: Cliff Wells [EMAIL PROTECTED] writes: Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I actually misunderstood your question about embedding a browser and thought for a while about what it would take to write or port a serious browser to use tkinter as its graphics layer. The resulting picture wasn't pretty. I wonder whether it's feasible in wxpython. wxPython has a toy HTML renderer that allows embedding wxPython widgets directly into it. If you only need simple HTML it works great. It is also possible to embed IE, Safari and Mozilla (via wxMozilla) but you lose the ability to embed the wxPython widgets). I like the idea of a browser-like portable gui toolkit. Instead of merely wrapping some other widget set, you'd write your interface as an XML file using HTML-like interface elements. You'd have callbacks on the form submit buttons and optionally on the other input elements, and you could get at the elements through the XML DOM if you were so inclined (sort of like the HTML DOM that browsers expose through Javascript). Implementations could run on top of Tk, GTK, native Windows widgets, or whatever. Actually wxPython has this today (and has had for some time): you can build your interface code in XML and wxPython will build the interface on the fly. I played with it once as a method of building a dialog editor along the lines of VB, but the project I needed it for died and I didn't have time to finish. My discovery was that it was entirely doable though, had I had time to finish. In fact, with the XRC stuff in wxPython, you can even create custom controls with pure XML. I'm not sure how great this is for hand-built interfaces (but I haven't tried), but it seems ideal for automated generation of GUI's. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 14:16 -0700, Paul Rubin wrote: Cliff Wells [EMAIL PROTECTED] writes: It was quite clear that by saying most people he was not referring to the set of most Python users, but rather the set of most people who have tried wxPython. That wasn't clear to me. If that's what he meant, he should have said so. Paul, Honestly what appears to me to be happening here is that you have found yourself assailed on all sides and are perhaps getting a bit too quick with both your reading of posts and with your replies. The end result is you end up trying to defend your earlier statements, which, due to haste, were either worded incorrectly or based on incorrect interpretations of what others have said. Then because you feel under attack you are compelled to defend those statements further, quite probably against your own better judgement. I know I've contributed plenty to this situation (and I'll also admit to having been in similar situations before, and it's a lot easier to get into this situation than to get out of it), therefore I'll make you a deal: you slow down and put a bit more thought into your replies and I'll lay off the sideways comments and cut you some slack. In fact, enough having been said, I think I'll just try to let this thread die a natural death. Deal? Regards, Cliff P.S. I would have preferred to have made this off-list, but I can't figure out how I should decipher your email address. -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Paul Rubin http://[EMAIL PROTECTED] wrote: Cliff Wells [EMAIL PROTECTED] writes: Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I actually misunderstood your question about embedding a browser and thought for a while about what it would take to write or port a serious browser to use tkinter as its graphics layer. The resulting picture wasn't pretty. I wonder whether it's feasible in wxpython. I'll point out that this has been done (in fact, many times). For example: http://tkhtml.hwaci.com (Integrating Gecko in has also been done, as a side note). I'll highlight a meta-point regarding this thread: there's a lot of stuff in Tk that is available but not built into the standard library, nor necessarily well documented or even easy to find. While this is a sad state of affairs, and to my mind no excuse (even though this is a common situation with open source software), it emphasizes that a cursory look does not tell the whole story. While I certainly don't begrudge anyone their choice of tools, it's no surprise that someone who's become more familiar with wxPython would have an unduly low opinion of Tk. They've obviously spent more time overcoming the warts in wxPython, and wouldn't have spent comparable effort learning what it would take to overcome the warts in Tk - it just looks hopelessly flawed in comparison. Switch wxPython and Tk around in the above argument and I think the statements equally hold of course. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 17:54 -0400, Mark Roseman wrote: I'll point out that this has been done (in fact, many times). For example: http://tkhtml.hwaci.com (Integrating Gecko in has also been done, as a side note). Interesting. Your later point about hard to find is certainly correct as my searches (albeit not as in-depth as they could have been) turned up little in this regard. While I certainly don't begrudge anyone their choice of tools, it's no surprise that someone who's become more familiar with wxPython would have an unduly low opinion of Tk. They've obviously spent more time overcoming the warts in wxPython, and wouldn't have spent comparable effort learning what it would take to overcome the warts in Tk - it just looks hopelessly flawed in comparison. Well, as was mentioned earlier (by Paul I believe), life is too short, in this case, to become expert in more than one GUI toolkit (which as a whole, are a wart on the face of programming in general, IMHO). They are highly complex and require a large investment of time regardless of which you choose. People often cite one kit as being more pythonic than another, but frankly I've yet to see one that even remotely meets that (admittedly vague) criteria. I've made my choices based on my own criteria, and certainly I would not hesitate to recommend my choices to others. Frankly most of my ire in this thread has been over things tertiary to the toolkits themselves: 1) the idea of demanding that one toolkit be the preferred way 2) dismissing without due consideration the hard work of others who have volunteered their code without demand for recompense, and 3) what I've taken (rightly or wrongly) to be deliberate obtuseness on the part of some of the participants. Aside from that, I consider the choice of GUI toolkits to be a pretty benign issue and hardly one qualifying for the level of heat we've had for the last day or so. Switch wxPython and Tk around in the above argument and I think the statements equally hold of course. Agreed. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: On Sun, 2005-07-31 at 14:58 -0400, Mike Meyer wrote: And what do I use to bundle my application for Unix? Most of the things I build get installed on Unix servers. You install GUI apps on Unix *servers*? Yup. Thanks to the wonders of X, I can run GUI apps on servers and have them display on my desktop. Or my OS X laptop. I normally leave a gkrellm running on most of my servers. Of course, the problem under discussion isn't restricted to GUI apps. Anytime I use a third party library, I have to deal with how end users are going to get it. Regardless, when you say Unix, what do you mean? You may as well say OS as this term has little meaning. Linux (which flavor)? BSD? SCO? HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils hacking would solve your problem. I think the post I replied to covered the OS X case - there's an application bundler available for it already. I want distributions that will work on all three major BSD variants and most Linux distrubtions - in particular, anything that uses deb's, rpm's or emerge. If you want to choose one in particular, try ubuntu Linux. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Jorge Godoy [EMAIL PROTECTED] writes: Mike Meyer wrote: We already have multiple distributions of Python: CPython, IronPython, and Jython (and there's at least one more). We even have multiple distributions of CPython, what with Active State doing their own and the MacPython distribution. I'm not proposing a fundamental change in the world, I'm suggesting an addition that would satisify the OPs needs. The standard distributor is whichever one your organization settles on when it comes time to choose a Python distribution. So we don't solve the problem with a standard distribution and that was the point I was trying to show. Exactly what problem are you trying to solve? If it's the one about not having a standard GUI, I don't think it's a problem. In fact this sounds more like a joke I've heard a while ago: standards, if you don't like the ones out there, create your own. Works for me. None of which has stopped linux from following this path. And solve a completely different problem while sharing the very same problem you, on the post prior to mine, was trying to solve: what is the standard GUI on a Linux distribution? QVWM? WindowMaker? Gnome? KDE? FVWM? I think you have me confused with someone else. I was responding to someone who was claiming that the lack of a standard enterprise strength GUI toolkit was a serious problem for Python - I disagree. I won't recap the thread, but other languages have been *very* successful without having a GUI as part of the language, all they had was one development environment distributed with a GUI. BTW, in answer to your rhetorical question about GUI's for Linux, the answer is plwm. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Hallöchen! Mike Meyer [EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: [...] None of us has talked about changing syntax. However, the standard library is part of the language unless you're really very petty. Or you use different Python implementations. There are four different Python implementations in the world. Not everything in the CPYthon standard library runs in all of them. Or are you going to claim that someone usin Jython isn't using Python because they can't use the full standard library? Well, in a way, they aren't using Python indeed. For example, most Python books tell only partly the truth in this case. Well, in a way, you're right. On the other hand, Guido has always insisted that CPython is just an implementation, and not a definition. This is not a sign of decadence, but a very good promotional argument. But it's not required for the language to succeed. Today it is (except for very special-purpose languages). To put this differently, it's required if you want to succeed as a language for the specific purpose of creating GUI applications. I'd agree to that. But there are *lots* of other application areas around, so limiting your definition of success to that one field is very short-sighted. You have to take into account not only the number of application areas, but also their respective importance. True. To you, GUI applications are very important. To me, they pretty much don't matter at all. I'm interested in a language with a big community. This is my definition of success. It has to do with the functionality I can expect (more contributors can create more modules and documentation) and with future-proofness. GUI applications seem to be the most attractive application type. This is not only true for commercial programming. When I look at the most agile projects on Sourceforge, almost all of them have a GUI. Why restrict yourself to agile projects? For that matter, how do you decide if a project is agile or not? I won't argue that most of the projects on Sourceforge have GUIs - that's certainly true. I will argue that most of the projects are done in languages that aren't what you call GUI-aware. Therefore, GUI-aware languages attract much larger user bases, and so they cater my definition of being successful. Since you haven't stated what that definition is, I can't really say anything about this. If you're counting applications on sourceforge, the evidence doesn't support your conclusion. C and C++ are the most used languages by an order of magnitude, and neither of those has integral GUI support. [...] By which measure C is still immensely popular, because of the large number of older applications that are written in it that are available - Python being one such. Legacy code is not a sign of success IMO because it implies a difficult future. So you're saying that Python, Perl, Linux, the various BSD et. al. will have a difficult future? If you believe that about Python, then why are you here at all? [...] I'd say Python has succeeded as a web development language, and as a systems scripting language - and I've certainly missed some. I don't think that Python should rely on these old strongholds. In the biggest bookstore of our region, there is one book about Zope but a whole bookself about PHP. And I've never used consciously a Python system script in contrast to dozens of Perl scripts. Um - you should compare apples to apples. Zope is an application development framework, and doesn't really compete in the same space as PHP and Python. For that matter, as you note, PHP is a special-purpose language (for a very popular application area) whereas Python is general purpose language. As for system scripts, Python is the primary system scripting tool for a number of Linux distributions (gentoo and redhat come to mind), and if I understand correctly, it's also used pretty heavily in OS X. In contrast to PHP or Perl, I consider Python a general-purpose language. There is its future in my opinion. However, this area is much tougher, and you need a good GUI approach there. I know a large number of people who'd argue with you implying that Perl isn't a general-purpose language. It's more successful than Python pretty much across teh board. [...] Could it be that that's what you really want - someone to distribute Python bundled with an enterprise-class GUI library and IDE? Well, a nice thing to have, but besides my point. Then you seem to have missed some of your own points. C++ succeeded without having a standard GUI library. You claimed that that success was because of a single distribution that included the things you are looking for. Why can't the same thing work for Python? I just didn't say that it couldn't work. But I don't think it'll happen, that's all. Well, if you dismiss it out of hand, it certainly won't happen. Try asking
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 23:49 -0400, Mike Meyer wrote: Cliff Wells [EMAIL PROTECTED] writes: On Sun, 2005-07-31 at 14:58 -0400, Mike Meyer wrote: And what do I use to bundle my application for Unix? Most of the things I build get installed on Unix servers. You install GUI apps on Unix *servers*? Yup. Thanks to the wonders of X, I can run GUI apps on servers and have them display on my desktop. Or my OS X laptop. I normally leave a gkrellm running on most of my servers. Yes, yes. The wonders of X have been known to me since around 1992. Personally I avoid running GUI apps on my servers since they are usually unnecessary, waste memory, and if not used properly, open the door for security issues (for that matter, any extra piece of software installed opens the door for potential security issues so I tend to run stripped-down servers that only provide needed services - no fluff. Then again server is a pretty broad term. The bulk of my servers are shared and dedicated hosting environments where paranoia is rewarded. Your situation may be different). Of course, the problem under discussion isn't restricted to GUI apps. Anytime I use a third party library, I have to deal with how end users are going to get it. Absolutely. However GUI libraries tend to stick out a bit more since they tend to have a larger number of dependencies plus sheer code size and complexity makes platform-specific bugs more likely. Regardless, when you say Unix, what do you mean? You may as well say OS as this term has little meaning. Linux (which flavor)? BSD? SCO? HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils hacking would solve your problem. I think the post I replied to covered the OS X case - there's an application bundler available for it already. Yes, I've used it to bundle wxPython apps on 10.3. I want distributions that will work on all three major BSD variants and most Linux distrubtions - in particular, anything that uses deb's, rpm's or emerge. If you want to choose one in particular, try ubuntu Linux. OpenBSD: in portage FreeBSD: in portage 386BSD: don't know... does anyone still use this? NetBSD: included AFAICT Fedora: rpms available Debian: debs available Ubuntu: included Gentoo: in portage OS/X: available on wxpython.org FWIW, much of this info I found in less than 5 minutes using Google. I suppose with a little persistence you could have discovered it for yourself. Here's your Ubuntu instructions: http://wiki.wxpython.org/index.cgi/wxPython_20with_20Ubuntu Of course, if you are distributing end-user software by requiring users to install 3rd party packages themselves, then I hope you are distributing open source software. If it's a commercial/closed-source app you'll do far better by simply packaging all the requirements into the installer and installing it within the application's directory tree (this solves a lot of problems with version conflicts and user confusion). In my experience, binary packages work best for Windows and OS/X, and source distributions work best for Linux (mostly because building packages for Linux is a varied and sometimes painful process. Further Linux truly works best as a source-based system: you cannot always depend on ABI compatibility across versions of libraries - *usually* you can but... caveat emptor). Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 23:56 -0400, Mike Meyer wrote: I think you have me confused with someone else. I was responding to someone who was claiming that the lack of a standard enterprise strength GUI toolkit was a serious problem for Python - I disagree. I won't recap the thread, but other languages have been *very* successful without having a GUI as part of the language, all they had was one development environment distributed with a GUI. I think there's a lot of confusion in this thread. BTW, in answer to your rhetorical question about GUI's for Linux, the answer is plwm. Technically, a toolkit for building a window manager, not a GUI. But funny anyway ;) Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 00:18 -0400, Mike Meyer wrote: Or maybe you could switch to Jython, and just use swing? Man, c.l.py is getting *mean* ;) -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer wrote: Exactly what problem are you trying to solve? If it's the one about not having a standard GUI, I don't think it's a problem. Me neither. You pointed out that having a standard distribution made by some company would solve the non-standard GUI problem. I believe we share the same opinion, judging from this last post of yours. Maybe I missed something on your message and read it as if you had a different opinion. In fact this sounds more like a joke I've heard a while ago: standards, if you don't like the ones out there, create your own. Works for me. What works for you? You believe that chaos is better than having standards? I believe that flexibility is good, but not chaos. I think you have me confused with someone else. I was responding to someone who was claiming that the lack of a standard enterprise strength GUI toolkit was a serious problem for Python - I disagree. I I dunno. Maybe I confused your words. I agree on disagreeing ;-) won't recap the thread, but other languages have been *very* successful without having a GUI as part of the language, all they had was one development environment distributed with a GUI. One IDE, you mean? I believe the freedom to choose from multiple IDEs is also good. Some code on VI, others on Emacs, others on Eclipse, others on ... I agree that having multiple toolkits is good. BTW, in answer to your rhetorical question about GUI's for Linux, the answer is plwm. :-) And does it integrate well with common business apps, such as a mail client, note taking apps, addressbooks (with personal and shared entries), calendar with ability to share appointments, etc.? Be seeing you, -- Jorge Godoy [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
[EMAIL PROTECTED] (phil hunt) writes: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Not necessarily. My window manger is Python all the way down - it uses the Python Xlib implementation - and is plenty fast. Of course, it doesn't do a lot of graphics work, even for a window manager. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Paul McNett [EMAIL PROTECTED] writes: On Windows and Mac, you download the package and run through the wizard. Which package? I'm looking at the sourceforge download site, and don't see any packages for Python 2.4 on OS X 10.4. In fact, I don't see any packages for 10.4 at all. IIRC, they didn't have a 2.4 package last time I looked. I may download the 10.3 one and see if it works. Admittedly, installing from source is more difficult than any other project I've found, but still doable. Well, I've got a long history of installing things from source - going back to v6. On OS X, I like the darwin ports stuff, so I tried that: % sudo port install wxpython It blew up trying to compile wxpython. The multitude of dependencies all seemed to build find. Building wxpython from the source distribution by hand doesn't seem to fair any better. Could be that it's 10.4 problem that hasn't been diagnosed yet. We'll see if the FreeBSD port works any better. mike P.S. - no, this isn't just a theoretical exercise. I want to play with THE, and that's been rewritten from it's Mac-only version to use the Python wxWidgets wrapper. It's mostly curiosity, so I'm not willing to work very hard on it. If the dependencies will build out of the box - cool. If not - I have lots of other things to do. -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Mike Meyer wrote: Paul McNett [EMAIL PROTECTED] writes: On Windows and Mac, you download the package and run through the wizard. Which package? I'm looking at the sourceforge download site, and don't see any packages for Python 2.4 on OS X 10.4. In fact, I don't see any packages for 10.4 at all. IIRC, they didn't have a 2.4 package last time I looked. I may download the 10.3 one and see if it works. I can confirm that the 10.3 one works on Tiger. I think that Robin doesn't have a Tiger machine to build on yet, which is why there's no package for it. Perhaps more information is at the wxPython download site (not the Sourceforge one) at: http://wxpython.org/download.php Admittedly, installing from source is more difficult than any other project I've found, but still doable. Well, I've got a long history of installing things from source - going back to v6. On OS X, I like the darwin ports stuff, so I tried that: % sudo port install wxpython It blew up trying to compile wxpython. The multitude of dependencies all seemed to build find. Building wxpython from the source distribution by hand doesn't seem to fair any better. To build wxPython from source, you really need to follow Robin's detailed instructions in BUILD.txt, located somewhere in the source tree (I have to look for it every time, but I think it is in wxSrc/wxPython/docs/BUILD.txt). It isn't difficult but there's more to it than the standard ./configure;make;make install. P.S. - no, this isn't just a theoretical exercise. I want to play with THE, and that's been rewritten from it's Mac-only version to use the Python wxWidgets wrapper. It's mostly curiosity, so I'm not willing to work very hard on it. If the dependencies will build out of the box - cool. If not - I have lots of other things to do. I think you'll find that wxPython installs perfectly on Tiger using the package provided. Indeed, the only really painful platform to install wxPython on is Linux, where you pretty much need to build from source if you want the latest and greatest. -- Paul McNett http://paulmcnett.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger [EMAIL PROTECTED] wrote: Hallöchen! [EMAIL PROTECTED] (phil hunt) writes: [...] How about sometihing with the same API as Tkinter (so no need to relearn), but which looks prettier? Would that fix your gripes? I haven't learned Tkinter. You mightn't have, but I suspect more Python programers who've written GUI apps have used Tkinter than any of the other APIs. Not that I'm a particular fan of it, it's just I like standardisation, because then you get network effects. So for me, it needn't be like Tkinter. The three most important attributes for me are Pythonic, modern (both nice-looking and comprehensive), and non-niche. What you say Pythonic, what do you mean? And how do you rate Tkinter, PyGtk, PyQt/PyKDE, wxWindows for Pythonicness? -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! [EMAIL PROTECTED] (phil hunt) writes: On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (phil hunt) writes: [...] How about sometihing with the same API as Tkinter (so no need to relearn), but which looks prettier? Would that fix your gripes? I haven't learned Tkinter. [...] Not that I'm a particular fan of it, it's just I like standardisation, because then you get network effects. Me too. Therefore I'd like to see a new toolkit in the standard library to see a new network growing. You mustn't do something like this too often of course but I think in this case it would be the right time. So for me, it needn't be like Tkinter. The three most important attributes for me are Pythonic, modern (both nice-looking and comprehensive), and non-niche. What you say Pythonic, what do you mean? And how do you rate Tkinter, PyGtk, PyQt/PyKDE, wxWindows for Pythonicness? I don't like to set arguments to -1 or NULL, but to None. I'd like to have extensive support for keyword arguments. I don't like mucking about with ID values. Partly this is cosmetical but partly it's a rich source of errors. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 00:59 -0400, Mike Meyer wrote: I don't particularly like Tkinter, but it seems to me that it's pretty much won. It seems to be installed on every desktop platform along with Python. That means that if I want to distribute GUI apps, I'm going to cause the least headache for my end users by writing them in Tkinter. By this argument, we should just give up and use Visual* on Windows. The least headache for end users comes from properly packaging your application. End users shouldn't need to worry about installing third party packages (or even Python for that matter). Tools such as py2exe and Inno installer make this pretty simple on Windows, and py2app on OS/X accomplishes the same. It should be irrelevant to end users what libraries or tools you use to develop the app. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
On Sat, 2005-07-30 at 16:52 -0700, Bugs wrote: Cliff Wells wrote: But how stable is GTK on systems such as Windows and OS/X? That has been what has kept me from using it. Most GTK apps I've used on Windows (including the venerable GIMP) are nowhere near as stable as their Linux counterparts (although this may not be entirely the fault of GTK). Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to place on an end user. wxWidgets only uses GTK on Linux. On Windows and OS X it uses native widgets where possible. You missed my point. I'm advocating wxPython over PyGTK for this reason. I'm quite aware of how wxPython functions. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
[EMAIL PROTECTED] (phil hunt) writes: What you say Pythonic, what do you mean? And how do you rate Tkinter, PyGtk, PyQt/PyKDE, wxWindows for Pythonicness? Tkinter is not very Pythonic because it's sort of a Frankenstein hybrid of Python and Tcl, but at least it's there and it more or less works. The others are non-Pythonic because they're not included in the standard distro and therefore the Pythonic use the included batteries tenet says to use Tkinter despite its flaws. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells [EMAIL PROTECTED] writes: [...] The least headache for end users comes from properly packaging your application. End users shouldn't need to worry about installing third party packages (or even Python for that matter). Tools such as py2exe and Inno installer make this pretty simple on Windows, and py2app on OS/X accomplishes the same. Does py2exe work for all GUI libraries? It'll highly probably work with Tkinter, and I've read that it also works with pyGTK, but does it also work with wxPython or PyQt? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Cliff Wells [EMAIL PROTECTED] writes: application. End users shouldn't need to worry about installing third party packages (or even Python for that matter). Tools such as py2exe and Inno installer make this pretty simple on Windows, and py2app on OS/X accomplishes the same. It should be irrelevant to end users what libraries or tools you use to develop the app. What if I want to be able to write multi-platform applications without having to deal with OS-specific packaging schemes for every OS that I want to run on? Even if I only want to run on Linux, I don't see how to package a wxPython application to minimize end user hassle. The only realistic GUI's to use are Tkinter or HTTP/HTML over a local socket talking to a user-provided web browser. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 31 Jul 2005 08:22:23 +0200, Torsten Bronger [EMAIL PROTECTED] wrote: What you say Pythonic, what do you mean? And how do you rate Tkinter, PyGtk, PyQt/PyKDE, wxWindows for Pythonicness? I don't like to set arguments to -1 or NULL, but to None. Fair enough I'd like to have extensive support for keyword arguments. Tkinter has that -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
phil hunt wrote: OK, hows this for an idea: 1. create a new API, loosely based on the Tkinter API, but more Pythonic 2. implement Tk using this API (probably won't be difficult because we can use Tkinter as a base) 3. Implement bindings to Gtk and Qt/KDE using this API. Like PyGUI, more or less? http://www.cosc.canterbury.ac.nz/~greg/python_gui/ -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin http://[EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. However, OS'es and GUI libraries are different axes in the space of possibilities. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. However, OS'es and GUI libraries are different axes in the space of possibilities. I'm not sure what you mean. Whatever GUI library the Mac uses, py2exe doesn't work with it, since py2exe doesn't work for Macs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin http://[EMAIL PROTECTED] writes: Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. However, OS'es and GUI libraries are different axes in the space of possibilities. I'm not sure what you mean. I didn't ask does it work with OSX but does it work with wxPython or PyQt. py2exe only creates Windows files, that's right, but why is this important here? Be that as it may, some Google postings suggest that it works at least with wxPython. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. I didn't ask does it work with OSX but does it work with wxPython or PyQt. py2exe only creates Windows files, that's right, but why is this important here? You asked whether it works with all GUI libraries. If the context limited all to wxPython or PyQt, I missed that. At any rate, I believe it does work with wxPython under Windows. I don't know about PyQt. It doesn't work with any non-Windows libraries. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sunday 31 July 2005 01:02, phil hunt wrote: You mightn't have, but I suspect more Python programers who've written GUI apps have used Tkinter than any of the other APIs. Not that I'm a particular fan of it, it's just I like standardisation, because then you get network effects. At PyCon DC 2004, Guido was asked about wxPython: wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first. I don't think that this is a sign that we should discourage further work with wxPython. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
