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.
