what gui designer is everyone using

[Mark R Rivet]

I want a gui designer that writes the gui code for me. I don't want to
write gui code. what is the gui designer that is most popular?
I tried boa-constructor, and it works, but I am concerned about how
dated it seems to be with no updates in over six years.

[becky_lewis]

I'm afraid that in my experience, doing things by hand has always
ended up being quicker and simpler than relying on a GUI designer when
it comes to building python GUI apps. That said, I've not tried any
for the past few years so there may be a killer app out there that
I've not tried :) But even then, it's likely that you'll still have to
get your hands dirty in the code at some point.

Also, it would help a little if you'd state which toolkit you were
using (I'm assuming wxPython since you mention boa-constructor).

[park...@gmail.com]

I've used XRCed with wxpython in the past. XRCed is bundled with the wxPython installation. It was very easy to layout the GUI objects and setup the generic event bindings.

Recently I've been playing around with using PyQt and QtDesigner because I keep seeing it highly recommened. The capabilities and process seem very similar to using XRCed to me.

These are simply GUI designers not IDE's. The basic process for using both is:
* Layout the GUI objects, define generic event bindings (wx) or signals/slots (Qt).
* Save the GUI layout XML.
* Auto-generate a generic Python module that defines the GUI object based on the XML.
* Import the and inherit from the generic Python GUI. Override the GUI class and methods as needed.
* Write a script or a main function that instantiates the GUI and starts the event loop.

I'm biased toward wxPython and XRCed mostly because I've had more experience with it and the documentation seems easier to follow.

[rds...@mac.com]

No one size fits all, and many Pythonistas prefer to write GUI code by
hand anyway. However, I like PythonCard. Try it, you might like it.

[Den]

On Jun 5, 7:10 am, Mark R Rivet <markrri...@aol.com> wrote:

I use wxFormBuilder. It seems to be most up-to-date and is as easy to
use as any others. It also covers AUI GUIs. It produces the class,
but you have to do a little bit of programming to actually see the
GUI.

I used wx-glade for a while. It was easy to use, and produced ready-
to-run GUIs. But it's old and not well kept up. There's some new
work being done on it but it seems to be mostly housekeeping work -
how to best package it, etc.

Den

[Colin Higwell]

I'm using wxGlade,and am very happy with it.

[Dave Cook]

I've been using wxFormBuilder since last summer. It's reasonably easy
to use, and there are regular releases by the developers.

I have a coworker who's had a lot of success using Boa for everything.
It would be a shame if Boa is allowed to bitrot in to complete
unuseability.

Dave Cook

[Miki Tebeka]

> what is the gui designer that is most popular?

IIRC Qt designer can output Python code.

[Kevin Walzer]

None. I write GUI code by hand (Tkinter).

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[CM]

Boa Constructor. Very happy with it. Mostly use it for the IDE these
days, as it already served to help build the GUI.

[Alister]

I am using glade at present but I am still in the process of learning

[Wolfgang Keller]

Sorry to "hijack" your thread, but since this is a very related
question...

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.

TIA,

Sincerely,

Wolfgang

[CM]

I'm curious about your point but I don't really understand it. Could
you try again without using any scare-quoted words? Maybe given an
example of creating a small text editor application with a GUI builder/
IDE in this Pythonic way you are hoping for.

[Dietmar Schwertberger]

Am 08.06.2012 17:11, schrieb CM:
> I'm curious about your point but I don't really understand it. Could
> you try again without using any scare-quoted words? Maybe given an
> example of creating a small text editor application with a GUI builder/
> IDE in this Pythonic way you are hoping for.

Before anyone now writes "Good GUIs are coded by hand":
I agree, but for many purposes only simple GUIs are required
and it should be possible to create these without studying manuals
(on toolkit and GUI editor).
A typical simple GUI would e.g. be for a measurement / data aquisition
program, where you just need some buttons and fields.


I think that something in the style of Visual BASIC (version 6) is required
for either wxPython or PyQt/PySide (or both).
In the Visual BASIC editor you can e.g. add a GUI element
and directly go to the code editor to fill methods (e.g. an OnClick
method).
If you have not used VB before, you should just try it. You can create
GUIs within a few minutes even if you haven't used it before.
(Sure, the fact that anyone can use it has the side effect that most
of these GUIs are not good...)

Also:
Such an editor should support simple manual layouts without enforcing
the use of sizers (wx) or layout managers (Qt).
These add an additional level of complexity which is not required
for simple GUIs.


Background:
I'm using Python in a corporate environment but I'm more or less
the only one using it. I could propagate Python for wider use as it
is the best available language for things like hardware control and
data acquisition, but the lack of an easy-to-use GUI editor is
the blocking point. I can teach anyone how to create a program for data
acquisition, but I don't see how more than a few could create a GUI
without an easy-to-use tool.
There's still a lot of VB6 code around as there's no replacement and
this gap could well be filled by Python.


Regards,

Dietmar

[CM]

> I think that something in the style of Visual BASIC (version 6) is required
> for either wxPython or PyQt/PySide (or both).
> In the Visual BASIC editor you can e.g. add a GUI element
> and directly go to the code editor to fill methods (e.g. an OnClick
> method).

You can do this for wxPython with Boa Constructor easily. You can
bind an event handler for a wx.EVT_BUTTON to, e.g., "Button1" with Boa
and it will add this code for you to the bottom of your code:

def OnButton1Button(self,evt):
evt.Skip()

And you can than go in the code editor to that function and change the
code to do whatever you want.

> If you have not used VB before, you should just try it. You can create
> GUIs within a few minutes even if you haven't used it before.

Same with Boa.

> Such an editor should support simple manual layouts without enforcing
> the use of sizers (wx) or layout managers (Qt).
> These add an additional level of complexity which is not required
> for simple GUIs.

Same with Boa, though it also has good support for sizers which
generally should be required for anything other than the simplest
GUIs.

> data acquisition, but the lack of an easy-to-use GUI editor is
> the blocking point. I can teach anyone how to create a program for data
> acquisition, but I don't see how more than a few could create a GUI
> without an easy-to-use tool.
> There's still a lot of VB6 code around as there's no replacement and
> this gap could well be filled by Python.

In addition to Boa, I get the sense that the other tools mentioned
here are also good, so is this "blocking point" real?

[Dietmar Schwertberger]

Am 09.06.2012 17:34, schrieb CM:
> You can do this for wxPython with Boa Constructor easily. You can
> bind an event handler for a wx.EVT_BUTTON to, e.g., "Button1" with Boa
> and it will add this code for you to the bottom of your code:
>
> def OnButton1Button(self,evt):
> evt.Skip()
>
> And you can than go in the code editor to that function and change the
> code to do whatever you want.

Having to go there is already more work than I would expect.
I would expect to go there e.g. by a double-click.

This is just a minor point, but many minor points sum up...

If you take maybe 10 people each with some BASIC or Python knowledge,
I would bet that you can teach most of them how to write a
simple GUI program in VB within five minutes, but you'll probably fail
with Boa. (And even then you would have to re-teach them in a few
months when they try to write their next program.)

>> If you have not used VB before, you should just try it. You can create
>> GUIs within a few minutes even if you haven't used it before.
>
> Same with Boa.

Not for me when I tried Boa.
The logic / usage concept behind is not exactly straightforward.
At the time, Boa was suggested to be the perfect choice for previous
Delphi users. Maybe my problem was that I did never use Delphi.
(Only Turbo Pascal in the pre-gui era...)

>> Such an editor should support simple manual layouts without enforcing
>> the use of sizers (wx) or layout managers (Qt).
>> These add an additional level of complexity which is not required
>> for simple GUIs.
>
> Same with Boa, though it also has good support for sizers which
> generally should be required for anything other than the simplest
> GUIs.

Yes, at least Boa left the choice to the user.
Some of the other tools even insist on sizers at places where they are
not even required with a sizer-based layout.
(E.g. with wx you usually place a notebook directly on a frame while
some tools insist on using a sizer first.)

> In addition to Boa, I get the sense that the other tools mentioned
> here are also good, so is this "blocking point" real?

I've tried several:
wxDesigner, Boa, QtCreator, wxFormBuilder, wxGlade,
None of these were such that I could propagate it as GUI development
tool for non-programmers / casual users.
Sure, some are good for designing the GUI, but at the point where
the user code is to be added, most people would be lost.
(I think that was the point that Wolfgang did not like and did describe
as un-pythonic.)


Also, another requirement for this purpose would be that the tool
is under active development. This would e.g. rule out Boa.

I would not care whether the tool is freeware or commercial.
Being freeware would make handling easier, though (e.g. deployment to
all measurement PCs by just running it from a file share is
easier than local installations and license handling).


Regards,

Dietmar

[rusi]

On Jun 9, 10:07 pm, Dietmar Schwertberger <n...@schwertberger.de>
wrote:

> > And you can than go in the code editor to that function and change the
> > code to do whatever you want.
>
> Having to go there is already more work than I would expect.
> I would expect to go there e.g. by a double-click.
>
> This is just a minor point, but many minor points sum up...
>
> If you take maybe 10 people each with some BASIC or Python knowledge,
> I would bet that you can teach most of them how to write a
> simple GUI program in VB within five minutes, but you'll probably fail
> with Boa. (And even then you would have to re-teach them in a few
> months when they try to write their next program.)

This is worth a read in this context: http://osteele.com/archives/2004/11/ides

[Dietmar Schwertberger]

Am 10.06.2012 08:16, schrieb rusi:
> This is worth a read in this context: http://osteele.com/archives/2004/11/ides

So which language would you suggest to use next? ;-)

