Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 13, 5:22 am, CM cmpyt...@gmail.com wrote: On Jul 12, 5:18 pm, rantingrick rantingr...@gmail.com wrote: Kevin made the argument earlier that Tkinter (and others) are so easy to use that they render needing a GUI builder useless -- and he is correct! But did you know that there are GUI libraries EVEN more highly abstracted than Tkinter? Oh yes! So your OMG, this typing and using my imagination is so difficult *crap* is really making me laugh. My attitude is, if I could speak in English to an AI to tell it what I'd like the program to do, I'd do it. Yes, since I can't do that, I inevitably do sometimes enjoy puzzling things out, but only because I have to. PS: if you don't like to type, programming IS NOT the best career (or hobby) choice for you. I guess it is not so much that I dislike typing, as I dislike having to switch from visual mode to code mode, remember the keywords and such for the widgets, rather than quickly clicking around. The keystroke count is really just a proxy for that sort of effort. Yes. This is what is called the semantic gap. Say you were a programmer who had to write software for numerical analysis. Would you write it in assembly even if, say, you knew assembly very well? I contend that most sane programmers would choose an algebraic language because they understand (formally or intuitively it does not matter) that minimizing semantic gaps are best for programming. Writing text that indirectly describes a gui rather than directly drawing it is analogous to writing assembly that implies an algebraic operation instead of writing the algebra directly. As for Kevin's point: One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. I am not sure how to interpret that. If you are saying that most of today's gui builders are too close to suxware to be worth the time, I guess its true (and eminently practical) If on the other hand the claim is that the very idea of gui-builders is a flawed one I think the jury is still out on that. And the history of computer science repeatedly shows that very high level ideas take decades to enter the mainstream. Think of garbage collection in 1960 in the esoteric lisp finally getting mainlined in Java in 1995. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Thorsten Kampe wrote: * sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT)) On 11 Jul, 14:39, Ben Finney ben+pyt...@benfinney.id.au wrote: The Unix model is: a collection of general-purpose, customisable tools, with clear standard interfaces that work together well, and are easily replaceable without losing the benefit of all the others. This is opposed to the Windows model of a one-click installer for a monolithic application. Many Windows users get extremely frustrated when they have to use more than one tool. *sigh* There is no Windows nor Unix model. There is only you-get-what- you-pay-for. On Windows, you're a customer and the developer wants to make using his application as convenient as possible for you, the customer. That's an astonishing statement. Today, I started to update a commercial, proprietary Windows application, Quickbooks. I didn't actually get around to running the installer application yet, on account of the installer having trouble if your data is on a network share. (Apparently the developers of Quickbooks never considered that when you have multiple users connected to the same database at once, at least one of them must be accessing it over the network.) But in preparation for the process, I took note of the information needed to make QB run. I don't have the list in front of me, but there were something like 6 or 8 keys needed to make the software work: Customer account number Licence key Upgrade key Validation code etc. (I don't remember the full list. I try not to bring that part of my work home :) Or consider the Windows licence key, product activation code, etc. If as convenient as possible was their aim (as opposed to making a profit from licencing), then you wouldn't need all that. Why on earth should I have to install a Amazon MP3 Downloader app to purchase mp3s? Or the iTunes app? The internet and web browsers excel at making it easy to download files. Rather than taking advantage of that convenience, commercial vendors put barriers in the way and try to carve out little walled gardens. Did they not learn anything from AOL? Where is the Windows equivalent of yum or apt-get? Why isn't there a central repository of independent and third party Windows software? It seems clear to me that it is the major open source communities that aim for convenience, at the cost of the opportunity to sell licences. In fairness though, open source developers' idea of convenient is not always the same as mine. On Unix you don't pay and the developer couldn't care less if his application works together with application b or how much it takes you to actually get this damn thing running. That might have been true, oh, 20 years ago, but today, that's far less of a rule. Linux distros make interoperability far simpler. Some level of savvy is needed, but it is remarkable how much Linux software Just Works. In my experience, two categories of Linux software are generally hard to deal with: one-man projects (usually stuck on version 0.2b for the last seven years), and big, popular projects that have been taken over by developers from the Windows world (I'm looking at you, Firefox). YMMV. And as soon as developers start developing for Unix customers (say Komodo, for instance), they start following the Windows model - as you call it. Surely that's because Komodo started off as a Windows application before being ported to Unix? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.12 05:24 AM, Steven D'Aprano wrote: Rather than taking advantage of that convenience, commercial vendors put barriers in the way and try to carve out little walled gardens. Did they not learn anything from AOL? DRM and activation schemes will /always/ make things harder, but that is the cost of doing business, at least in the minds of commercial software vendors. There are actually a lot of good freeware (proprietary, but zero cost) apps out there. Some even better than open-source alternatives. I avoid commercial apps, though, since they tend to be far inferior to the alternatives (inconvenience aside). Where is the Windows equivalent of yum or apt-get? Why isn't there a central repository of independent and third party Windows software? If Microsoft made such a repository, how much of the repository would be high-quality open-source software, and how much would be commercial shovelware? Attempts at independent repos have been made, but they all fail because there's no effort among developers (especially developers of proprietary software), to package their software this way. These attempts also fail because they fail to gain support from users (a catch-22 where users don't bother because there's not much in the repo and there's not much in the repo because users don't bother). It seems clear to me that it is the major open source communities that aim for convenience, at the cost of the opportunity to sell licences. The developers of open-source projects often aim to please the user rather than make money. You'd think pleasing the user and making money would go hand-in-hand, but history has shown that the latter can be achieved with little thought of the former. That might have been true, oh, 20 years ago, but today, that's far less of a rule. Linux distros make interoperability far simpler. Some level of savvy is needed, but it is remarkable how much Linux software Just Works. At first, Linux had to learn how to crawl and then walk. Now it's doing gymnastics. :) In my experience, two categories of Linux software are generally hard to deal with: one-man projects (usually stuck on version 0.2b for the last seven years), and big, popular projects that have been taken over by developers from the Windows world (I'm looking at you, Firefox). YMMV. Firefox (and Thunderbird with it) are falling into the same trap that many fall into when they become popular. This is more prevalent among commercial apps, but it's not too surprising considering Firefox's popularity. The trap is making things shiny. That is, using UI designs (and to a lesser extent adding neat, but generally useless features) that appeal to the computer-illiterate masses who cling to something that looks neat, regardless of how useful it ultimately is. AFAICT, Mozilla's problem isn't that incompetent Windows-centric devs took over, but rather that Google and MS were stepping up their game with their respective browsers and is desperately trying not to lose market share. - -- CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOHC4EAAoJEPiOA0Bgp4/Lgm0IAOT+/LQNalPHm5pvt4ilF1yt RM9fPBSgAF5k9U8jWBuQy/V6QJ/a1Sfkzu8ulZ8TyAYS64quucIqTwMJugdTUmct KsGbDsyXg0FObMxNiKKFuZblVYOtnULkYtYZOxeE33qy+85X6NMuFUv7ARHaLi/3 1Bdmnsj43hRrzJ1Rwb8x+xbOmiq+fJ7199loPQ+unSu7s37NJoL1e1vFNnsmGz8A Jg58Q0MbGiwettPdM9ZySYWgTJhiawtEX4SF6YiQqf22e04OyPWyxUfejixnZNoQ 7vbksr9k8PQzuTlG2y3G1pJx6XGrxgOQuEoVjInMGbZW0tx43paJLEWCOcd38FI= =3FGv -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Tue, Jul 12, 2011 at 8:24 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Where is the Windows equivalent of yum or apt-get? Why isn't there a central repository of independent and third party Windows software? It seems clear to me that it is the major open source communities that aim for convenience, at the cost of the opportunity to sell licences. The nearest commercial equivalent is probably Apple's iTunes store. It manages to be the one place to go for iphone apps, many of which cost money. Upside: Developers know where to host their stuff if they want it to sell. Downside: Developers have to host it there if they want it to sell - and Apple snag 30% on the way through. I've not seen a Windows equivalent, but Microsoft could make one if they wanted to. All they need is for the next version of Windows to recommend that all software be signed, and make it somewhat awkward to install unsigned software, and that would be that. It would probably be the knell of Windows, but it could be done. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. I use a GUI builder because I'd rather click less than type more. I just tried that in Boa Constructor; with ~10 mouse clicks I produced 964 characters of Python code. Now, sure, depending on how I wrote the code I could do better than that, but for me, I just find it more intuitive and easier to use a GUI to make a GUI. Often a GUI builder is used as a bad replacement for sketch-pad and pencil. I would use a sketch-pad and pencil and *then* use the GUI builder. What's nice about a builder is one can move things around quickly and see the results in the real application, which one can never really see well on a paper sketch. You could use a mock-up program of course, but I feel you might as well do it in the builder because when you're satisfied with it you have a real runnable application instead of just a picture. Using a GUI builder with layout managers might actually feel awkward. It takes some getting used to in Boa, in my experience, but then it feels intuitive and I really like using sizers with Boa. It helps if you give your sizers descriptive names. Che -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 12, 1:43 pm, CM cmpyt...@gmail.com wrote: One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. I use a GUI builder because I'd rather click less than type more. I just tried that in Boa Constructor; with ~10 mouse clicks I produced 964 characters of Python code. Remember, it's NOT the length of the code that matters, no, it's the motion of the sources ocean. Did it produce rough seas full of spaghetti monsters? Or tranquil fjords worth pining over (sadly to death apparently?)? 1. Never judge the quality of code simply by it's length. Because if you do, some folks might suffer from source envy! Also, you MAY have created 964 chars of code with your ten or so clicks HOWEVER that is just template code. You'll need to set many attributes for the widgets before they are ready for prime time. Your supposed ten or so click estimate is very naive. It takes MUCH more to create even a simple GUI, because, we have NOT even discussed logic yet! Now, sure, depending on how I wrote the code I could do better than that, but for me, I just find it more intuitive and easier to use a GUI to make a GUI. Personal opinions should always be respected, and as such i respect yours but later i would outline my GUI design workflow so pay close attention. Often a GUI builder is used as a bad replacement for sketch-pad and pencil. I would use a sketch-pad and pencil and *then* use the GUI builder. But do you really? Your following statements lead me to believe that you don't. What's nice about a builder is one can move things around quickly and see the results in the real application, which one can never really see well on a paper sketch. I prefer to skip any pencil and paper completely myself. I just use my imagination. UNLESS the GUI is EXTREMELY complicated. For me the design of a GUI starts in my brain. No pencil, no paper, no three hours using Auto Cad GUI designer. Next i start creating widgets and laying them out using geometry managers (in CODE). Finally i run a few tests, make a few changes, and design phase is over. Time for logic. - My argument against GUI builders is two fold. - 1. GUI builders remove us from the initial mental design phase and temp us to let our inner click-ity-click and drag-ity-drag child loose. This inner child likes to play but he hates to plan. Very soon he has the play room floor (source code) overflowing with toys (code) arranged in a completely haphazard way. Unlike the child however, there is no code mommy to spank this bad little boy when he is a programmer. So he just keeps messing up play room after play room making a complete fool of himself along the way. 2. GUI builders remove us from the source code. When you are playing clicky-click with yourself you could be in the trenches fighting the spaghetti code monster. Instead you are losing mental focus. Remember, playing with yourself makes you lazy! -- What happens is... you get lost playing and fail to keep your mental focus. A programmers metal focus is his most valuable weapon in the fight against the spaghetti code monster. I am a programmer. I love my source code more than i love most people in this world. I do not want to be away from my source. I am jealous of my source! And so too should you be. Kevin made the argument earlier that Tkinter (and others) are so easy to use that they render needing a GUI builder useless -- and he is correct! But did you know that there are GUI libraries EVEN more highly abstracted than Tkinter? Oh yes! So your OMG, this typing and using my imagination is so difficult *crap* is really making me laugh. That is my argument people. Opinions may vary. Keep watch for the spaghetti code monster! Cheers folks. PS: if you don't like to type, programming IS NOT the best career (or hobby) choice for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 12, 5:18 pm, rantingrick rantingr...@gmail.com wrote: On Jul 12, 1:43 pm, CM cmpyt...@gmail.com wrote: One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. I use a GUI builder because I'd rather click less than type more. I just tried that in Boa Constructor; with ~10 mouse clicks I produced 964 characters of Python code. Remember, it's NOT the length of the code that matters, no, it's the motion of the sources ocean. Did it produce rough seas full of spaghetti monsters? Or tranquil fjords worth pining over (sadly to death apparently?)? In my experience, the GUI builder I use creates reasonable code that deals with the GUI in a separate portion of the code. It does not strike me as spaghetti-ish (though it's not perfect). Also, you MAY have created 964 chars of code with your ten or so clicks HOWEVER that is just template code. You'll need to set many attributes for the widgets before they are ready for prime time. Your supposed ten or so click estimate is very naive. It takes MUCH more to create even a simple GUI, because, we have NOT even discussed logic yet! Sure. But my point was just that to even get as far as I did (which was just a frame and two unspecified widgets) takes 964+ keystrokes, but only ~10 clicks. So the pacing of keystrokes:clicks is favorable. If I built a small functioning GUI application, it might take 100 clicks and 9,640 keystrokes (very roughly). But it is the same point. I would use a sketch-pad and pencil and *then* use the GUI builder. But do you really? Your following statements lead me to believe that you don't. What's nice about a builder is one can move things around quickly and see the results in the real application, which one can never really see well on a paper sketch. I just meant that though I might start on paper, once it is on the screen I sometimes will shift things around a bit at that point to see how it looks. This is easily done with sizers and a sizer collection manager and an up/down arrow, so it is worth an extra minute to just see how it looks. 1. GUI builders remove us from the initial mental design phase and temp us to let our inner click-ity-click and drag-ity-drag child loose. This inner child likes to play but he hates to plan. Very soon he has the play room floor (source code) overflowing with toys (code) arranged in a completely haphazard way. Unlike the child however, there is no code mommy to spank this bad little boy when he is a programmer. So he just keeps messing up play room after play room making a complete fool of himself along the way. 2. GUI builders remove us from the source code. When you are playing clicky-click with yourself you could be in the trenches fighting the spaghetti code monster. Instead you are losing mental focus. Remember, playing with yourself makes you lazy! I've certainly heard of others who feel that working with only code is cleaner for them, mentally speaking. I can understand that. I think it just depends on what one is used to. I don't find the GUI builder disrupts my ability to plan or keep things orderly. In fact, most of my disorder and spaghetti problems have been in the logic side of the applications, the part which the GUI builder doesn't have anything to do with. (That's my own issue to keep working on). Kevin made the argument earlier that Tkinter (and others) are so easy to use that they render needing a GUI builder useless -- and he is correct! But did you know that there are GUI libraries EVEN more highly abstracted than Tkinter? Oh yes! So your OMG, this typing and using my imagination is so difficult *crap* is really making me laugh. My attitude is, if I could speak in English to an AI to tell it what I'd like the program to do, I'd do it. Yes, since I can't do that, I inevitably do sometimes enjoy puzzling things out, but only because I have to. PS: if you don't like to type, programming IS NOT the best career (or hobby) choice for you. I guess it is not so much that I dislike typing, as I dislike having to switch from visual mode to code mode, remember the keywords and such for the widgets, rather than quickly clicking around. The keystroke count is really just a proxy for that sort of effort. CM -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 02:43, Adam Tauno Williams awill...@whitemice.org wrote: Because RAD tools are for GUI toolkits, not for languages. If you're using GTK, Glade works fine. Same with QT and QTDesigner. If you're using WPF with IronPython, t These [Glade, etc...] are *NOT* RAD tools. They are GUI designers. A RAD tool provides a GUI designer that can be bound to a backend [typically an SQL database]. RAD = GUI + ORM. The type speciemens for RAD tools were Borland Delphi and Microsoft Visual Basic. They were not a combination of GUI designer and SQL/ORM backend. They were a combination of GUI designer, code editor, compiler, and debugger. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 00:50, Ivan Kljaic iklj...@gmail.com wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? If you by RAD tool mean GUI builder, I'd recommend wxFormBuilder for wxPython, QtCreator for PyQt or PySide, and GLADE for PyGTK. Personally I prefer wxFormBuilder and wxPython, but it's a matter of taste. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 11, 2:42 am, Adam Tauno Williams awill...@whitemice.org wrote: But Open Source land is simply too fragmented. There are too many database bindings [and RAD requires something like an ORM (think SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list goes on and on]. Nothing can muster the gravity required to bring a quality RAD tool into existence. Why too many ? Natural selection is a GoodThing. Python is known as the language with more web frameworks than keywords, and this doesn't prevent some of these frameworks to be 1/ pretty good and 2/ becoming de facto standards. I also suspect - seeing some of the articles that float across the FLOSS-o-sphere mentioning RAD - that many Open Source developers have never had the pleasure [yes, it is a pleasure] of using a professional RAD tool. This is slightly arrogant. Did you occur to you that quite a few OSS developers may have at least as much experience as you do with these kind of tools and just happen to actually prefer the unix way of doing things ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
bruno.desthuilli...@gmail.com bruno.desthuilli...@gmail.com writes: On Jul 11, 2:42 am, Adam Tauno Williams awill...@whitemice.org wrote: But Open Source land is simply too fragmented. There are too many database bindings [and RAD requires something like an ORM (think SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list goes on and on]. Why too many ? Natural selection is a GoodThing. Natural selection is not a good thing. It is blind and unthinking and cruel and wasteful and haphazard and purposeless. Those aren't traits to recommend it, IMO. (It's also not a bad thing. Natural selection just is.) Natural selection is not what's happening here. Rather, *artifical* selection, with people as the agents of selection, have purposes and wants that guide their selections. It would be better to say: Competition can be (not an unalloyed “is”) a Good Thing. Python is known as the language with more web frameworks than keywords, and this doesn't prevent some of these frameworks to be 1/ pretty good and 2/ becoming de facto standards. Right. People are selecting web frameworks for their fitness to purposes, but their purposes are many and change over time. So there can be many such frameworks, of varying popularity, and that's a good thing. I also suspect - seeing some of the articles that float across the FLOSS-o-sphere mentioning RAD - that many Open Source developers have never had the pleasure [yes, it is a pleasure] of using a professional RAD tool. This is slightly arrogant. Did you occur to you that quite a few OSS developers may have at least as much experience as you do with these kind of tools and just happen to actually prefer the unix way of doing things ? Yes. As someone who has used some of those all-in-one one-size-fits-most tools, I can testify that their usefulness is severely limited when compared with the Unix model. The Unix model is: a collection of general-purpose, customisable tools, with clear standard interfaces that work together well, and are easily replaceable without losing the benefit of all the others. -- \ “Are you pondering what I'm pondering?” “Umm, I think so, | `\Brain, but what if the chicken won't wear the nylons?” —_Pinky | _o__) and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 14:39, Ben Finney ben+pyt...@benfinney.id.au wrote: The Unix model is: a collection of general-purpose, customisable tools, with clear standard interfaces that work together well, and are easily replaceable without losing the benefit of all the others. This is opposed to the Windows model of a one-click installer for a monolithic application. Many Windows users get extremely frustrated when they have to use more than one tool. There is also a deep anxiety of using the keyboard. This means that command line tools are out of the question (everything needs a GUI). In the Windows world, even programming should be drag-and-drop with the mouse. Windows programmers will go to extreme measures to avoid typing code on their own, as tke keyboard is so scary. The most extreme case is not Visual Basic but LabView, where even business logic is drag-and-drop. A side-effect is that many Windows developers are too dumb to write code on their own, and rely on pre-coded components that can be dropped on a form. A common fail-case is multiuser applications, where the developers do not understand anything about what is going on, and scalability is non-existent. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 7/10/11 6:50 PM, Ivan Kljaic wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? http://pyobjc.sourceforge.net/ -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
* sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT)) On 11 Jul, 14:39, Ben Finney ben+pyt...@benfinney.id.au wrote: The Unix model is: a collection of general-purpose, customisable tools, with clear standard interfaces that work together well, and are easily replaceable without losing the benefit of all the others. This is opposed to the Windows model of a one-click installer for a monolithic application. Many Windows users get extremely frustrated when they have to use more than one tool. *sigh* There is no Windows nor Unix model. There is only you-get-what- you-pay-for. On Windows, you're a customer and the developer wants to make using his application as convenient as possible for you, the customer. On Unix you don't pay and the developer couldn't care less if his application works together with application b or how much it takes you to actually get this damn thing running. And as soon as developers start developing for Unix customers (say Komodo, for instance), they start following the Windows model - as you call it. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 16:10, Thorsten Kampe thors...@thorstenkampe.de wrote: And as soon as developers start developing for Unix customers (say Komodo, for instance), they start following the Windows model - as you call it. You are probably aware that Unix and Unix customers have been around since the 1970s. I would expect the paradigm to be changed by now. S.M. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden sturlamol...@yahoo.no wrote: You are probably aware that Unix and Unix customers have been around since the 1970s. I would expect the paradigm to be changed by now. The paradigm of small tools that do exactly what they're supposed to, and can be combined? Nope. There's still a philosophy of services that fit together like a jigsaw puzzle, rather than expecting each application to do everything you want it to. A standard Unix command line might consist of three or more tools, piping from one into another - grep the Apache log for lines containing the name of a PHP script, pipe that into awk to pick up just the user name, IP address, and date (without time), then pipe into uniq (deliberately without first going through sort) to show who's been using the script lately. And then piped it through sed to clean up the format a bit. Yep, that's something I did recently. Point to note: This is the Unix *philosophy* versus the Windows *philosophy*, not Unix *programs* versus Windows *programs*. There are Windows programs that follow the Unix philosophy. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
* sturlamolden (Mon, 11 Jul 2011 07:21:37 -0700 (PDT)) On 11 Jul, 16:10, Thorsten Kampe thors...@thorstenkampe.de wrote: And as soon as developers start developing for Unix customers (say Komodo, for instance), they start following the Windows model - as you call it. You are probably aware that Unix and Unix customers have been around since the 1970s. I would expect the paradigm to be changed by now. For the /customers/ on Unix it never was a paradigm. They would have laughed in their vendor's face if they had gotten the here are the tools, just make them work together as you like attitude[1]. Thorsten [1] at least starting from the beginning of the nineties when commercial alternatives to Unix began to emerge -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 11, 7:39 pm, Chris Angelico ros...@gmail.com wrote: On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden sturlamol...@yahoo.no wrote: You are probably aware that Unix and Unix customers have been around since the 1970s. I would expect the paradigm to be changed by now. The paradigm of small tools that do exactly what they're supposed to, and can be combined? Nope. There's still a philosophy of services that fit together like a jigsaw puzzle, rather than expecting each application to do everything you want it to. A standard Unix command line might consist of three or more tools, piping from one into another - grep the Apache log for lines containing the name of a PHP script, pipe that into awk to pick up just the user name, IP address, and date (without time), then pipe into uniq (deliberately without first going through sort) to show who's been using the script lately. And then piped it through sed to clean up the format a bit. Yep, that's something I did recently. Point to note: This is the Unix *philosophy* versus the Windows *philosophy*, not Unix *programs* versus Windows *programs*. There are Windows programs that follow the Unix philosophy. ChrisA The intention of programming is to close the semantic gap. - It is a fundamental task of software engineering to close the gap between application specific knowledge and technically doable formalization. For this purpose domain specific (high-level) knowledge must be transferred into an algorithm and its parameters (low-level). (from http://en.wikipedia.org/wiki/Semantic_gap - A gui-builder reduces the semantic gap by showing a widget when the programmer things 'widget.' Banging out hundreds of lines in vi/emacs for the same purpose does a measurably poorer job. Note it can reduce but not close. By choosing fidelity to the gui we have corresponding less fidelity to the algos and data-structures [And one may assume that someone even using a gui toolkit wants to do something with the gui and not just paint the screen] Still it seems a bit naive to suggest that building a gui by a few pointclicks is 'windows-model' and banging out hundreds of lines in vi/emacs is 'unix-model.' It does disservice to python and to unix. If a student of mine came and said: Is Python better or Unix? he would receive a dressing down. And yet more than one person here seems to think such type-wrong comparisons are ok. I find this disturbing... -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Windows, you're a customer and the developer wants to make using his application as convenient as possible for you, the customer. So the well-behavioured, good-intentioned windows devs are making sure the customer feels pampered and cozy, how nice and dandy. On Unix you don't pay and the developer couldn't care less if his application works together with application b or how much it takes you to actually get this damn thing running. Now, on the other hand, the bad, bearded, grumpy and ugly unix devs want to make the customer's life miserable, bad boys.. What a load of bull, I am a unix developer and do _care_ for my customers, being them sysadmins, end users or even windows heads, and I am sure I am not the only one thinking this way. The windows way of doing things (user friendly experience, point and click, plug and play) etc is not a bad one at all, it consists of tools to allow developers who have lesser understanding about computers to create applications that will be used by users with also little understanding about computers in general, on the other hand, unix/linus/posix devs develop applications that can potentially be used more efficiently by people with great understanding about computers in general. Both have their user base, and this is IMO the primary reason why windows is the dominant OS currently, those with little understanding about computers and technology in general far outnumber those who do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Ivan Kljaic, 11.07.2011 00:50: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. Just a quick suggestion regarding the way you posed your question. It's usually better to ask if anyone knows a good tool to do a specific job (which you would describe in your post), instead of complaining about there being none. Even if you googled for it, you may have missed something because it's known under a different name or because it works differently than you expected. Also, as the answers show, your usage of the term RAD is ambiguous - not everyone seems to know what you mean with it. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 11, 11:33 am, rusi rustompm...@gmail.com wrote: A gui-builder reduces the semantic gap by showing a widget when the programmer things 'widget.' Banging out hundreds of lines in vi/emacs for the same purpose does a measurably poorer job. It is very rare to need to bang out hundreds of lines of code to replace a mouse click interface. If properly designed a good API can compete with a GUI. In far less time than it takes me to scroll down a list of widgets, pick the appropriate one, drag it across the screen, tinker with it's absolute position, and set some attributes, i could have typed Widget(parent, **kw).geometry(blah, blah) and been done. Note it can reduce but not close. By choosing fidelity to the gui we have corresponding less fidelity to the algos and data-structures [And one may assume that someone even using a gui toolkit wants to do something with the gui and not just paint the screen] Exactly. For this very reason i have always refused to used any point- and-click GUI builders. I prefer to get up-close and personal with my code bases. Of course i use high levels of API abstraction for most of the work, however i already know what is happening in the lower levels if i need to dive down one tier. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Tue, Jul 12, 2011 at 2:56 AM, rantingrick rantingr...@gmail.com wrote: It is very rare to need to bang out hundreds of lines of code to replace a mouse click interface. If properly designed a good API can compete with a GUI. In far less time than it takes me to scroll down a list of widgets, pick the appropriate one, drag it across the screen, tinker with it's absolute position, and set some attributes, i could have typed Widget(parent, **kw).geometry(blah, blah) and been done. Point to ponder: Human beings tend to memorize names better than images from long lists. Most widgets have names as well as appearances (although it's arguable that the appearance is more what the widget _is_, and the name is somewhat arbitrary), although in some cases there's odd pairings - some toolkits merge Radio Button and Check Box/Button into a single object, others call them two different things. To find the widget you need, you must either scroll a long list and pick the one you want, or key in - possibly with autocompletion assistance - the name. Which is easier to memorize? Which is easier to explain? I'd always rather work with the name. And even with the most point-and-clicky of interface designers, it's normal to be able to see the names of the objects you're working with. The one time where point and click is majorly superior to scripted design is with pixel positioning of widgets. You can drag things around until you're artistically happy with them, rather than have to fiddle with the numbers in code. That's how I learned to code GUIs, but when I started doing cross-platform work and discovered rule-based layouts (where you put objects in boxes and lay out the boxes in order, etc), suddenly life got a LOT easier. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Ok. I asked about this questio because I am working with python for the last 5 years and I am always in touch about signifigact things in Python. I am pissed of that I make my living by developing applications at work in Java an C#. My comPany would switch to python but they complained that there is not even one single gui builder or framework that can allow it to make a living from it. If you are going to say that there are also other libraries with every single one there is a significant problem that make the development painfull. About the natural selection... I'll say it with the words of pennteller:bullshit For how many years are this vui library wars going on. How many. Look. I am a open source supporter but Windows will always kick the ass of open source because the open source comunity can not make a decision. Just imagine what we would have today if the effort of development would have been used to develop one really good library. We would have kicked the ass of MS and steve balmer. The average user wants something simple and not something to program to do something. It looks that the firs linux os to realize that is successfull. I am talking about android. And the python development team is doing nothing to improve the situatio to solve this dispute that lasts for the last years by including the worthless Tk library and now upgrading it with Tix. To summarize it. It would be very helpfull for python to spread if there qould be one single good rad gui builder similar to vs or netbeAns but for python. So right now if i need to make a gui app i need to work with an applicatio that is dicontinued for the last 5 years is pretty buggy but is ok. If it would only be maintained and the libraby updated it would be great. When it comes to other application, sorry but they are just bad. Their userfriendlyness is simmilar to most of Ms products, they are user friendly but the problem is that they very wisely chose their friends. The ony worthly ones mentioning as an gui builder are boa constructor fo wx, qtDesigner with the famous licence problems why companies do not want to work with it, sharpdevelop for ironpython and netbeans for jython. Did you notice that 2 of these 4 are not for python? One is out of dTe and one has a fucked up licence. Sorry guys but there is not even one single rad gui tool for python as long as there is no serious guibuilder. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 11, 1:03 pm, Chris Angelico ros...@gmail.com wrote:
The one time where point and click is majorly superior to scripted
design is with pixel positioning of widgets. You can drag things
around until you're artistically happy with them, rather than have to
fiddle with the numbers in code.
This is true mostly for the new user of a GUI library or anyone
unlucky enough to use a poorly designed API(which leads into my next
response)
That's how I learned to code GUIs,
but when I started doing cross-platform work and discovered rule-based
layouts (where you put objects in boxes and lay out the boxes in
order, etc), suddenly life got a LOT easier.
A bit tangential however still relevant... i had always considered
Tkinter's three geometry managers (pack, place, and grid) to be
perfect. However lately i have been musing on the idea of rewriting
the pack API into something more intuitive like a linear-box-style
which then manifests itself in two forms; horizontal and vertical.
Of course you can create horizontal and vertical layouts ALREADY by
passing the side=LEFT or side=RIGHT to the pack geometry manager of
Tkinter widgets (TOP being the default BTW) but that fact isn't always
apparent to the new user as the full set of options are side={TOP|
BOTTOM|LEFT|RIGHT}.
And besides, the current API allows you to pack in all sorts of
ridiculous manners; BOTTOM, then TOP, then LEFT, then TOP, then RIGHT,
then TOP, then LEFT, then RIGHT, THEN GHEE WHIZ! Are you trying to win
the obfuscation award of the year here lad?
As we all know you only need three types of geometry management:
* Linear (horizontalvertical)
* Grid
* Absolute
Anything else is just multiplicity run a muck, again! And by
propagating such API's we also induce ignorance into our ranks. Before
we EVER consider a Python4000 we really need to clean up this
atrocious stdlib! It's like i tell people: when you keep screwing your
customers over then very soon you'll be out of buisness. Sure you can
make a decent living for a short time but the whole house of cards
comes crumbling down without the core base of repeat customers.
/food for thought
PS: I noticed that Python.org has a suggestion box now for which
modules we should be concentrating our community efforts. Well like
they say... imitation is the greatest form of flattery. And i am
quite flattered.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Mon, 11 Jul 2011 20:11:56 +0300, Stefan Behnel stefan...@behnel.de wrote: Just a quick suggestion regarding the way you posed your question. It's usually better to ask if anyone knows a good tool to do a specific job (which you would describe in your post), instead of complaining about there being none. Opinion is divided on this… http://bash.org/?152037 -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Tue, Jul 12, 2011 at 4:28 AM, Ivan Kljaic iklj...@gmail.com wrote: For how many years are this vui library wars going on. How many. Look. I am a open source supporter but Windows will always kick the ass of open source because the open source comunity can not make a decision. You think Microsoft makes decisions and sticks with them? Look at Office's last few versions. They can't decide on a file format, an interface, a featureset... everything keeps changing. The difference is that in the open-source world, everything survives and can be seen as a set of alternatives, whereas in the closed-source world, it's either different versions of one program (like MS Office), or competing products (which usually means one of them dies for lack of money - or is bought out by the other). What we have is not indecision, it is options. Imagine if you went to a hardware shop and were offered only one tool: a magnet. Would you laud them for making a decision and sticking with it? No, you'd wonder what they have against hammers and screwdrivers. I like to have tools available to my use, not someone else making my decisions for me. There's competition in the open source world, too; primarily competition for developer time, a quite scarce resource. If a toolkit is not of value to people, it won't get as many dev hours, so you can often gauge popularity and usefulness by the VCS checkins. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 11, 1:28 pm, Ivan Kljaic iklj...@gmail.com wrote: To summarize it. It would be very helpfull for python to spread if there qould be one single good rad gui builder similar to vs or netbeAns but for python. Well don't hold your breath friend because i have been ranting for years about the sad state of GUI libraries (not just in Python but everywhere). However if somehow we (the Python community) could grow a collective brain and build the three tiered system (that i proposed on THIS very list!) then we would have something that no one has! Yes, we would have a future! * Layer1: A 3rd party low level GUI library (owned by the python community) that will be the base from which to build the cake. A Gui library that carries the torch of true 21st century GUI's look and feel, and widgets! (aka: lots of C code here). * Layer2: An abstraction of Layer1 (written in 100% python) for the python std library. (think PythonGUI) * Layer3: A Graphical GUI builder front end for this expansive and beautiful library (so the kids can play along too). Yes, i DID mention a Graphical Builder. Even though i'd never use one, i DO realize the importance of such tools to this community. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Tue, Jul 12, 2011 at 4:52 AM, rantingrick rantingr...@gmail.com wrote: As we all know you only need three types of geometry management: * Linear (horizontalvertical) * Grid * Absolute I contend that Absolute is unnecessary and potentially dangerous. Grid and Box (linear) are the most flexible, but there are others that come in handy too. GTK has quite a few [1] including a scrollable, a notebook, hor/vert panes (where the user can adjust the size between the two panes), and so on. Once again, Ranting Rick is asking for all tools to be destroyed except his preferred minimal set. I think this strongly suggests that Rick is, in point of fact, either brain something'd (keeping this G-rated) or an orangutan, because the ultimate end of his logic is coding in either Brain-*[2] or Ook [3]. ChrisA [1] http://developer.gnome.org/gtk3/stable/LayoutContainers.html [2] http://www.muppetlabs.com/~breadbox/bf/ [3] http://www.dangermouse.net/esoteric/ook.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.11 02:16 PM, Chris Angelico wrote: You think Microsoft makes decisions and sticks with them? Look at Office's last few versions. They can't decide on a file format, an interface, a featureset... everything keeps changing. Of course they do. They've decided to change things in each major version to give people a reason to pay for the new version when there's nothing wrong with the old one (at least nothing that's been fixed in the new version :P ). Of course, MS is not the only software company that employs such a strategy... - -- CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOG1ORAAoJEPiOA0Bgp4/LF7oH/Al6RTGIQ2hAKztEiob/oXnz +eV8HZ0K+OBpd/FtRBkiMTJaQm5LU1jKPdwsf/RhF7UU69FfCQNfhzW5LsdMMQYE +lh4YwbJ8cXVEkCgdkf2zh7BElJ9/95nYedd64Ev4sG+QECvLFYoeql5mjcO45S9 V+iElE9y4FsPr1E0tC2BhFPQuiRMRIIOjQQ7UKP28dnIOKf6u9QM4UdN4WYKOy+n jgXRaFtstA3YtbzqmKfVoj9Go8SstF71XnGjSzAQeq4j96IfbvW/PTaPhkvyfB7y tHG861oW19orvZ1ESJue/lvd/KQ7rRDRn7IjH+fKvKuYlgjM3+Q7hR7hcXi97Wg= =a5A/ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 20:28, Ivan Kljaic iklj...@gmail.com wrote: To summarize it. It would be very helpfull for python to spread if there qould be one single good rad gui builder similar to vs or netbeAns but for python. So right now if i need to make a gui app i need to work with an applicatio that is dicontinued for the last 5 years is pretty buggy but is ok. http://wxformbuilder.org/ Shut up. The ony worthly ones mentioning as an gui builder are boa constructor fo wx, qtDesigner with the famous licence problems why companies do not want to work with it, sharpdevelop for ironpython and netbeans for jython. Did you notice that 2 of these 4 are not for python? One is out of dTe and one has a fucked up licence. Qt and PySide have LGPL license. QtCreator can be used with Python (there is a Python uic). SharpDevelop has an IronPython GUI builder. Boa Constructor is abandonware, yes. Is it just me, or did I count to three? And yes, you forgot: Visual Studio for IronPython wxGLADE for wxPython GLADE for PyGTK BlackAdder for Python and Qt SpecTcl for Tkinter That's eight. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 21:58, sturlamolden sturlamol...@yahoo.no wrote: That's eight. Sorry, nine ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 20:28, Ivan Kljaic iklj...@gmail.com wrote: The ony worthly ones mentioning as an gui builder are boa constructor fo wx, qtDesigner with the famous licence problems why companies do not want to work with it, sharpdevelop for ironpython and netbeans for jython. There is wxFormBuilder for wxPython, I suppose you've missed it. Of three GUI builders for wxPython (wxFormBuilder, wxGLADE, Boa Constructor), you managed to pick the lesser. The license for Qt is LGPL, the same as for wxWidgets. Both have LGPL Python bindings (PySide and wxPython), so why is Qt's license more scary than wxWidgets? I have an idea why you think QtCreator cannot be used with Python. If you had actually used it, you would have noticed that the XML output file can be compiled by PyQt and PySide. SharpDevelop for IronPython means you've missed Microsoft Visual Studio. Bummer. And I am not going to mention IBM's alternative to NetBeans, as I am sure you can Google it. And did you forget abpout GLADE, or do you disregard GTK (PyGTK) as a toolkit completely? Regards, Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Monday, 11 July 2011 00:50:31 UTC+2, Ivan Kljaic wrote: But seriously. Why is the not even one single RAD tool for Python. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? The set of reasons that nobody else has made one is *exactly* the same set of reasons that you're not going to make one. Note that if you prove me wrong, and make one, I still win ;) I am in the somewhat interesting position of having worked continuously with both Python and Delphi (yes, formerly by Borland) for the last decade. I like to think I use both languages/tools idiomatically. I used to lament not having a GUI builder like the Delphi IDE for Python, but I don't any more. Use the right tool for the job, and all that old-timer stuff is starting to make sense. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 21:58, sturlamolden sturlamol...@yahoo.no wrote: http://wxformbuilder.org/ This Demo is using C++, it works the same with Python (wxPython code is generated similarly). http://zamestnanci.fai.utb.cz/~bliznak/screencast/wxfbtut1/wxFBTut1_controller.swf Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 7/11/11 2:28 PM, Ivan Kljaic wrote: Did you notice that 2 of these 4 are not for python? One is out of dTe and one has a fucked up licence. Sorry guys but there is not even one single rad gui tool for python as long as there is no serious guibuilder. One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. Certainly with the Tkinter library this is trivial. The only GUI builder I've ever used that was arguably superior to hand-coding is Interface Builder, on Mac OS X, and it's truly needed there. (The Cocoa frameworks don't really lend themselves to hand-coding.) Otherwise I find GUI builders inflexible, and more trouble than they are worth. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 11 Jul, 22:35, Kevin Walzer k...@codebykevin.com wrote: One reason there hasn't been much demand for a GUI builder is that, in many cases, it's just as simpler or simpler to code a GUI by hand. Often a GUI builder is used as a bad replacement for sketch-pad and pencil. With layout managers (cf. wxWidgets, Qt, Swing, SWT, Tkinter) it is easier to sketch and code than with common MS Windows toolkits (eg. MFC, .NET Forms, Visual Basic, Delphi) which use absolute positioning and anchors. Using a GUI builder with layout managers might actually feel awkward. But with absolute positioning and anchors, there is no way to avoid a GUI builder. That said, we have good GUI builders for all the common Python GUI toolkits. Sometimes a mock-up GUI designer like DesignerVista might help. Yes, and actually hiring a graphical designer helps too. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 2011-07-10, Ivan Kljaic iklj...@gmail.com wrote: a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. I prefer spec-generators (almost all generate XML these days) like QtDesigner to code-generators like Boa. I've only seen one good argument for code generation, and that's to generate code for a layout to see how it's done. But code could always be generated automatically from a spec. I already have an editor I like, I don't see the need to tie GUI layout to a code editor. If you want something with more sophisticated Python specific features, there's PyDev. Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Chris Angelico wrote: either brain something'd (keeping this G-rated) or an orangutan, There's a certain librarian who might take issue with your lumping orangutans in with the brain-something'd... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Ivan Kljaic iklj...@gmail.com writes: My comPany would switch to python but they complained that there is not even one single gui builder or framework that can allow it to make a living from it. That response from your company is a non sequitur. What does “one single gui builder or framework” have to do with “allow it to make a living from it”? Evidently many organisations are making a living with Python, so that statement is just false. For how many years are this vui library wars going on. How many. Why see it as a war that must have one clear winner? You have options. I am a open source supporter but Windows will always kick the ass of open source because the open source comunity can not make a decision. Different people make different decisions. If you want a monolithic organisation that makes a single decision for everyone, you don't want software freedom. To summarize it. It would be very helpfull for python to spread Please find a different language to “fix”; Python is spreading quite successfully. -- \ “I don't like country music, but I don't mean to denigrate | `\ those who do. And for the people who like country music, | _o__)denigrate means ‘put down’.” —Bob Newhart | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 12 Jul, 01:33, Dave Cook davec...@nowhere.net wrote: I prefer spec-generators (almost all generate XML these days) like QtDesigner to code-generators like Boa. I've only seen one good argument for code generation, and that's to generate code for a layout to see how it's done. But code could always be generated automatically from a spec. wxFormBuilder will produce C++, Python and XML. Pick the one you like! The advantage of using XML in tools like GLADE, QtCreator, and more recently Visual C#, is separation of layout and program logic. The problem with code generators like Visual C++ or Delphi was the mixing of generated and hand-written code. However, there is no real advantage over using XML instead of C++ or Python: C++ and Python code are also structured text. One structured text is as good as another: There once was a man who had a problem. He said: 'I know, I will use XML.' Now he had two problems. When using wxFormBuilder, the generated .cpp, .h, .py or .xrc files are not to be edited. To write event handlers, we inherit from the generated classes. Thus, program view (generated code) and program control (hand-written code) are kept in separate source files. Because C++ and Python have multiple inheritance, we can even separate the program control into multiple classes. What we instantate is a class that inherit the designed dialog class (generated) and event handler classes (hand-written). Therefore, XML has no advantage over Python in the case of wxFormBuilder. XML just adds a second layer of complexity we don't need: I.e. not only must we write the same program logic, we must also write code to manage the XML resources. Hence, we are left with two problems instead of one. This is not special for wxFormBuilder: In many cases when working with Python (and to somewhat lesser extent C++), one is left to conclude that XML serves no real purpose. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On 12 Jul, 01:33, Dave Cook davec...@nowhere.net wrote: I prefer spec-generators (almost all generate XML these days) like QtDesigner to code-generators like Boa. I've only seen one good argument for code generation, and that's to generate code for a layout to see how it's done. But code could always be generated automatically from a spec. wxFormBuilder will produce C++, Python and XML. Pick the one you like! The advantage of using XML in tools like GLADE, QtCreator, and more recently Visual C#, is separation of layout and program logic. The problem with code generators like Visual C++ or Delphi was the mixing of generated and hand-written code. However, there is no real advantage over using XML instead of C++ or Python: C++ and Python code are also structured text. One structured text is as good as another: There once was a man who had a problem. He said: 'I know, I will use XML.' Now he had two problems. When using wxFormBuilder, the generated .cpp, .h, .py or .xrc files are not to be edited. To write event handlers, we inherit from the generated classes. Thus, program view (generated code) and program control (hand-written code) are kept in separate source files. Because C++ and Python have multiple inheritance, we can even separate the program control into multiple classes. What we instantate is a class that inherit the designed dialog class (generated) and event handler classes (hand-written). Therefore, XML has no advantage over Python in the case of wxFormBuilder. XML just adds a second layer of complexity we don't need: I.e. not only must we write the same program logic, we must also write code to manage the XML resources. Hence, we are left with two problems instead of one. This is not special for wxFormBuilder: In many cases when working with Python (and to somewhat lesser extent C++), one is left to conclude that XML serves no real purpose. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Excerpts from Ivan Kljaic's message of Sun Jul 10 18:50:31 -0400 2011: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? What is RAD? If you're just looking for a GUI builder there's Glade for gtk, wxGlade for wxWidgets, QtCreator (And something new for their newer system, don't remember the name), etc. -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Jul 10, 6:50 pm, Ivan Kljaic iklj...@gmail.com wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? Just because Boa Constructor stopped (or lengthily paused?) development doesn't mean it doesn't exist. It does, and (at least on Windows), it is, IMO, really good. So why don't you use it? Che -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Sun, Jul 10, 2011 at 3:50 PM, Ivan Kljaic iklj...@gmail.com wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? -- Because RAD tools are for GUI toolkits, not for languages. If you're using GTK, Glade works fine. Same with QT and QTDesigner. If you're using WPF with IronPython, there's plenty of tools out there for you to use. And Boa Constructor isn't the only RAD tool for wx- you can also use wxGlade, which can output code in several languages in addition to XRC files (an XML file you can load into wx from any language) http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
On Sun, 2011-07-10 at 15:50 -0700, Ivan Kljaic wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? I've pondered this myself, for a long time - since I could use RAD to build very nice applications using Borland's OWL on Windows For Workgroups it is sad. But Open Source land is simply too fragmented. There are too many database bindings [and RAD requires something like an ORM (think SQLalchemy)] and far too many GUI toolkits [Qt, Gtk, wx, and the list goes on and on]. Nothing can muster the gravity required to bring a quality RAD tool into existence. I also suspect - seeing some of the articles that float across the FLOSS-o-sphere mentioning RAD - that many Open Source developers have never had the pleasure [yes, it is a pleasure] of using a professional RAD tool. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Because RAD tools are for GUI toolkits, not for languages. If you're using GTK, Glade works fine. Same with QT and QTDesigner. If you're using WPF with IronPython, t These [Glade, etc...] are *NOT* RAD tools. They are GUI designers. A RAD tool provides a GUI designer that can be bound to a backend [typically an SQL database]. RAD = GUI + ORM. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
As someone who was a Visual Studio user for many years, I felt much the same way you do when I made the jump to Python on Linux last year. But then I discovered Glade and am quite satisfied. Glades UI design paradigm is a little different than that of VS but it's not so hard that you couldn't learn it in a week. It's very usable, pretty easy to learn, and doesn't cost you a penny. If you've not already, I recommend you check out Glade. I think it's probably what you're looking for. Anthony On 7/10/11, Ivan Kljaic iklj...@gmail.com wrote: Ok Guys. I know that most of us have been expiriencing the need for a nice Gui builder tool for RAD and most of us have been googling for it a lot of times. But seriously. Why is the not even one single RAD tool for Python. I mean what happened to boa constructor that it stopped developing. I simply do not see any reasons why there isn't anything. Please help me understand it. Any insights? -- http://mail.python.org/mailman/listinfo/python-list -- Anthony Papillion Advanced Data Concepts Get real about your software/web development and IT Services Phone: (918) 919-4624 Does your business need to reduce its phone bill? I can help! Email me and ask me how! -- http://mail.python.org/mailman/listinfo/python-list
