Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

Wolfgang Keller feliphil at gmx.net
Mon Jun 11 07:55:51 EDT 2012


> > What "GUI designer" would come the closest to the way that Cocoa's
> > Interface Builder works? I.e. is there any one (cross-platform) that
> > allows to actually "connect" the GUI created directly to the code
> > and make it available "live" in an IDE?
> >
> > This whole cycle of "design GUI"->"generate code"->add own code to
> > generated code"->"run application with GUI" has always seemed very
> > un-pythonic to me. A dynamic, interpreted language should allow to
> > work in a more "lively", "direct" way to build a GUI.
> 
> I'm curious about your point but I don't really understand it.  Could
> you try again without using any scare-quoted words?

myidea.explanation.retry()

Python has this insanely great thing that e.g. Delphi, Java, C#, Visual
Basic, etc. lack and that's called an interactive commandline
interpreter, which allows you to build GUIs while exploring/trying out
the API of a GUI framework step by step. You simply type the code for
the GUI at the python prompt and your GUI comes directly to life.
Here's an example by someone else:

http://pysnippet.blogspot.de/2010/11/getting-interactive-with-pyqt.html

Now "just" (sorry for those quotes again) imagine a GUI builder that
generates _and_ _runs_ the code (pyqt, wxpython, pygtk, whatever) for
the GUI you edit _while_ you do so.

And now imagine that this GUI builder would be integrated with the IDE
you use (I use one), so that the GUI code is run in the same
interpreter instance as the other code of your application. So that you
can directly interact with your application through the GUI you build
while you do so.

The advantage of using a GUI builder over typing the code into the
interpreter window would be that users who rarely implement a GUI(*)
would not need to re-dig into the details of the API every time. This is
especially tedious since those APIs are essentially C++ APIs wrapped
in Python and thus they are honestly simply §$%&@# to use for a certain
type of Python user(*). And the lack of Python-specific documentation,
tutorials etc. doesn't really help. Did I mention yet that just having
to read C++ example code in documentation makes me spill my last meal
over keyboard, screen etc.?

Of course there's PyGUI, but that's unfortunately far from being as
complete as PyQt or wxPython and unless someone creates something like
an equivalent of Apache Software Foundation for Python, declares PyGUI
as the canonical Python GUI framework and funds the work needed to
complete it... And then you still need a GUI builder for it. *sigh*

> Maybe given an example of creating a small text editor application
> with a GUI builder/ IDE in this Pythonic way you are hoping for.

I'm not into text editors as example applications since I don't
develop text editors, I rarely even use one. And besides, I don't think
any typical user(*) of such a GUI builder would ever implement a text
editor in his whole life.

Personally, my typical use of such a GUI builder would be for database
applications. Which make up, according to my experience, for at least
90% of all custom-built applications in companies. Today, these
applications have to be made by external, paid developers who have
typically no clue of the application domain in question. Consequently,
the applications, no matter how many pages of detailed specifications
you as the domain expert write, never do what you wanted them to do.
Although just writing the specification takes more time than it would
take to implement it myself if only the (GUI) tools and (GUI)
frameworks(**) for Python would be at the level required to make them
useful for such "developers" as me(*). And did I mention that the cost
of external developers (plus the overhead cost for interaction with
them) makes them prohibitive anyway? And did I mention that the time
required such external development (plus the overhead time for
interaction with the external developers) takes doesn't help either?

* Such as "casual" Python scripting dilettants who are not full-time
software developers but domain experts who just use Python to help get
their main work done.

** In my case of database applications, something like this:
http://www.nakedobjects.org/book/
http://www.nakedobjects.org/downloads/Pawson%20thesis.pdf

Sincerely,

Wolfgang



More information about the Python-list mailing list