I've read the article. It presents some nice ideas, but probably the
author has not used Python before.
Otherwise he would have noticed that the overall productivity does not
only depend on language and IDE/editor, but on the complete environment
which in the case of Python includes the ability to use the interpreter
interactively. For many tasks that's a major productivity boost.
But that's a point that many people don't see because their current
language like C# or Java does not have an interpreter and when they
just look at the syntax, the find "there's not enough improvement to
switch".

Also, I'm not sure whether the author counts the libraries as language
or tool feature. In my opinion the environment and the libraries should
be listed on their own in such an article. Libraries are developed
after the language, but usually they are ahead of the other tools/IDEs.


The author lists many IDE features that I personally don't find too
important (the refactoring capabilities of a simple text editor are
fine for me...). But following the link to Laszlo made the reason quite
clear because his IDE background is from Eclipse not from Python.


Btw.: I've been using Python for 16 or 17 years now. Only 3 years ago I
did the switch from Editor to IDE (Wing IDE) and this has brought a
*significant* boost of productivity (especially the good debugger allows
you to code in a different way as you can use the interactive
interpreter at any point in your program).



But back to my original point, this time in the context of the article:
If you want to 'sell' a programming language for corporate use, you
absolutely need the tools. And this includes an easy-to-use GUI editor
which does not only allow to create the GUI, but also to fill it with
code.
Most corporate users are casual users, not full time programmers.



