[Tutor] When to use classes

[Jim]

On 08/20/2017 03:12 AM, Alan Gauld via Tutor wrote:
> 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.
> 

In one sense Hypercard is still alive. Check out Livecode at livecode.com

Regards,  Jim