Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 12:04:52 PM UTC+5:30, Steven D'Aprano 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.
> 
> 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?
> 
> 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.
> 
> An effective and modern GUI builder UI should be programmable without
> requiring programming. About thirty years ago Apple came up with the ideal
> mix of graphical and programmatic development for its Hypercard product.
> You built applications by dragging and dropping widgets on the screen, or
> by copying and pasting them from a library of pre-made widgets. 
> 
> (By 2016 standards the UI of Hypercard would seem a bit old fashioned and
> primitive -- black and white, bitmapped graphics, no magnetic guides
> or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder
> wouldn't have those limitations.)
> 
> Hypercard let you create a place widgets by hand using the mouse, or by
> running a one-line command in the "Message Box" (a simple command
> interpreter), and for complex tasks, or by writing a script and executing
> it. You didn't have to script the *entire* application, just as much or as
> little as needed scripting.
> 
> Python would be especially well-suited to this, being an interpreter. Why
> should I have to batch up all the GUI elements and run them all at once to
> see what my application looks like? Why can't I add elements interactively?
> 
> I've made a number of attempts to get into GUI development in Python, and
> every time I flounder at the lousy state of the art in GUI builder tools.
> Yes, the widget set is fantastic. But putting the GUIs together is
> primitive beyond words.
> 
> Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it
> lives on in the guise of LiveCode:
> 
> http://livecode.com/
> 
> 
> If only I could get the Linux installer to actually, you know, *work*.
> 
> 
> -- 
> Steven


A sensible view
And more helpful than pretending that neanderthal == civilized

Chris: Is it easier to work out the best-lookkng colors with a color picker or 
with hacking through a million #rrggbb combos?