Regards,

Dietmar

[Kevin Walzer]

On 6/8/12 8:27 AM, Wolfgang Keller wrote:
> 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?

If you're developing on the Mac, PyObjC allows you to use Interface
Builder for developing Python apps.

However, there are those of us who are deeply uncomfortable with IB and
related tools, such as RealBasic and LiveCode/Runtime Revolution. These
tools make code organization very hard by reducing the amount of code
written to the point of the UI working by "magic," and/or by breaking up
your code into little snippets that you can only view by clicking on the
widget in the UI tool.

A related issue is that using a tool such as this makes you heavily
dependent on that particular tool, and subject to its developers'
priorities, release schedule, and bugs. The pace of Xcode
development--with Apple making frequent changes to project formats in a
backwards-incompatible way--is an example of this.

One reason I prefer to code UI's by hand is because a) in Tkinter it's
very easy to do, and b) it allows me to have a much better mental model
of my code and my app's functionality--I can put everything into as many
.py files as I need to, and can edit my code with any text editor.

I think these issues are a reason that the slick "drag-and-drop" UI
builders tend to be developed by commercial software shops to support
their language and/or IDE, but find little traction among open-source
developers and languages.

--Kevin

[Rick Johnson]

On Jun 7, 4:18 pm, Kevin Walzer <k...@codebykevin.com> wrote:
> On 6/5/12 10:10 AM, Mark R Rivet wrote:
>
> > I want a gui designer that writes the gui code for me. I don't want to
> > write gui code. what is the gui designer that is most popular?

> None. I write GUI code by hand (Tkinter).

I second that notion. Writing GUI code by hand is the only way.

[Rick Johnson]

On Jun 8, 7:27 am, Wolfgang Keller <felip...@gmx.net> wrote:

> 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 strongly agree with this statement also.

[Rick Johnson]

On Jun 9, 8:25 am, Dietmar Schwertberger <n...@schwertberger.de>
wrote:

> Before anyone now writes "Good GUIs are coded by hand":
> I agree, but for many purposes only simple GUIs are required
> and it should be possible to create these without studying manuals
> (on toolkit and GUI editor).

It is possible. Try Tkinter for the "get-you-from-a-to-b" solution,
or, wxPython if you like fog lamps, heated seats, and navigation
systems.

> A typical simple GUI would e.g. be for a measurement / data aquisition
> program, where you just need some buttons and fields.

Buttons and feilds are just a few short lines of code. Look. You guys
don't need a visual GUI builder. What you need to do is stop being
lazy and spend a few hours studing the basics of Tkinter and wxPyhon
(or whatever else suits your needs). IMO, every single python
programmer who needs GUI interfaces should know the basics of AT LEAST
Tkinter without even looking at the docs. I mean, how difficult is:

import Tkinter as tk
from Tkconstants import *
root = tk.Tk()
root.title('Noob')
for x in range(10):
f = tk.Frame(root)
f.pack(fill=X, expand=YES)
l = tk.Label(f, text="Field_"+str(x))
l.pack(side=LEFT, anchor=W)
e = tk.Entry(f)
e.pack(side=LEFT, fill=X, expand=YES)
root.mainloop()
#
# Or even better. Use grid!
#
root = tk.Tk()
root.title('Amatuer')
root.columnconfigure(1, weight=1)
for x in range(10):
l = tk.Label(root, text="Field_"+str(x))
l.grid(row=x, column=0, sticky=W)
e = tk.Entry(root)
e.grid(row=x, column=1, sticky=W+E)
root.mainloop()
#
# Or become a pro and create reusable objects!
#
class LE(tk.Frame):
def __init__(self, master, **kw):
tk.Frame.__init__(self, master)
self.l = tk.Label(self, **kw)
self.l.pack(side=LEFT)
self.e = tk.Entry(self)
self.e.pack(side=LEFT, fill=X, expand=YES)
root = tk.Tk()
root.title('Pro')
for x in range(10):
le = LE(root, text="Field_"+str(x))
le.pack(fill=X, expand=YES)
root.mainloop()

>
> I think that something in the style of Visual BASIC (version 6) is required
> for either wxPython or PyQt/PySide (or both).
> In the Visual BASIC editor you can e.g. add a GUI element
> and directly go to the code editor to fill methods (e.g. an OnClick
> method).

With Tkinter you add a GUI element IN THE CODE and then you are
ALREADY in the code editor! What an amazing concept! No juggling
editors and windows. No need to mentally switch from one language to
another. Can you imagine how productive you could be?

> If you have not used VB before, you should just try it. You can create
> GUIs within a few minutes even if you haven't used it before.

Allow me to qualify that very naive generalization: "ANYBODY and point
and click, very few can actually write code".

> (Sure, the fact that anyone can use it has the side effect that most
> of these GUIs are not good...)

