ewan birney (birney at molbiol.ox.ac.uk) wrote:
:: But, here are some questions/ideas....
:: Tcl/tk is an interpreted language (yes?) which essentially makes
: command line calls to "embed" other programs: So don't you have to
: have both Tcl and your system running on the same box? I mean
: what some people are asking here is for a "client" to be running
: on a PC/mac and a "server" running on some mainframe with TCP/IP
: communicating things between them. Does Tcl allow you to do this...
: won't you still have to running X on your box for Tcl/tk to work
: with GCG or port GCG to the PC (please correct me...)
:
You would be running an interpreter locally to create the interface,
and an interpreter on a server, which can accept requests from the
other one. The 'request' can be to execute some tcl/commands in the
servers' context, and return the results. Currently you can run
Tcl/Tk under MS Windows (without the need to have X), but the interface
looks like X. A port is in progress (by the group of John Ousterhout) to
MS Windows and MacOS, which will have native look-and-feel.
: I have had the fun of writting a simple line-feed interface (menu
: based) for some of my programs. After much headaches I came up
: with a series of modules (in C) which had function calls such
: as
:: char * prompt_user_for_filename(char * prompt,char * protstr);
:: or boolean prompt_user_for_int_between_value(int,int,*int);
:: etc.
:: Then there was a menu module which essentially had calls
: like
: "next menu entry in XXX is a shell escape"
: "next menu entry in XXX wants prompts a filename with prompt xxx"
::: This left the talking to the user in a couple of modules and the
: rest of the modules (thankfully) sat happily just doing what
: they were meant to be doing...
:
I have been there to. (See the non-tk version of DCSE for DOS.) Tcl/Tk
is a lot nicer.
: What I realised as I wrote this was that
: a) the low-level user stuff could easily be ported to windowing
: enviroment
: b) the "menu-ing" stuff would need a bit of changing as you would
: have it more like an 'enviroment' rather than a menu... but do able.
: c) that *possibly* one could split the user interface from the
: program interface: so programs ask for
: "give me a valid filename"
: and the user interface has to deal with that command, and that this
: could realistically be sent across a network...
Actually, this is much how Tcl/Tk works. It offers a number of 'widgets'
commonly used in an interface, such as buttons, entries, text, menus, etc.
The widgets have defaults for colors key bindings, etc. which can be set
for the entire program using an options database. You also can specify all
options per created widget if you wish. All interaction with the widgets
gets translated to Tcl commands.
eg. the following command will create a button which will execute the tcl
command foo when activated:
button .b -text "Foo" -command foo
pack .b
The pack command is necessary to specify the order and position of
buttons and other widgets.
:: *I* love making up new words, so I like to call this a
: "Logical User Interface" (LUI)... but this is vapour ware at the
: moment.
:: I have no doubt that this has been done numerous times before, but
: what (as a programmer) I think would be nice is REAL low level
: control over the interface (you can't specify packing, button size
: anything)... you just ask what you need and you send it what you've
: got... Everything else is the client's problem. This gets close
: to HTML forms, except that an HTML form is *meant* to be a one
: shot thing, whereas I am asking for a real interface.
Using Tcl, you could send a little program to that will create the interface;
This can be almost a very simple list of what data you need (I would call this
high level though), or an intricate interface, eg. allowing for modified
behaviour depending on some of the choices: This can be necessary, how else
are you going to tell the user eg. that option 'X' is not available when you
work with DNA sequences, and that value 'Y' should be between a and b
for that kind of analysis, ...
:: For graphics I was thinking along lines of Display PostScript??
:: Any thoughts?
:: .. Please, if someone could enlighten me on Tcl/tk I'd be really
: interested
:
Visit the DCSE Home page at URL http://www-rrna.uia.ac.be/~peter/dcse
It has quite some info on Tcl/Tk. If you have access to SGI or Suns, you
could have a closer look at tkDCSE. I have not ported it to MS Windows
yet, as I'd rather wait for the Ousterhout port before I start porting
all the C-code in tkDCSE. The Tcl part would be a small problem, although
I am probably going to change quite some things there as well. I used small
procedures for creating 'compound widgets', and I think it might be better
to go OO for that. I haven't decided between itcl and Tix yet (OO extensions
to Tcl).
::: ewan
::birney at molbiol.ox.ac.uk: <a href="http://www.molbiol.ox.ac.uk/www/users/birney/me.html">
: me </a>
Peter De Rijk
--
----
Peter De Rijk derijkp at reks.uia.ac.be
<a href="http://indigo2.uia.ac.be:80/~peter/personal/peter.html">Peter</a>
