Wgy isn't there a good RAD Gui tool fo python

Discussion in 'Python' started by Ivan Kljaic, Jul 10, 2011.

  1. Ivan Kljaic

    Ivan Kljaic Guest

    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?
    Ivan Kljaic, Jul 10, 2011
    #1
    1. Advertising

  2. 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.17 (GNU/Linux)

    iQEcBAEBCAAGBQJOGi/aAAoJEAFAbo/KNFvpMWsH/3WDRZSvqSK6e456klZvf7J3
    w/E8GBCNVLgGVLqbcfzlk770bvC0NNyKOTjnN3RsneRmSinvg9C7R+qZhwGTx8in
    3kPYoVcZo+Prn/MzN/uhwg4SgTH8uXpjqd2ukf1frjNA/rOEV6o/se9igFo2MwBH
    Qrw7krmYyIl1pglPEg2gLBCuKz/V1yV/Y2IgHOR1yCJe8pCWbC2gwRDvTf6YD1uB
    TTsybTHmw6jxYu4i7BjOXudMC96Hr91ZfI8UTTP9w+vilT9nQoV/BoffJ+m4+oAL
    Ty9KTioCQSBgMcyTt/kV7YcsE8Qlcq1A1iJ7hYNrFHbLmsmC3s40yeFhKHctgCc=
    =jb+H
    -----END PGP SIGNATURE-----
    Corey Richardson, Jul 11, 2011
    #2
    1. Advertising

  3. Ivan Kljaic

    CM Guest

    On Jul 10, 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?


    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
    CM, Jul 11, 2011
    #3
  4. 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.
    Adam Tauno Williams, Jul 11, 2011
    #4

  5. >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.
    Adam Tauno Williams, Jul 11, 2011
    #5
  6. 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 <> 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!
    Anthony Papillion, Jul 11, 2011
    #6
  7. Ivan Kljaic

    sturlamolden Guest

    On 11 Jul, 00:50, 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?


    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
    sturlamolden, Jul 11, 2011
    #7
  8. Ivan Kljaic

    sturlamolden Guest

    On 11 Jul, 02:43, Adam Tauno Williams <> 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
    sturlamolden, Jul 11, 2011
    #8
  9. Ivan Kljaic

    Guest

    On Jul 11, 2:42 am, Adam Tauno Williams <>
    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 ?
    , Jul 11, 2011
    #9
  10. Ivan Kljaic

    sturlamolden Guest

    On 11 Jul, 14:39, Ben Finney <> 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
    sturlamolden, Jul 11, 2011
    #10
  11. Ivan Kljaic

    Kevin Walzer Guest

    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
    Kevin Walzer, Jul 11, 2011
    #11
  12. * sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT))
    > On 11 Jul, 14:39, Ben Finney <> 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
    Thorsten Kampe, Jul 11, 2011
    #12
  13. Ivan Kljaic

    sturlamolden Guest

    On 11 Jul, 16:10, Thorsten Kampe <> 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.
    sturlamolden, Jul 11, 2011
    #13
  14. * sturlamolden (Mon, 11 Jul 2011 07:21:37 -0700 (PDT))
    > On 11 Jul, 16:10, Thorsten Kampe <> 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
    Thorsten Kampe, Jul 11, 2011
    #14
  15. On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden <> 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
    Chris Angelico, Jul 11, 2011
    #15
  16. Ivan Kljaic

    rusi Guest

    On Jul 11, 7:39 pm, Chris Angelico <> wrote:
    > On Tue, Jul 12, 2011 at 12:21 AM, sturlamolden <> 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
    point&clicks 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...
    rusi, Jul 11, 2011
    #16
  17. Ivan Kljaic

    Speedbird Guest

    > 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.
    Speedbird, Jul 11, 2011
    #17
  18. Ivan Kljaic

    rantingrick Guest

    On Jul 11, 11:33 am, rusi <> 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.
    rantingrick, Jul 11, 2011
    #18
  19. 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
    Stefan Behnel, Jul 11, 2011
    #19
  20. On Tue, Jul 12, 2011 at 2:56 AM, rantingrick <> 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
    Chris Angelico, Jul 11, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Edilmar
    Replies:
    9
    Views:
    820
    Fredrik Lundh
    Aug 7, 2003
  2. Michael Ekstrand
    Replies:
    3
    Views:
    394
    Ravi Teja
    Mar 9, 2006
  3. Luca

    Java/J2EE RAD tool

    Luca, Oct 17, 2006, in forum: Java
    Replies:
    0
    Views:
    402
  4. johnny

    Any good RAD C++ tool

    johnny, Jan 28, 2007, in forum: C++
    Replies:
    5
    Views:
    492
    Ian Collins
    Jan 28, 2007
  5. Atlas

    RAD tool

    Atlas, Oct 23, 2003, in forum: ASP General
    Replies:
    3
    Views:
    98
    Atlas
    Oct 24, 2003
Loading...

Share This Page