Well i see that you agree. Look. This is fact. GUI's require you to
write code. You cannot get around this fact. Sure, you can create some
templates. But in the end, you will have to write in order to link the
templates together.

I say. If your GUI kit gives you the feeling that you are writing too
much boilerplate, well, then, it's time to wrap up some re-usable
functionality on your own. I have done this myself with Tkinter AND Wx.
( although much more so with Tkinter being that is a poorly designed
GUI)

> Also:
> Such an editor should support simple manual layouts without enforcing
> the use of sizers (wx) or layout managers (Qt).
> These add an additional level of complexity which is not required
> for simple GUIs.

See above code for example of *gasps* simple layouts in REAL code!

> Background:
> I'm using Python in a corporate environment but I'm more or less
> the only one using it. I could propagate Python for wider use as it
> is the best available language for things like hardware control and
> data acquisition, but the lack of an easy-to-use GUI editor is
> the blocking point.

BS!

> I can teach anyone how to create a program for data
> acquisition, but I don't see how more than a few could create a GUI
> without an easy-to-use tool.

Like Tkinter?

> There's still a lot of VB6 code around as there's no replacement and
> this gap could well be filled by Python.

Visual Basic sucks. I spend more time re-focusing my mental energy
than actually getting work done. There is no replacement for pure raw
code. You visualize GUI's in you mind, and fingers bring that vision
to life through properly written API's.

Never invent a new problem for a solution that does not exist.

[Dietmar Schwertberger]

Am 10.06.2012 21:36, schrieb Rick Johnson:
> It is possible. Try Tkinter for the "get-you-from-a-to-b" solution,
> or, wxPython if you like fog lamps, heated seats, and navigation
> systems.

I prefer wx or Qt. The look and feel is one reason.

But the fact that Tkinter is still the standard GUI toolkit tells a lot
about the situation...

> Buttons and feilds are just a few short lines of code. Look. You guys
> don't need a visual GUI builder. What you need to do is stop being
> lazy and spend a few hours studing the basics of Tkinter and wxPyhon
> (or whatever else suits your needs). IMO, every single python
> programmer who needs GUI interfaces should know the basics of AT LEAST
> Tkinter without even looking at the docs. I mean, how difficult is:

[snipped code examples]
Sure, I know how to code GUIs. But the learning curve is too steep
for new users wanting to implement simple GUIs.

> With Tkinter you add a GUI element IN THE CODE and then you are
> ALREADY in the code editor! What an amazing concept! No juggling
> editors and windows. No need to mentally switch from one language to
> another. Can you imagine how productive you could be?

I thought about preparing some templates for typcial applications, but
I abandonded this as I don't think that it would work out well.

>> If you have not used VB before, you should just try it. You can create
>> GUIs within a few minutes even if you haven't used it before.
>
> Allow me to qualify that very naive generalization: "ANYBODY and point
> and click, very few can actually write code".

Right. I won't comment on the quality of the most VB code.
But there are many applications where the quality of the code is not
the main objective. It just needs to work e.g. to set up the instrument
and read back data. The know-how and value is not the GUI code, but
in the instrument setup and data evaluation.

> I say. If your GUI kit gives you the feeling that you are writing too
> much boilerplate, well, then, it's time to wrap up some re-usable
> functionality on your own. I have done this myself with Tkinter AND Wx.
> ( although much more so with Tkinter being that is a poorly designed
> GUI)

Did the same for wx twelve years ago as I did not like e.g. the event
handling. Most of the time I'm still using my own wrappers.
Still, once or twice a year I'm writing some small applications where
I would use a GUI builder if it was available instead of copying old
code as template.

>> I can teach anyone how to create a program for data
>> acquisition, but I don't see how more than a few could create a GUI
>> without an easy-to-use tool.
>
> Like Tkinter?

Don't like Tkinter, even though the alternatives are not too Pythonic
either.

> Visual Basic sucks. I spend more time re-focusing my mental energy
> than actually getting work done. There is no replacement for pure raw
> code. You visualize GUI's in you mind, and fingers bring that vision
> to life through properly written API's.
>
> Never invent a new problem for a solution that does not exist.

Sure, VB language sucks, but still I do not see any other tool that
would cover the RAD aspect of the VB 6 environment. I would love to
see Python for this, even though this would have negative side
effects (e.g. attracting stupid people like PHP seems to).


Regards,

Dietmar

[Rick Johnson]

On Jun 10, 2:36 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:

> #
> # Or become a pro and create reusable objects!
> #
> class LE(tk.Frame):
>     def __init__(self, master, **kw):
>         tk.Frame.__init__(self, master)
>         self.l = tk.Label(self, **kw)
>         self.l.pack(side=LEFT)
>         self.e = tk.Entry(self)
>         self.e.pack(side=LEFT, fill=X, expand=YES)
> root = tk.Tk()
> root.title('Pro')
> for x in range(10):
>     le = LE(root, text="Field_"+str(x))
>     le.pack(fill=X, expand=YES)
> root.mainloop()

PS: The keywords argument should have been passed to the entry widget
and NOT the label. Yes, occasionally, even pros make subtle mistakes.

[rusi]

On Jun 10, 4:52 pm, Dietmar Schwertberger <n...@schwertberger.de>
wrote:

