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*

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,

The current GUI frameworks which are available for Python require way
too much "glue code" that needs to be written by hand, imho simply
because they are primitive wrappers around frameworks for C++
developers who are used to such bulkloads of slave labour. Python as a
language is way ahead of C++, Java, C# etc. in terms of functionality
that you can implement per coding effort required , but it simply lacks
GUI frameworks and corresponding development tools that are equally
efficient.

And Apple's "product politics", oh, well, errr, uhm, don't get me into
that... *sigh*. If only all those third-party applications for MacOS X
were available on Linux, I would happily forget about Apple's very
existence.

* Domain experts in fact who would need to implement loads of
software to help them get their work done but can't. And since there's
no budget for external developers, nothing get's ever done about this.

Sincerely,

http://www.codebykevin.com/phynchronicity-running.png

http://www.codebykevin.com/quickwho-main.png

Given that, we're likely "stuck" with more or less what we have now, so
let's make the best of it.

On the Tkinter front, I just want to reiterate two important points that
are not nearly as well known as they should be.

First, it is possible and in fact easy to do decent looking GUI's in
Tkinter, with the caveat that you do in fact have to do things very
slightly differently than you would have 15 years ago. Shocking, I know.

Second, there does exist at least one fairly good source of
documentation for new users wishing to do exactly this (according to
many, many comments I have received), though that documentation is
admittedly buried in a sea of out-of-date information that is still all
too easy to find.

Please see http://www.tkdocs.com and in particular the tutorial there.

And regarding popularity, I see very much potential.
I have been working for two high-tech companies and I have never
met anyone else using Python there.
Focus is not classical databases, but data acquisition and processing.
Many are still using VB, some are even using HT/HP-BASIC.
Quite a lot moved to Labview, some are using Matlab or thinking
about moving to it.
The ones who actually see the point the advantages of a general
purpose language moved to C#.
(Nobody is using Java in this context as it obviously would not make
any sense.)

Anyway, I don't see how people could be persuaded to use a
console-only environment, which - realistically - Python is at the
moment for most people.

 From what I see, Python is recognized as a language for scripting
and maybe for web servers, but not as a general purpose language to
implement GUI software.

(To make it clear: I have been using Python as a general purpose
  language for many years.)

Regards,

I would prefer people to invest the same time into a Python based
solution.
But then we're back to the initial point: As long as there's no GUI
builder for Python, most people will stick to Excel / VBA / VB.

Regards,

For getting an impression about Qt Quick, have a look at
http://qt.nokia.com/qtquick/
(The slide show 1,2,3,...)

Regards,

 * Outdated tuts are contributing to the slow adoption of Python3000
 * Outdated tuts are contributing the animosity towards Tkinter.
 * Poorly written tuts are doing even more damage.

I have pointed this out before with very little feedback from our
community members. So you know what i did... about two years ago i
start a quest to rid the WWW of old and outdated tutorials. I send out
email after email; begging; pleading, and yes even brown-nosing!...
and you know how many reposes i got? Three! Yes three! And one of the
three told me to eef-off.

The other two chaps not only updated their tutorials, they even sent
me a nice Thank you letter. Oh. And the one who told me to eff-off, he
re-read my email and decided he took it out of context and then he
updated his tut also.

You refer to "non-programmers" and then point out that they would be
lost trying to add code. That's a natural consequence of not being a
programmer, and of all languages to help someone bridge that gap and
start coding, I would say Python is, if not the absolute best,
certainly up there somewhere. Just as you wouldn't expect a music
authoring program to let someone publish score without knowing how to
compose music, you can't expect a GUI tool to relieve you of the need
to write code.

WYSIWYG UI designers suffer badly from a need to guess _why_ the human
did what s/he did. Build your UI manually, and there's no guesswork -
you explicitly _tell_ the computer what to do and why.

--
Cheers.

I've used Visual Basic. My first salaried work was on VB. Making it
easy to throw together a simple GUI doesn't mean a thing when you have
a large project to write - your business logic and UI design work will
massively dwarf the effort of actually throwing widgets into a
hierarchy. So the only time it's going to be an issue is with trivial
programs; which means there isn't much to be saved. Just make your
trivial things run in a console, and then either use a GUI builder
(several have been mentioned) or hand-write your UI code.

