Pythonic cross-platform GUI desingers à la

[Mark Roseman]

But the fact that Tkinter is still the standard GUI toolkit tells a lot
about the situation...
...
Sure, I know how to code GUIs. But the learning curve is too steep
for new users wanting to implement simple GUIs.

As is obvious to everybody, the massive interest in web-based
applications in recent years has certainly not helped advance the state
of the art in desktop GUI's, nor enlarged the developer population
actively engaged in maintaining and improving desktop GUI toolkits.

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.

Mark

 

[Anssi Saari]

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.

What about Qt Quick? I have used it very little, but it does allow
dynamic modification of the GUI elements so that the application
changes on the fly. I don't know how pythonic it is, since the GUI is
described in QML, which combines CSS and javascript.

 

[Dietmar Schwertberger]

Am 11.06.2012 06:05, schrieb rusi:

If python is really a "language maven's" language then it does not do
very well:
- its not as object-oriented as Ruby (or other arcana like Eiffel)
- its not as functional as Haskell
- its not as integrable as Lua
- its not as close-to-bare-metal as C
- etc

Depends on the definition. Maybe, that Python is not a perfect
language from an academic point of view, but it's a good choice
for anyone looking for a pragmatic programming language.

Then why is it up-there among our most popular languages? Because of
the 'batteries included.'

It's not only the batteries, but also the language itself.
As someone wrote a long time ago "Python fits my brain".

And not having a good gui-builder is a battery (cell?) that is
lacking.

It's a cell that would make it much easier to compete with other
languages/environments.
These environments need not necessarily be classical programming
language, but could also be Labview, Matlab etc.

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,

Dietmar

 

[Dietmar Schwertberger]

Am 11.06.2012 14:01, schrieb Wolfgang Keller:

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

Well, typically or at least very often sooner or later something
gets done about this as someone finds out that all could be solved
using MS Excel and some macros / VBA programming.

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,

Dietmar

 

[Dietmar Schwertberger]

Am 11.06.2012 16:14, schrieb Anssi Saari:

What about Qt Quick? I have used it very little, but it does allow
dynamic modification of the GUI elements so that the application
changes on the fly. I don't know how pythonic it is, since the GUI is
described in QML, which combines CSS and javascript.

I have been following the Qt development as I have been using PySide
for some small projects on the Maemo platform.
Qt Quick / QML seems to enable the implementation of so-called "modern"
UIs.
It's more for people who think that HTML5/CSS/Javascript is the future
for UIs.
Well, maybe they are right for certain advanced requirements.
But for the beginner I don't see how it would help as it's even more
difficult to link the GUI to the backend code and also I don't see
how having to deal with multiple environments would make things easier.
I think that for beginners some basic controls are fine enough and
there's no need to care for fancy effects for the most non-consumer
applications.


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


Regards,

Dietmar

 

[Dietmar Schwertberger]

Am 11.06.2012 16:09, schrieb Mark Roseman:

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.

Yes, but when I have the choice between Tkinter, Qt and wx, I still
would go for wx or Qt (or stick to wx which I chose 12 years ago).
I don't see the point of chosing Tkinter over the other toolkits.

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,

Dietmar

 

[Rick Johnson]

If python is really a "language maven's" language then it does not do
very well:
- its not as object-oriented as Ruby (or other arcana like Eiffel)

if it were object-oreiented as Ruby, then why not use Ruby?

- its not as functional as Haskell

if it were as functional as Haskell, then why not use Haskell?

- its not as integrable as Lua

if it were as integrable as Lua, then why not use Lua?

- its not as close-to-bare-metal as C

if it were as asinine as C, then why not use C?

- etc exactly!

Then why is it up-there among our most popular languages? Because of
the 'batteries included.'

No. It's up there because it does not FORCE you to program in a single
paradigm. Look. I love OOP. It works well for so many problems -- but
not for ALL problems! I like the freedom i have when using Python. I
don't get that feeling anywhere else.

And not having a good gui-builder is a battery (cell?) that is
lacking.

Nonsense. I'm not saying we should NEVER have a visual gui builder,
no, but i am saying that we don't need one to be a great language.

 

[Rick Johnson]

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.

Well you Mark you have really hit it this time.

* 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 see. If "I", or me rather, the despised and hated "rantingrick"
can inspire three people to contribute positively to this community,
well, just imagine what you or *gasps* GvR could do! Is any heavy
weight willing to step forward and be heard? What say you? The silence
is deafening.

 

[CM]

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.

