«

(Sorry for posting without references to the previous messages, but it
seems that many messages don't get through to the nntp server that I'm
using.)

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,

Dietmar

On Jun 10, 12:37*pm, Dietmar Schwertberger <maill...@schwertberger.de>
wrote:
> Personally, I prefer Python with console, wx or Qt for local
> applications and Python/HTTP/HTML/Javascript for multi-user
> database applications.
>
> Regards,
>
> Dietmar

+1

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.

Ron Stephens

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

Replying to myself, to add this note: I just read the link
likehacker.com/learn-to-code/
about Google's "Blockly" a drag and drop tool for building apps that
outputs Python or Javascript code (among others) and it might be
usable along these lines...I'm sure serious programmers would not use
it but maybe engineers looking to make web front ends
for data acquisition or data base apps might use it...

Danger: Flame ahead!
> 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.

The idea of so-called "web applications" is a cerebral flatulance
emanating from braindead morons (typically the pointy-haired type),
sorry.

From the perspective of the domain specialist who needs to get some work
done and who needs to get it done efficiently they are simply
unusable. The "functionality" that such "web interfaces" provide is
ridiculously poor, they are clumsy to use and even worse
hourglass-display systems than the junk that MS or SAP sell. Besides the
fact that they require obscene amounts of runtime ressources.
Besides... Sorry, this subject isn't worth wasting my brain bandwidth
on it.

I have started to use computers with GEM on Atari ST, MacOS 6.0.7 and
DOS 3.3, and if all those "web mailers" or "Google apps" had been the
only applications available back then I would have never started to use
computers at all.

In short: "web applications" are in no way a solution to the mentioned
problem, but they make this problem worse by piling up other problems
on top of it.

End of flame.

Sincerely,

Wolfgang

Am 13.06.2012 18:30, schrieb :
> about Google's "Blockly" a drag and drop tool for building apps that
> outputs Python or Javascript code (among others) and it might be
> usable along these lines...I'm sure serious programmers would not use
> it but maybe engineers looking to make web front ends
> for data acquisition or data base apps might use it...
Actually, there are mouse based tools for engineers, but they are
more focused on data flow. For the low level they need to fall back to
something similar to Blockly. That's the reason why I don't want to
use them. Still they have a significant market share. With Python not
having an easy-to-use GUI builder, I don't see how to get people
to move from such tools to Python. For the data acquisition and
processing itself I could well imagine them to see the potential,
but when it comes to implementation of a complete program...
(Most people consider a software without GUI as incomplete.)


Regards,

Dietmar

Dietmar quotes:

> With Python not having an easy-to-use GUI builder,

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

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

In response to all of these and the general heavily repeated mantra
here that "there is no easy to use GUI builder for Python", OK, tell
you what: describe what the "GUI that an engineer would want to make"
should look like--give all widgets and their bindings--and I will see
about making a video that shows how easy this is to do with a GUI
builder, even with the user having a very rudimentary (or perhaps
zero) knowledge of wxPython. And it will be timed. Let's test your
idea for real. (I should note, I don't know what an "input mask"
refers to above).