On 20/08/17 02:47, Steven D'Aprano wrote: > since then feels like going back to the Dark Ages. Having to care about > low-level details like creating buttons, installing callbacks and so > forth just feels wrong.
To be fair most GUI frameworks come with a GUI builder that remove the manual coding for things like that. Even Tk (upon which Tkinter is based) has a couple of them, but for some reason the Python implementation has never had one that worked well. The bigger industrial grade GUI builders for Java(Swing/JFX), .NET(VS), and even Gnome/Qt on Linux are all very easy to use to build quite complex GUIs. > There is an alternative to callback based GUI frameworks, and that is an > message-passing, event-driven language. The framework handles the events > for you, and fires off messages to objects. If the object doesn't handle > the event, it is sent to the next object in the message-passing > heirarchy. Again, that's how pretty much every modern GUI works. The callback bit is just a manual exposure of what the GUI builder does under the covers. Most casual GUI programmers never create or specify a call back they just click the widget in the GUI builder and are taken to the pre-written empty function body. > The language was Hypertalk, the scripting language of Apple's Hypercard > application in the mid to late eighties. There was(is?) a project on Sourcefoirge to build a Python equivalent to Hypercard. I played with it a long time ago but it wasn't really ready for serious use in my view. I don't know if its still running or how far it has progressed. And there are several GUI builders for Python beyond Tk although I haven't had much success with any of them. I suspect because Python is so high level as a language that the effort they save is much less than when using Java or C++. > By today's standards it is woefully primitive: only a single window, of > a fixed size, black and white graphics, and only a fixed set of > pre-defined GUI widgets and no way to create your own. But it is > remarkable just how much power there is in just two widgets, text fields > and buttons, especially since the buttons can be specialised into push > buttons, radio buttons and checkbox buttons. Borland tried a similar trick on Windows with a tool called TurboVision(Or ObjectVision? my memory fails me) which was an entirely graphical tool with even the code being built using graphical code blocks. Scratch does the same thing today for beginning programmers. But all of these tools run into the same issues - eventually you will need to create something more complex which the tool can't handle. > stack (Hypercard document) consisted of at least one shared background > used by at least one card. Cards inherited their look, state and > behaviour from their background, but could override any part of that. I think that was Hypercard's USP. The idea of an inherited look 'n feel was quite powerful and I'm surprised that nobody else has picked that up, at least as an option, for a new window/screen/frame. > The Hypercard application managed the GUI event loop for you. It tracked > the mouse and the keyboard, and other events, and each time it noticed > an event, it sent a message to the appropriate object (a widget, card, > background or stack). That object could either handle the message, or > ignore it. If it ignored the message, it passed on to the next object in > the heirachy. Again that's pretty much how every GUI framework operates. Its just that Tkinter etc make it explicit by forcing you to pass the parent object and event handler(s) into the widget at creation time. A GUI builder does that for you. > If this looks a tiny bit like Javascript, that's because Javascript > borrowed the idea and language of handlers from Hypertalk and > Hypercard. Most OO GUI frameworks borrowed these ideas from Hypercard (and indeed the Object Pascal MacApp framework that Hypercard was built on). The MaCapp framework was a huge step up from the older procedural frameworks such as X Windows and MS Windows etc that had gone before. > To call a handler in another object, you sent your own message, and the > Hypercard application would manage the details: > > send "print" to field "Address" of card "George" > > That message would be sent via the same message path as any other event, Again that's pretty much how any GUI framework works today (although they also allow direct message passing between code objects too). They all have some kind of event posting service. Hypercard's legacy is alive and well in the GUI frameworks we all use today. The tools used to make that accessible are not so simple however, and in the end, the ability to create powerful, full featured GUIs has trumped the easy to use, but ultimately limited, scope of Hypercard. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
