On Sat, Aug 19, 2017 at 11:34:10AM -0600, Mats Wichmann wrote: > It makes some sense though; computational code just goes ahead and > computes. In the graphical UI world, interesting things happen when an > event you can't exactly plan for takes place. From the point of view of > a computer program, waiting for somebody to move a mouse and click it is > a slow, infrequent, and unpredictable event, so you set up callbacks > which are invoked when one of those events happens, and in the meantime > you can either do other productive work, or do nothing at all (let other > programs on the computer do work). I'm finding it hard to imagine > tkinter without them...
I've never got into GUI programming because I was so thoroughly spoiled by one of the first programming languages that I learned that everything 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. 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. The language was Hypertalk, the scripting language of Apple's Hypercard application in the mid to late eighties. Hypercard was seen by Apple as a kind of Rolodex application, with a "card" metaphor, and programmable objects (text fields and buttons) that you can copy and paste between files. Apple invisiged that developers would program the objects and users would simply copy and paste them, and to their utter surprise they were overwhelmed by the number of end users who started programming their own objects. 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. But I digress... the Hypercard model was that of a stack of cards. Each 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. You used the integrated GUI designer to lay out your shared objects in the background, and customised objects on the card. 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. To program your "stack", you create message handlers that respond to events. E.g.: on mouseUp # sent when the mouse button is released over the object on idle # sent when nothing else is happening on opencard # sent when we've just navigated to another card on closecard # sent when we've just navigated away from the current card If this looks a tiny bit like Javascript, that's because Javascript borrowed the idea and language of handlers from Hypertalk and Hypercard. 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, so if the field itself couldn't handle it, it would next go to the card "George", then the card's background, then the current stack, and finally Hypercard itself, which would complain that it didn't know anything about "print" events. (Events it did know about, like idle or mouseDown or closeCard, would just be silently ignored.) -- Steve _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor