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? -- https://mail.python.org/mailman/listinfo/python-list