Then good thing there *are* GUI builder/IDEs for Python, one of which
was good enough for me to take me from essentially zero modern
programming experience to a sizable (> ~15k LOC) application.

 

[Wolfgang Keller]

* Domain experts in fact who would need to implement loads of

Well, typically or at least very often sooner or later something
gets done about this as someone finds out that all could be solved
using MS Excel and some macros / VBA programming.

MS Excel is unusable for any kind of serious work, due its serious
design deficiences. But that's off-topic here.

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.

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.

There are quite a few GUI builders out there for Python. The point is
that they are not very "pythonic" imho, i.e. they don't really show
what the advantage of Python is for GUIs over those other languages. And
imho these GUI builders, just like the frameworks that they generate
code for are not very suitable for someone who's not a software
developer by profession. Because they require way too much "glue code".

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,

Wolfgang

 

[Wolfgang Keller]

Tkinter is imho honestly the very best "argument" if you want to

Yes, Tkinter GUI's are very ugly.

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

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

OK, so after what - one and a half decades? - Tkinter now finally has
caught up with wxPython and PyQt (concerning the look). Which can be
used in an as interactive way from the commandline interpreter as
Tkinter. Argument against Tkinter withdrawn from my side.

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,

Wolfgang

 

[Wolfgang Keller]

None of these were such that I could propagate it as GUI development

There was a time when that was a highly advertisable feature - "build
XYZ applications without writing a single line of code!".

That's the typical nonsense cheaptalk of sales promotion advertising,
directed at clueless managers.

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.

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.

If by "experts" you mean "domain specialists", you're wrong. If you
mean full-time software developers, I don't care for what they want,
because they already have what they want. And where they don't have it
already, they can do it themselves.

You end up having to un-learn the "easy way" before you learn the
"hard way" that lets you do everything.

I see no technical reason why a GUI builder would prevent anyone to
add customised code by hand.

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,

Wolfgang

 

[CM]

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.

Above this you also mentioned a disdain for the need for "glue code",
which in the context of your post seemed to be binding to event
handlers.
So is there a possible way for a GUI builder to *automatically* bind
widgets
to the appropriate functions in your domain-specific code? It's hard
to
see how this would be generally possible, even with an AI (maybe a
mind-reading AI would work).

Or maybe I'm misunderstanding something.

 

[Colin Higwell]

As long as there's no GUI
builder for Python, most people will stick to Excel / VBA / VB.

No GUI builder for Python? There are plenty.

I use wxGlade with wxPython and it works beautifully. It writes the code
for the GUI elements, and I put in the event handlers, database access
code and so on.

 

[Dietmar Schwertberger]

Am 14.06.2012 22:06, schrieb Colin Higwell:

No GUI builder for Python? There are plenty.

Yes, sorry. I posted that too late in the night.
The point was that there's no easy-to-use GUI builder which would
allow the casual user to create a GUI.

I use wxGlade with wxPython and it works beautifully. It writes the code
for the GUI elements, and I put in the event handlers, database access
code and so on.

Yes, from the ones I've tested, wxGlade came closest to what I was
looking for.
But still, it's far away from being the tool that is required IMHO.
(An it does not seem to be in active development.)

Also, with wxGlade you are forced to use sizers - even at positions
where they are not useful at all.
For simple GUIs that adds a level of complexity which is counter
productive.
(From the GUI editors that I tried, Qt Creator/Designer was the only
one where I agree that it handles sizers/layout containers well.)


When I compare e.g. wxGlade to VB6, whether a casual programmer can use
it to create a GUI, then still VB6 wins.
VB is crap, but at least it allows to create GUIs by using a GUI and
will help you getting started in writing GUI applications. It will
take only a few minutes to teach someone how to get started.
On the other hand, I need to know wx very well to be able to create
a GUI using wxGlade as otherwise I will never find where to add
e.g. the handlers.
But when I know wx very well, then there's no point in using wxGlade.



Regards,

Dietmar

 

[Grant Edwards]

Yes, sorry. I posted that too late in the night. The point was that
there's no easy-to-use GUI builder which would allow the casual user
to create a GUI.

I'm not sure I'm in favor of casual users creating GUIs.

Have you ever tried to _use_ a program built by a casual user?

