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 parent .
create button .b -text "Hello World" -command {puts Hello}
manage pack .bIn that simple example tclsh calls the create proc, which calls the parent executable which creates the main window and returns an id for it (which is stored automatically). Then tclsh calls the button executable and passes the id of the parent "." 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 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/module 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.
Afterthoughts
After I had this idea I looked to see if anybody had implemented this. I found a widget server that has some similar ideas, but I think it used Motif IIRC, which gets away from my ideals.
What do you think? Am I out of my mind? ;^)
Cool. No :o) ...
Many ways to go here. One exe with Tk in it, fed by a pipe is another way to achieve such things. It would avoid the 1000-process aspect. Yet another idea is to communicate through array data and triggers, Tequila comes to mind.
Please do keep going, George -jcw
-- There seems to be quite a lot of thinking and experimentation in this are at the moment, cf. discussion on the Tcl chat dd. 18 june 2002. Perhaps some coordination is called for? :-) Like formulating a little project ... AM
A project might narrow this down too much (there is a LOT of related thinking left to do!) - perhaps a SIG (Special Interest Group) approach? Is there a page that lists the current Tcl discussion groups? -jcw
ulis: For me, sounds like a Tk server, thru sockets: only one remaining process.
George, if you want to see a product that implements similar concepts (albeit mostly using shell scripts) then download a copy of Sentinel3G from http://www.sentinel3g.com/ (it's free on Linux).
The GUI for this product is a long running incrTcl process that displays the graphical elements on behalf of the shell scripts, communicating via sockets (so the GUI can be run on a separate host, even on Windows). The protocol between the GUI and scripts is based on incrTcl object instantiations and method invocations. The actual product is built using these GUI tools, and has no knowledge of how the information is being displayed - it makes relatively abstract requests like "display this data" or "choose one of these data items".
As I said, a commercial product but free on Linux, and it might give you some encouragement/ideas. - stevel
AK - Regarding a one-process approach serving Tk, Mark Roseman described something similar at the Seventh Annual Tcl/Tk Conference => http://www.usenix.org/events/tcl00/roseman.html . A Java Applet for use in a Browser, and the commands send to it came via sockets from a Tk emulation. I.e. a package looking like Tk, behaving like Tk, but talking to the Applet. He used it in the TeamWave application to be able to use Tk on the server side to generate GUI's and still be able to display them platform-independent, and without the need for the Tcl/Tk Tclet Plugin.
AM I wrote a small example - A small example of a widget serving a program