Actually, there's a third option these days. Give it no console and no
GUI, make it respond to HTTP connections, and use a web browser as
your UI. :)

        object mainwindow=GTK2.Window(GTK2.WindowToplevel);
        mainwindow->set_title("Timing")->set_default_size(400,300)->signal_connect( "destroy",window_destroy);
        GTK2.HbuttonBox btns=GTK2.HbuttonBox()->set_layout(GTK2.BUTTONBOX_SPREAD);
        foreach (labels,string lbl)
                btns->add(buttons[lbl]=button(lbl,mode_change));
        mainwindow->add(GTK2.Vbox(0,0)

->add(GTK2.TextView(buffer=GTK2.TextBuffer())->set_size_request(0,0))
                ->pack_start(btns,0,0,0))->show_all();

If you're a complete non-programmer, then of course that's an opaque
block of text. But to a programmer, it ought to be fairly readable -
it says what it does. I'm confident that anyone who's built a GUI
should be able to figure out what that's going to create, even if
you've never used GTK before. (And yes, it's not Python. Sorry. I
don't have a Python example handy.)

Modern UI toolkits are generally not that difficult to use. Add just a
few convenience functions (you'll see a call to a "button" function in
the above code - it creates a GTK2.Button, sets it up, and returns
it), and make a nice, well-commented configuration file that just
happens to be executed as Python, and you've made it pretty possible
for a non-programmer to knock together a GUI. They'll have learned to
write code without, perhaps, even realizing it.

* syntax highlighting
* sensible auto-indenting
* as little reliance on the mouse as possible
* emacs key bindings :)

This article makes me feel more positive about my inability to feel
comfortable in an IDE.  Thanks for the link!

That's the starting point of this thread: for Python we could not
identify such a GUI editor.

No matter how cool it may seem to create simple GUIs manually or to
write business letters using LaTeX: just try to persuade people to move
from Word to LaTeX for business letters...

Regards,

Chris Angelico wrote (in two posts):
 > There was a time when that was a highly advertisable feature - "build
 > XYZ applications without writing a single line of code!". I've seen it
 > in database front-end builders as well as GUI tools, same thing. But
 > those sorts of tools tend not to be what experts want to use. You end
 > up having to un-learn the "easy way" before you learn the "hard way"
 > that lets you do everything.
This time is not over.
Especially when you look at data acquisition and control applications
where tools like Labview are widely used.
Personally, I would not want to use such tools as I find it quite
complicated to implement any logic with a graphical editor.
But when you want to sell an alternative to such tools, then you
should not offer a tool which makes it almost impossible for a
typical engineer to create a simple GUI.

 > You refer to "non-programmers" and then point out that they would be
 > lost trying to add code. That's a natural consequence of not being a
 > programmer,
Sure, but with "non-programmers" I'm referring to typical engineers
who can implement some basic programs for measurement, control or
data processing.

 >  and of all languages to help someone bridge that gap and
 > start coding, I would say Python is, if not the absolute best,
 > certainly up there somewhere. Just as you wouldn't expect a music
100% agreed. It's the only programming language that I can recommend
to casual or even non-programmers, but only as long as he/she's not
interested in GUI programming.

 > authoring program to let someone publish score without knowing how to
 > compose music, you can't expect a GUI tool to relieve you of the need
 > to write code.
The audience of GUI editors is not the artist / professional...

 > WYSIWYG UI designers suffer badly from a need to guess _why_ the human
 > did what s/he did. Build your UI manually, and there's no guesswork -
 > you explicitly _tell_ the computer what to do and why.
True for non-trivial applications. I don't have many windows and dialogs
that could have been created using a GUI editor in my main wxPython
based application.
But even then: I've learned wxPython from looking at the code that
wxDesigner created. Of course, that was in 1999/2000 when no books on
such matters were available.

 > There's an assumption in most of the Windows world that everything
 > needs a GUI. For a simple data acquisition program, I wouldn't use one
 > - I'd have it run in a console. That's something that any programmer
 > should be able to create without studying complex manuals; all you
 > need to know is the basics of I/O and possibly argument parsing.
Yes, usually I'm using a console as most measurement programs are quite
straighforward and linear.
But I don't see a way to convince people to go back to the console.
They will always want to implement a basic GUI for one or the other
program and then they will end up frustrated...
(Or I have to implement the GUI for them, which is not an option.)

 > I've used Visual Basic. My first salaried work was on VB. Making it
 > easy to throw together a simple GUI doesn't mean a thing when you have
 > a large project to write - your business logic and UI design work will
