Everything good about Python except GUI IDE?

[Chris Angelico]

On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
>
>>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
>>> less well known GUI IDEs which I did not come across. Thanks.
>>
>> Sounds like the advantage lies with Python here...
>>
>> Don't make a UI by dragging and dropping that many widgets.
>
>
> And later, in another post:
>
>> the best way to build a cross-platform GUI is code, not drag-and-drop.
>
>
> I think that's out-and-out wrong, and harmful to the developer community. I
> think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> processing: you can format documents as nicely as you like, but you have to
> use a separate mode to see it.
>
> Drag-and-drop GUI builders have the same advantages over code as Python has
> over languages with distinct compile/execute steps: rapid development,
> prototyping, exploration and discovery. Of course, any decent modern
> builder won't limit you to literally drag-and-drop, but will offer
> functionality like duplicating elements, aligning them, magnetic guides,
> etc.

Alright, but how do you go about doing, with a drag-and-drop builder,
all those things we're used to with code - composing new named actions
out of primitives, observing the changes to a program through source
control, unit testing (maybe), and code review? The only way I know of
to build a "function" in a DnD builder is to create a composite widget
(eg "horizontal box containing label and entry field"), which is
extremely useful, but limited - it's like saying that the only way to
reuse code is single-inheritance. How would you create a higher-order
operation in a DnD builder? How would you write something that does
some sort of sweep over a set of widgets and does the same thing to
them?

All these sorts of things are possible... but we're getting right back
to code again. People have tried to create graphical code builders for
decades; they've never been sufficient. Code - textual commands to
manipulate a system - is still the most powerful and flexible way to
do things.

By the way, you'll notice that I said "dragging and dropping **that
many** widgets" (emphasis added). GUI builders can be great for simple
jobs, and a really awesome one can work well for more complex jobs
too, but the asymptotic complexity of using drag and drop is worse
than that of code.

> GUI elements are by definition graphical in nature, and like other graphical
> elements, manipulation by hand is superior to command-based manipulation.
> Graphical interfaces for manipulating graphics have won the UI war so
> effectively that some people have forgotten there ever was a war. Can you
> imagine using Photoshop without drag and drop?

No, I can't. But I also can't imagine git-managing Photoshop files,
and IMO, that is a serious loss. Would you accept a programming
language that forced all files to be edited by a single person?
Collaboration is pretty important these days. How would you review
edits to approve/deny them if you can't see what was edited?

> And yet programming those graphical interfaces is an exception. There, with
> very few exceptions, we still *require* a command interface. Not just a
> command interface, but an *off-line* command interface, where you batch up
> all your commands then run them at once, as if we were Neanderthals living
> in a cave.

I think there's room to improve the textual interface without throwing
it away. Certainly several of the Python toolkits are quite primitive
in their style; everything has to be executed imperatively, with no
room to build a layout declaratively. But thanks to the flexibility of
code, this is a very real possibility. Nobody can usefully *extend*
the VB UI builder except its owner; anybody can write a function that
simplifies one small part of code generation.

Python's existing APIs definitely need some work, but I've used some
other systems that were closer. Imagine something like this:

win = gtk.Window(
    title="Demo Window",
    transient_for=mainwindow,
    child=gtk.labelled(["User name", "Email", "Password", "Confirm",
gtk.okbtn()]),
)

For more complicated work, build up new primitives and keep right on
going. Do it right, and you should be able to have live editing with a
preview window, and *maybe* even some kind of manipulation tool,
although I'm not sure how best to do that.

This doesn't have to be a dichotomy.

ChrisA