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

[Ivan Kljaic]

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
penn&teller: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.

 

[rantingrick]

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 (horizontal&vertical)
* 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.

 

[Elias Fotinis]

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>

 

[rantingrick]

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.

 

[Chris Angelico]

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

 

[Billy Mays]

Opinion is divided on this… <http://bash.org/?152037>

There is another way: http://bash.org/?684045

 

[Chris Angelico]

As we all know you only need three types of geometry management:
 * Linear (horizontal&vertical)
 * 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

 

[sturlamolden]

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

 

[Andrew Berg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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

 

[sturlamolden]

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.

 

[sturlamolden]

That's eight.

Sorry, nine

 

[sturlamolden]

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

 

[Kevin Walzer]

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.

 

[sturlamolden]

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

 

[Dave Cook]

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

 

[Gregory Ewing]

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

 

[sturlamolden]

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

 

[sturlamolden]

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

 

[Hansmeet Singh]

lol isnt billy mays dead

There is another way: http://bash.org/?684045

 

[Steven D'Aprano]

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

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