Different interface needed for V8.0 altogether:TCP/IP clients

ewan birney birney at molbiol.ox.ac.uk
Thu Jan 26 10:12:16 EST 1995

derijkp at reks.uia.ac.be (Peter.DeRijk) wrote:

This is about Peter's Tcl/tk stuff

> Not only is Tcl/Tk a great language to create an interface. It is also
> a reasonably featured programming language (solving the feedback problem)
> and a great 'glue language': From Tcl it is easy to execute other
> programs with any parameters (eg. GCG programs). This way the interface
> can be created in Tcl/Tk, and from the data in the interface any command
> can be composed and executed. There is no need to change anything to
> their command-line interface. eg. in tkDCSE I have incorporated the
> programs 'readseq' and 'Clustal V' seamlessly (except for the
> acknowledgements ;-)), without changing anything in them.
>     (2) PC and Mac applications talk _very_ different tongues. Apple events 
>     are easy to program for a Mac programmer, but certainly don 't agree well 
>     in source code with the corresponding Windows code. 
> It will be easily portable to the mainstraim platforms, when the ports
> are finished.
>     Therefore, I would consider TCP/IP to be the most generic 
>     protocol as understood by most reasonable operating systems. The more 
>     fancy you want to become the more off-mainstream your development will 
>     be. 
> There already exist extensions to Tcl which will provide an easy access
> to TCP/IP, etc.
> A very important property of Tcl for this project is its interpreted
> nature. In Tcl any program, procedure or range of commands is
> represented as a string that can be handled as data, ie. changed,
> transmitted, and executed at run-time. This property makes it possible
> to send a range of commands (eg. a new function, the commands needed to
> run a utility, etc.) via TCP/IP to a Tcl interpreter on another
> machine, where they can be executed directly.
> In my vision, the interface and even most of the tools would run
> locally in a Tcl/Tk interface. For some analyses, database searches,
> etc., a set of commands and data can be executed in an interpreter
> running on another machine (server). Naturarly, other services can be
> accessed as well, by executing their programs.
> If other people are interested in this project, have suggestions or
> want to cooporate, I can be reached at derijkp at reks.uia.ac.be.
> Regards,
> Peter De Rijk

Great...Please do it :)

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...)

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

	char * prompt_user_for_filename(char * prompt,char * protstr); 

or 	boolean prompt_user_for_int_between_value(int,int,*int);


Then there was a menu module which essentially had calls
	"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...

What I realised as I wrote this was that 
a) the low-level user stuff could easily be ported to windowing
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...

*I* love making up new words, so I like to call this a 
"Logical User Interface" (LUI)... but this is vapour ware at the

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.

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


birney at molbiol.ox.ac.uk
<a href="http://www.molbiol.ox.ac.uk/www/users/birney/me.html">
me </a> 

More information about the Info-gcg mailing list

Send comments to us at biosci-help [At] net.bio.net