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

[Ivan Kljaic]

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?

 

[Corey Richardson]

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

 

[CM]

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

 

[Adam Tauno Williams]

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]

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.

 

[Anthony Papillion]

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

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?

--
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!

 

[sturlamolden]

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]

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

 

[bruno.desthuilliers]

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 ?

 

[sturlamolden]

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

 

[Kevin Walzer]

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/

 

[Thorsten Kampe]

* sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT))

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

 

[sturlamolden]

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.

 

[Thorsten Kampe]

* sturlamolden (Mon, 11 Jul 2011 07:21:37 -0700 (PDT))

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

 

[Chris Angelico]

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

 

[rusi]

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

 

[Speedbird]

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.

 

[rantingrick]

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.

 

[Stefan Behnel]

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

 

[Chris Angelico]

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