I would never consider or recommend to write anything significant using
a GUI builder. Also, I would never recommend anyone to use VB at all.
But given the lack of alternatives, it still has a significant market
share.
(The fact that anyone can hack together a program in VB has the side-
effect that most programs are not very good...)

 > massively dwarf the effort of actually throwing widgets into a
 > hierarchy. So the only time it's going to be an issue is with trivial
 > programs; which means there isn't much to be saved. Just make your
 > trivial things run in a console, and then either use a GUI builder
 > (several have been mentioned) or hand-write your UI code.
Right, we're talking about non-trivial programs with almost trivial
user interfaces. But I don't see a Python GUI builder which a casual
user could use to add a GUI to the code.
(To be exact: it's easy to create a GUI with one or the other builder,
but non-trivial to connect it to the backend.)

 > Actually, there's a third option these days. Give it no console and no
 > GUI, make it respond to HTTP connections, and use a web browser as
 > your UI. :)
I don't think that this is easier for the casual user as multiple
languages and environments are involved.
But on the other hand there are some (mainly commercial) organizations
who believe that HTML5, CSS and Javascript are the future for GUI
programming.
Personally, I prefer Python with console, wx or Qt for local
applications and Python/HTTP/HTML/Javascript for multi-user
database applications.

Regards,

 > Second, there does exist at least one fairly good source of
 > documentation for new users wishing to do exactly this (according to
 > many, many comments I have received), though that documentation is
 > admittedly buried in a sea of out-of-date information that is still all
 > too easy to find.
 >
 > Please see http://www.tkdocs.com and in particular the tutorial there.
The point of this thread is that Python is not attractive to casual
users who want to implement some GUI programs.
I don't see how that would change without an easy-to-use GUI builder,
no matter how good the documentation is.
Of course, it's possible to split up the documentation into many small
building blocks which the user could copy & paste together.
But then we have a poor-man's GUI builder. I doubt that it would
attract new users.

(For more straightforward tasks like hardware control / data
  acquisition I made good experiences with a Wiki-based approach
  of providing snippets. But *simple* GUIs are mainly visual and
  there should be a way to create them visually without consulting
  much documentation.)

Regards,

I think this is the wave of the furture for deploying simple programs
to many users. It is almost 100% cross platform (can be used on
desktop, smartphone, tablet, windows, linux, mac etc) and is very easy
to do, even for casual "non-programmers" who do a little programming
(such as many engineers).

I think efforts to make a better, and more definitive, "GUI builder"
for Python should focus on makigng an easy to use "IDE" for creating
these kinds of Python-HTMl-Javascript front ends for applications.

*That* would really help Python's popularity to take off and expode.

VB(A) is unusable for everyday office automation because it doesn't
offer an interactive commandline interpreter.

Besides, both only run^H^H^Hlimp on a pathologic non-operating system
that's just as unsuitable for any productive work. But that's
off-topic, too.

And unfortunately the origin of this problem seems to be the
open-source development model itself: Since developers of open source
development tools (GUI frameworks, GUI builders etc.) usually
implement these for their own use, and since these people are typically
software developers by profession who come from a C++-dominated
background, they don't see the necessity and they don't have any
motivation to implement anything that would help all those potential
Python users out there who just can't devote the time and effort
required to get over that pretty huge step in the learning curve of
those frameworks and tools.

Please note that this is not meant as criticism to open-source
developers, but as a hint that there might be a business opportunity
for someone here to develop and sell something for money. ;-)

Sincerely,

But there's afaik still no interactive GUI builder out there for any of
these frameworks, nor a higher level framework that requires less glue
code between bare naked "event handling" and the domain-specific code.
"Event handling" - that term already raises my hair because it stinks
like bulkloads of clumsy, error-prone diligence work that has nothing
to do with the problem I need to get solved.

Sincerely,

I have done nearly exactly this* - but it was only possible thanks to
LyX.

Sincerely,

Wolfgang

What is needed for domain specialists are frameworks and related tools
such as GUI builders that allow them to write exclusively the
domain-specific code (this is where a domain specialist will always be
better than any software developer), layout the GUI as ergonomically
convenient (same) and then have the framework do all the rest.

No tool/framework can cover 100%, no doubt. My point is that there are
currently no frameworks/tools available for Python that cover the
90/95/98% of use cases where they would help a L-O-T.

Sincerely,