> Am 10.06.2012 08:16, schrieb rusi:> This is worth a read in this context:http://osteele.com/archives/2004/11/ides
>

>

> I've read the article. It presents some nice ideas, but probably the
> author has not used Python before.
> Otherwise he would have noticed that the overall productivity does not
> only depend on language and IDE/editor, but on the complete environment
> which in the case of Python includes the ability to use the interpreter
> interactively. For many tasks that's a major productivity boost.
> But that's a point that many people don't see because their current
> language like C# or Java does not have an interpreter and when they
> just look at the syntax, the find "there's not enough improvement to
> switch".

Full agreement here

>
> Also, I'm not sure whether the author counts the libraries as language
> or tool feature. In my opinion the environment and the libraries should
> be listed on their own in such an article. Libraries are developed
> after the language, but usually they are ahead of the other tools/IDEs.

That was my main point and the reason for referring to that article.
If I may rephrase your points in OSteele's terminology:

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

Then why is it up-there among our most popular languages? Because of
the 'batteries included.'
And not having a good gui-builder is a battery (cell?) that is
lacking.

[Wolfgang Keller]

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

[Wolfgang Keller]

> > 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?
>
> If you're developing on the Mac, PyObjC allows you to use Interface
> Builder for developing Python apps.

I know that. And no, I haven't used Interface Builder yet myself, just
because I would need those GUIs also to run elsewhere than on my
private Mac.

> However, there are those of us who are deeply uncomfortable with IB
> and related tools, such as RealBasic and LiveCode/Runtime Revolution.

I haven't used any of these either, just because I don't like those
languages. Their syntax is ugly, static type declarations are imho
perfectly redundant for interpreted languages and besides they don't
offer me an interactive interpreter, which is an absolute must-have for
my day-to-day use of Python - "office automation", ad-hoc "information
logistics" etc. (errr, sorry for those quotation marks again... ;-).

> These tools make code organization very hard by reducing the amount
> of code written to the point of the UI working by "magic,"

Any modern GUI framework has quite a lot of "magic" going on
"behind the curtains" without that the user needs to know or understand
how it works. And this is the way it _should_ be. As long as it is well
documented how to use that "magic".

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/or by breaking up your code into little snippets that you can
> only view by clicking on the widget in the UI tool.

I remember reading about RAD IDEs/frameworks out there that managed to
integrate/seperate their generated code with/from user-written code
quite well. And which could even use external revision control systems
etc.. Back in the good old days of software diversity, before MS/Java
took over the whole world...

> A related issue is that using a tool such as this makes you heavily
> dependent on that particular tool, and subject to its developers'
> priorities, release schedule, and bugs.

This is true with _any_ language, library, framework or software. Heck,
it's even true with hardware! If this was such a show-stopper, we would
still write computer programs like this: 0100011100101010101....
Well, certainly not me, in that case.

> The pace of Xcode development--with Apple making frequent changes to
> project formats in a backwards-incompatible way--is an example of
> this.

Wxwidgets/python has a reputation for frequent incompatible API changes,
too...

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.

> One reason I prefer to code UI's by hand is because a) in Tkinter
> it's very easy to do,

Tkinter is imho honestly the very best "argument" if you want to make
potential new users turn their backs away from Python for good. Just
show them one GUI implemented with it and, hey, wait, where are you
running to...

> I think these issues are a reason that the slick "drag-and-drop" UI
> builders tend to be developed by commercial software shops to support
> their language and/or IDE, but find little traction among open-source
> developers and languages.

The point is that loads of potential "developers"(*) simply don't
ever get to use Python due to the very lack of such tools (and
corresponding frameworks).

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

Wolfgang

[Kevin Walzer]

On 6/11/12 8:01 AM, Wolfgang Keller wrote:
> Tkinter is imho honestly the very best "argument" if you want to make
> potential new users turn their backs away from Python for good. Just
> show them one GUI implemented with it and, hey, wait, where are you
> running to...

Yes, Tkinter GUI's are very ugly.

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

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

[Mark Roseman]

Dietmar Schwertberger <ne...@schwertberger.de> wrote:
> 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]

Wolfgang Keller <feli...@gmx.net> writes:

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

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

[Rick Johnson]

On Jun 10, 11:05 pm, rusi <rustompm...@gmail.com> wrote:

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

On Jun 11, 9:09 am, Mark Roseman <m...@markroseman.com> wrote:

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

[Chris Angelico]

On Sun, Jun 10, 2012 at 3:07 AM, Dietmar Schwertberger
<ne...@schwertberger.de> wrote:
> None of these were such that I could propagate it as GUI development
> tool for non-programmers / casual users.
> Sure, some are good for designing the GUI, but at the point where
> the user code is to be added, most people would be lost.

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.

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.

ChrisA

[Mark Lawrence]

On 11/06/2012 13:47, Kevin Walzer wrote:
> Yes, Tkinter GUI's are very ugly.
>
> http://www.codebykevin.com/phynchronicity-running.png
>
> http://www.codebykevin.com/quickwho-main.png
>

At last we're getting to the crux of the matter. Provided that the GUI
is pretty who cares about picking appropriate algorithms for the code,
or a sensible database design or whatever. And heaven forbid that
anyone suggest using a command line even if this was the better solution
for the problem that the user wants solved.

--
Cheers.

Mark Lawrence.

[Chris Angelico]

