GPS Tue Jun 18, 2002: I've had some ideas floating around in my head, and thought I might share them to maybe start a discussion. I've had the idea of building a GUI toolkit using widgets that consist of a standalone executables for a while. When I first started out I oftened wanted the ability to use something like button.exe to create a button in my shell scripts. Now I've come to realize many benefits of this simple idea. With standalone executables that handle messages through a two-way pipe a cross-platform programming-language-independant toolkit could be built. Sockets could also be used instead of two-way pipes for web-service widgets.
For example:
#! /bin/tclsh8.3
create button .b -text "Hello World" -command {puts Hello}
manage pack .bIn that simple example tclsh calls the create proc, which calls the button executable, creates a two-way pipe, and sends the arguments -text "Hello World", which is received via its argv. The button responds to events that only affect itself. If it receives an Expose it redraws itself. If the manager process wants to configure the button it sends a configure message to the pipe associated with .b If the button fails due to a bad message or an error in the C code only that button fails. This means that a users can then use the rest of the application to save their work, send a bug report, and hopefully restart. If the button is pressed the -command would be evaluated by the scripting language, via a message received from the .b instance, which is then evaluated by the scripting language.
One problem with many languages (especially C) is that things often affect each other in ways you don't want. Having executable modules that compose widgets allows the code to be unique for each widget. Ideally you might share some code, but most of it would be application specific. A binding for a scripting language wouldn't require any C code. Programmers could have a single toolkit that works with their favourite language.
Threads would become in many cases obsolete, because blocking of one module wouldn't block others due to the separate event loops.
This way of thinking encourages adding executables to extend the language. Code reuse would be very easy from this level. Users could use several programming languages as well.
Tk would probably be easier than most toolkits to convert to work this way.
The Downside
The memory usage of having a thousand different widget executables running would quickly eat up memory.
The OS may not deal well with thousands of processes operating in this manner.
What do you think? Am I out of my mind? ;^)