[OK, I'm half joking.]

If casual users want a GUI builder they can use, then let 'em write
one...

 

[Dietmar Schwertberger]

Am 14.06.2012 23:29, schrieb Grant Edwards:

Yes, sorry. I posted that too late in the night. The point was that
there's no easy-to-use GUI builder which would allow the casual user
to create a GUI.

I'm not sure I'm in favor of casual users creating GUIs.

Have you ever tried to _use_ a program built by a casual user?

[OK, I'm half joking.]

I understand your point.
I've used and fixed many such programs.

Plenty of those were by so-called professionals. Usually, those are the
most problematic cases as you don't have the sources available or they
are developed and deployed by a central IT department.

There's a correlation between technical knowledge of creating a GUI
and the quality of the resulting GUI, but the correlation is not too
strong.

The casual programmer that I was refering to, is also among the users
of the software that (s)he is writing and therefore the GUI tends to
be improved over time, which often is not the case with the software
developed by so-called professionals who get paid for the program and
then move on.

The point is, that if you want to promote Python as replacement
for e.g. VB, Labview etc., then an easy-to-use GUI builder is required.
The typical GUI programs will just have an input mask, a button and one
or two output fields.

Regards,

Dietmar

 

[Dennis Lee Bieber]

When I compare e.g. wxGlade to VB6, whether a casual programmer can use
it to create a GUI, then still VB6 wins.
VB is crap, but at least it allows to create GUIs by using a GUI and
will help you getting started in writing GUI applications. It will
take only a few minutes to teach someone how to get started.

Visual Basic was essentially developed as a unified whole (drop a
VB6 "form" module into a pure text editor and look at how much hidden
code was embedded)...

Have you ever seen the crud created by Visual C++? I'd rather create
a GUI using Fujitsu COBOL version 4 (unfortunately, the installer that
came with my Y2K COBOL book(s) doesn't work on WinXP and I no longer
have a Win98 system; wonder if it can run under Win7 using one of the
compatibility modes; I think v4 itself would work -- it is just the
installer doing something odd; v3, OTOH, is a 16-bit application)

 

[Dietmar Schwertberger]

Am 15.06.2012 01:07, schrieb Dennis Lee Bieber:

Visual Basic was essentially developed as a unified whole (drop a

Sure. I prefer modular approaches. I don't see why this should not be
possible (e.g. an IDE like Wing integrates well with other tools and
frameworks; I'm sure it could also integrate with a GUI builder).

VB6 "form" module into a pure text editor and look at how much hidden
code was embedded)...

I did so several times before. It's nothing that you want to create
manually, but you can fix small items there and also, being text based,
it works with revision control systems and can be printed for
documentation purposes.

Have you ever seen the crud created by Visual C++? I'd rather create

No. And I don't have plans to. C/C++ is good as a system-level language
but I don't see the point in using it for implementation of a GUI or
business logic.

a GUI using Fujitsu COBOL version 4 (unfortunately, the installer that
came with my Y2K COBOL book(s) doesn't work on WinXP and I no longer
have a Win98 system; wonder if it can run under Win7 using one of the
compatibility modes; I think v4 itself would work -- it is just the
installer doing something odd; v3, OTOH, is a 16-bit application)

If you have access to a Win98 system, you could try to install there
an move only the installed program to your current PC (including any
DLLs from the system folder).
Well-written software does not need an installer. Just move where you
want to have it and execute (works well with Python; you can e.g.
run a shared installation from the network, even though I would not
recommend this for processes requiring highest reliability).
IMHO under Windows installers and the crappy start menus are a side
effect of the initial decision to separate into File Manager and
Program Manager. Other platforms did things better from a UI and
technical point of view, but not from a commercial one...
(E.g. Acorn's RISC OS where you could even run software from
within zip archives as it had the equivalent of user-space file
systems twenty years ago already.)

Regards,

Dietmar

 

[Wolfgang Keller]

Above this you also mentioned a disdain for the need for "glue code",
which in the context of your post seemed to be binding to event
handlers.

With "glue code" I mean any code other than that which serves to
implement purely domain-specific behaviour.

So is there a possible way for a GUI builder to *automatically* bind
widgets to the appropriate functions in your domain-specific code?
It's hard to see how this would be generally possible, even with an
AI (maybe a mind-reading AI would work).

Or maybe I'm misunderstanding something.

Probably, since there are GUI builders/frameworks available that do
what I described. I have already pointed to some for my specific type
of application (database applications) that don't even need any GUI
definition at all, since the GUI is entirely reflected from the domain
model. Which I would not consider as the most ergonomic way to define
a GUI.

Unfortunately these excellent GUI builders and frameworks all use
languages which imho are not at all suitable for domain specialists who
are not full-time software developers by training.

Sincerely,

Wolfgang