On Sat, Jun 9, 2012 at 11:25 PM, Dietmar Schwertberger
<ne...@schwertberger.de> wrote:
> ... for many purposes only simple GUIs are required

> and it should be possible to create these without studying manuals
> (on toolkit and GUI editor).
> A typical simple GUI would e.g. be for a measurement / data aquisition
> program, where you just need some buttons and fields.
>
>

> If you have not used VB before, you should just try it. You can create
> GUIs within a few minutes even if you haven't used it before.
> (Sure, the fact that anyone can use it has the side effect that most
>  of these GUIs are not good...)

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.

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

ChrisA

[Chris Angelico]

On Mon, Jun 11, 2012 at 5:37 AM, Dietmar Schwertberger
<mail...@schwertberger.de> wrote:
> 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.
>
> [chomp lots of other examples - go read 'em in the original post :) ]

Either these people know how to write code, or they don't. If they do,
then building a simple GUI shouldn't be beyond them; if they don't
know that much code, then anything more than trivial _will_ be beyond
them. Here's the window building code from something I just knocked
together, with all comments stripped out:


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.

ChrisA

[Arnaud Delobelle]

On 10 June 2012 07:16, rusi <rusto...@gmail.com> wrote:

> This is worth a read in this context: http://osteele.com/archives/2004/11/ides

Interesting! I definitely fall nicely at one extreme of this
dichotomy. Every time I've tried to use an IDE, it's made me feel
inadequate and I've quickly retreated to my comfort zone (emacs +
xterm). I felt inadequate because I felt like the IDE was hindering
me rather than helping me. All I ask from the program that I use to
write code is:

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

--
Arnaud

[Dietmar Schwertberger]

Am 11.06.2012 01:15, schrieb Chris Angelico:
> 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 -

Well, I can read the code.
But still I would not be able (or interested) to write C++/GTK code.
With my rusty C++ knowledge and a simple GUI builder, I might be able
to create the GUI, though.
Whether I could then connect the events to actions is a different
question and depends on the GUI builder. If it does not support this,
then I would just not write the software.

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

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

All the discussion about casual users being able to implement GUIs by
manually coding it is somehow based on the assumption that suitable
examples for any purpose are available.
So to me the above example seems to be the proof that suitable examples
are not available easily.

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

Right, they are not too difficult to use for full-time programmers
or for people who want to invest a lot of time (as hobbyist).
But there are many people who just need to get things done and who
don't want to invest too many time on a simple GUI.

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,

Dietmar

[Dietmar Schwertberger]

(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

[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

[CM]

On Jun 11, 6:55 pm, Dietmar Schwertberger <n...@schwertberger.de>
wrote:

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

[rds...@mac.com]

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

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

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
> > make potential new users turn their backs away from Python for
> > good. Just show them one GUI implemented with it and, hey, wait,
> > where are you running 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]

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

Good example.

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

Sincerely,

Wolfgang

*I moved not from Wugh, but from other software to LyX/LaTeX for all my
document processing.

[rds...@mac.com]

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

[Wolfgang Keller]

> > None of these were such that I could propagate it as GUI development
> > tool for non-programmers / casual users.
> > Sure, some are good for designing the GUI, but at the point where
> > the user code is to be added, most people would be lost.
>
> 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

[Wolfgang Keller]

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

Thanks for that hideously appalling example of a ridiculously low-level
mess.

If you're an occasional Python scripting dilettant, this looks like a
heap of syntax garbage of exactly that kind that has made me avoid all
C-derived languages at university (I'm a mechanical engineer) and that
makes me avoid GUI programming with Python so far.

If a domain specialist needs an application with a GUI, (s)he
typically only wants to have to tell the framework three things:

1. What the domain model looks like (classes, attributes) and what it
does in terms of behaviour (domain logic, methods). In my use-cases this
would be typically done with SQLalchemy.

2. What the GUI shows of the domain model and how it does it - define
menus with entries, layout forms/dialog boxes with fields etc. This
should be done without having to permanently look up all the specific
details of the API of the GUI framework.

3. What attribute/method of the domain model a GUI element is
"connected to" (sorry for the quotes again). This should be possible in
an interactive way, so that you can test whether GUI and code work
together as required while defining the connections.

Anything else should be done by the framework without the necessity to
write a single line of code for the "straight forward" use cases:
- creating, retrieving, updating, deleting instances of domain model
classes
- setting values of attributes instances of domain model classes
- calling methods of instances of domain model classes

Sincerely,

Wolfgang

[Wolfgang Keller]

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

[CM]

On Jun 14, 2:25 pm, Wolfgang Keller <felip...@gmx.net> wrote:
>
> 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]

On Tue, 12 Jun 2012 00:55:38 +0200, Dietmar Schwertberger wrote:

> 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:
> On Tue, 12 Jun 2012 00:55:38 +0200, Dietmar Schwertberger wrote:
>> 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.

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]

On 2012-06-14, Dietmar Schwertberger <ne...@schwertberger.de> wrote:

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

--
Grant Edwards grant.b.edwards Yow! My nose feels like a
at bad Ronald Reagan movie ...
gmail.com

[Dietmar Schwertberger]

Am 14.06.2012 23:29, schrieb Grant Edwards:
> On 2012-06-14, Dietmar Schwertberger<ne...@schwertberger.de> wrote:
>> 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

[Dietmar Schwertberger]

Am 13.06.2012 14:49, schrieb Wolfgang Keller:
>> 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...
>
> Good example.
>
> I have done nearly exactly this* - but it was only possible thanks to
> LyX.

> *I moved not from Wugh, but from other software to LyX/LaTeX for all my
> document processing.

But of course, you were only doing so because you had LyX available,
which is the equivalent of an easy-to-use GUI builder.
So maybe I should be more precise: just try to persuade people to move
from Word to *pure* LaTeX for business letters...

Regards,

Dietmar

[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

[Dietmar Schwertberger]

Am 13.06.2012 18:30, schrieb rds...@mac.com:
> 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

[CM]

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

[Wolfgang Keller]

On Thu, 14 Jun 2012 12:59:23 -0700 (PDT)
CM <cmpy...@gmail.com> wrote:

> On Jun 14, 2:25 pm, Wolfgang Keller <felip...@gmx.net> wrote:
> >
> > 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.

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

[Chris Angelico]

On Fri, Jun 15, 2012 at 7:47 AM, Dietmar Schwertberger
<ne...@schwertberger.de> wrote:
> 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.

I want to promote Linux as a replacement for Windows. But I do not see
that Linux needs to be able to run Internet Explorer in order to do
that. Maybe when people move to a replacement, they need to learn a
slightly different way of doing things; and in this case, I would
strongly recommend the "build your UI in code" method.

ChrisA

[Chris Fox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So you use wget on linux and read the html code in a terminal? That
would seem to be a reasonable analogy.

(a different) Chris


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/dnQUACgkQ/UgLKfoJxI6FzgCg0zRwrwQJwwCMatEEMhYyMvPN
eGsAn111DGx2lgo7Y6vMJr0EcD+zGDHD
=GjZF
-----END PGP SIGNATURE-----

[Chris Angelico]

On Sun, Jun 17, 2012 at 7:01 PM, Chris Fox <ch...@robotninja.net> wrote:
> On 17/06/2012 03:42, Chris Angelico wrote:
>> I want to promote Linux as a replacement for Windows. But I do not
>> see that Linux needs to be able to run Internet Explorer in order
>> to do that. Maybe when people move to a replacement, they need to
>> learn a slightly different way of doing things; and in this case, I
>> would strongly recommend the "build your UI in code" method.
>>
>> ChrisA
>
> So you use wget on linux and read the html code in a terminal? That
> would seem to be a reasonable analogy.
>
> (a different) Chris

Well, I have been known to use wget, a simple HTML-to-text converter,
and watch... made for a fairly simple monitor for something that had a
browser-based status display. But no, I don't go to that extent. That
would be analogous to abolishing GUI frameworks altogether and
expecting everyone to use and write command-line tools. We're talking
here about building your own program, and whether or not you can use a
GUI to build a GUI. Most other interfaces aren't built using
themselves; look at web-based web site builders, they almost
universally suck (and those that don't suck are special-purpose
things, like MediaWiki, that just happen to be able to be used to
build a web site). WYSIWYG HTML editors have become rather better now
than they were (say) 10-15 years ago, but I still believe in
hand-writing HTML and CSS (or using straight-forward tools) for best
results.

ChrisA
(keeping the A(ngelico) on the name to distinguish from all the other
geeky Chrises, of whom there are a good few on this list)

[Wolfgang Keller]

> >> 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...
> >
> > Good example.
> >
> > I have done nearly exactly this* - but it was only possible thanks
> > to LyX.
>
> > *I moved not from Wugh, but from other software to LyX/LaTeX for
> > all my document processing.
> But of course, you were only doing so because you had LyX available,
> which is the equivalent of an easy-to-use GUI builder.

No need to argue here. This was exactly my point. :-)

> So maybe I should be more precise: just try to persuade people to move
> from Word to *pure* LaTeX for business letters...

Nearly impossible. And this was exactly my point. Again, no need to
argue here. :-)

The success of LyX (and TeXmacs and BaKoMaTeX and Scientific Word...)
proves imho that the LaTeX community had missed to offer a
"syntax-hiding"-GUI with LaTeX some 20 years ago.

And the lack of success of Python so far to replace, in your
application case, Labview, or, in my application case, all those
proprietary 4GL IDEs/frameworks/GUI builders (just check the success
that Realbasic has) proves imho that the Python community has totally
missed to address the vast crowd of potential users who are domain
experts in other domains than software development.

Sincerely,

Wolfgang

[Albert van der Horst]

In article <jr4pcc$fl3$1...@dont-email.me>,
Kevin Walzer <k...@codebykevin.com> wrote:

>On 6/11/12 8:01 AM, Wolfgang Keller wrote:
>> Tkinter is imho honestly the very best "argument" if you want to make
>> potential new users turn their backs away from Python for good. Just
>> show them one GUI implemented with it and, hey, wait, where are you
>> running to...
>
>Yes, Tkinter GUI's are very ugly.
>
>http://www.codebykevin.com/phynchronicity-running.png

I looked it up.

What you find ugly, I find unconfusing and clear.
If I compare it to usual on the web, it is the difference
between a waterfall side and an airport where the personell
is on strike. (Oh the noise, the noise is unbearable!).
I have not, nor intend to write gui things in Python,
I just give an impression.

[ I want my gui's to be functional, not beautiful. ]


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

>--
>Kevin Walzer

Groetjes Albert



--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Terry Reedy]

On 6/22/2012 11:53 AM, Albert van der Horst wrote:
> In article <jr4pcc$fl3$1...@dont-email.me>,
> Kevin Walzer <k...@codebykevin.com> wrote:
>> On 6/11/12 8:01 AM, Wolfgang Keller wrote:
>>> Tkinter is imho honestly the very best "argument" if you want to make
>>> potential new users turn their backs away from Python for good. Just
>>> show them one GUI implemented with it and, hey, wait, where are you
>>> running to...
>>
>> Yes, Tkinter GUI's are very ugly.
>> http://www.codebykevin.com/phynchronicity-running.png
>
> I looked it up.
>
> What you find ugly, I find unconfusing and clear.

Kevin Walzer is a tk expert. Perhaps you missing the sarcastic irony in
what he intended to be a refutation of Wolfgang Keller's comment ;-).

--
Terry Jan Reedy

[88888 Dihedral]

Albert van der Horst於 2012年6月22日星期五UTC+8下午11時53分01秒寫道：

I suggest you can use Python with QT to build some GUI and C++ with QT
for similar jobs of the commercial versions in order to test the tools.


Nowadays the GUI part is so cheap to build with so manny code generation tools, it is not the same as in the years before 2000.

[Brian]

On 6/19/2012 6:07 AM, Wolfgang Keller wrote:
> And the lack of success of Python so far to replace, in your
> application case, Labview, or, in my application case, all those
> proprietary 4GL IDEs/frameworks/GUI builders (just check the success
> that Realbasic has) proves imho that the Python community has totally
> missed to address the vast crowd of potential users who are domain
> experts in other domains than software development.
>
> Sincerely,
>
> Wolfgang

I have been compelled to occasionally use LV by my current
employer. I do not know if LabView is the disease or is a
symptom. It is an evil parasite and has resulted in a disaster
at my place of employment and another that I am aware.

As for 'designers' and 'builders', the discussion threads on
Python gui builders is legion. In the end, the consensus is
always to learn one and write the gui. Regardless of the
multitude of clever gui libraries, event code in this language
seems a bit contrived, and is attractive only to professional
programmers. But the community must know that the language is
used by hundreds of thousands of scientists and engineers that
have a job to do, and do not have the time and have no interest
in learning the frameworks du jour.

This is why I see test and manufacturing engineers refuse to
give up VB6 where Windows is required. I disagree with those
that say Python can be used as a VB6 replacement. And the touted
'interactive' feature of Python does nothing for gui coding.

It would not be difficult to convince me to commit homicide for
a Delphi-like Python gui machine that runs on a Linux box. I
have played with many - Boa, WxDes, Glade, Tk, Dabo, QtDesigner,
Card, etc.

Am currently experimenting with IronPython, because the factory
boss says no more Linux boxes on his production lines. And the
person that said Python is best tool for data acq/hw control
needs to get out more. Very dangerous. C first, Python second.
This is why I insist on only C and Python for the engineering
lab, and use one of three proven pre-coded Tk-based GUIs for
production and ATE drivers.

You want to argue with me? First come visit my employer's TJ
factory and watch the boys test 600kVA transformers or 250kVA
inverters. 150,000 A of fault current.

Brian

[CM]

> It would not be difficult to convince me to commit homicide for
> a Delphi-like Python gui machine that runs on a Linux box. I
> have played with many - Boa, WxDes, Glade, Tk, Dabo, QtDesigner,
> Card, etc.

Not sure whether you tried it enough on Linux, but Boa (which was
intended to be kind of Delphi for Python) *almost* runs OK on Linux.
There are a few workarounds to some of the problems and I have a list
of the remaining issues. But yes, it's not ideal to use on Linux yet
(I have done sort of OK with developing with it on Windows and then
using it on Linux to tidy up cross platform incompatibilities in
wxPython apps between Win and Linux).

[rusi]

On Jun 10, 3:36 pm, Arnaud Delobelle <arno...@gmail.com> wrote:
> On 10 June 2012 07:16, rusi <rustompm...@gmail.com> wrote:
>
> > This is worth a read in this context:http://osteele.com/archives/2004/11/ides
>
> Interesting! I definitely fall nicely at one extreme of this
> dichotomy.  Every time I've tried to use an IDE, it's made me feel
> inadequate and I've quickly retreated to my comfort zone (emacs +
> xterm).

Here is a more recent discussion in the same vein:
http://henrikwarne.com/2012/06/17/programmer-productivity-emacs-versus-intellij-idea/

Reddited here:
http://www.reddit.com/r/programming/comments/vqb9l/programmer_productivity_emacs_versus_intellij_idea/

> I felt inadequate because I felt like the IDE was hindering
> me rather than helping me.  All I ask from the program that I use to
> write code is:
>
> * syntax highlighting
> * sensible auto-indenting
> * as little reliance on the mouse as possible
> * emacs key bindings :)

To some extent the new article just confirms the old Osteele one: viz.
Programmers stuck with java had better spend their time using the most
powerful tools to compensate for their inadequate language.

However it also indicates the opposite:
Benefits of sophisticated refactoring support are almost certainly
underestimated by users of vi/emacs.

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

T