From vectorbd!pagesat.net!news.erinet.com!uunet!hobbes!davidy Wed Apr 19 16:32:35 1995 Xref: vectorbd biz.sco.vtcl:27 Newsgroups: biz.sco.vtcl Path: vectorbd!pagesat.net!news.erinet.com!uunet!hobbes!davidy From: davidy@sco.COM (David Young) Subject: Re: vtcl vs. tk (was Re: What is vtcl, how to learn?) Organization: The Santa Cruz Operation, Inc. Date: Fri, 14 Apr 1995 17:56:52 GMT Message-ID: <1995Apr14.175652.5429@sco.com> References: <1995Apr11.021514.4953@sco.com> <3mjpv5$sj6@Starbase.NeoSoft.COM> Sender: news@sco.com (News admin) Lines: 123 In article <3mjpv5$sj6@Starbase.NeoSoft.COM> kunkee@Starbase.NeoSoft.COM (Randy Kunkee) writes: >There is a lot going on in the tcl/tk world. I suggest also checking >out the comp.lang.tcl newsgroup. Yes! You'll also see postings about visual tcl there as our ports to other platforms become available. >From what I've seen at a cursory level, tk is simpler to use than vtcl. >Anybody game for comparing the two? Since I'm just a tcl/tk guy, I can't >speak to vtcl. However, why would a person in my position ever be >interested in vtcl? It's supported on fewer platforms, and appears to have >a more complicated widget interface (after all it's built on Motif). Based on your statements, I must conclude that your evaluation has indeed been "cursory." Create a label widget with visual tcl: VtLabel $form.label -label "Hello World" or a main dialog with title and an OK button: VtForm $app.mainForm -okCallback DoIt -title "My Program" I guess the best way to respond to your question is to describe the "design center" for visual tcl. #1 it was developed for wrapping Motif around systems mgmt tools (though it can be used for many, many non systems mgmt needs) #2 it was targeted for use by non X/Motif engineers whose core competency was in systems management issues; it had to support any easy-to-use syntax/semantics that would allow somebody to ramp up very quickly. #3 it was designed to support typical systems mgmt environments where character interfaces still dominate (particularly when management is conducted remotely over modem lines). The language was designed to program to both environments (character and X) from one source file: e.g. VtList $form.machineList \ -MOTIF_rows 28 \ -CHARM_rows 10 \ ... (Charm = "Character Motif") #3 it had to support OSF/Motif 1.2. At the time we started this project, 3 1/2 years or so ago, tk was not on our radar. Tcl was brought to SCO; we fell in love; and Visual ksh was reborn as Visual Tcl. In order to achieve the goals of visual tcl, particularly the ease-of-use goal, we leveraged Motif (file selection boxes, message/warning/info/etc. dialogs and all the literature about Motif) and applied a thin layer of built-in "policy" that achieves automatic placement of widgets (and a few other things). We also added the ability to override the automatic stuff in order to allow people to expand their program's control of the environment as they learned more and more about Motif programming. Visual Tcl's architecture is different than tk. The interpreter has NO GUI-building code. It has commands that invoke gui-building by a motif server daemon. The server daemon, connected by named pipes (and eventually sockets pipes), is the real motif application that does the actual rendering. The speed is fantastic because the daemon support multiple interpreters simultaneously. The server daemon comes in 2 flavors currently: Motif 1.2 and "character Motif" (Motif library with curses drawning inserted). In the SCO labs, we have a running native Windows prototype. This means that you can create visual tcl scripts that run in a Unix server environment, but are rendered on a native Windows PC using a VERY low bandwidth protocol (no Xlib necessary). As a result, again with systems management needs in mind, system administrators will be able to run visual tcl applications from the Windows PC at home or at a remote office and manage servers via a, say 14.4bps modem, located back at work or a customer site. This also means that instead of having a bunch of useful tcl-based gui apps all over the place, you simply distribute the rendering server component only and execute the interpreted script on your remote server. When you update the server script, EVERYBODY is automatically updated without the pushing of new software. I see tk as a full-featured, general purpose GUI application development tool. There are LOTS of tk fans at SCO, so I think that religion is a minor issue in this discussion. But if your purpose is to produce systems mgmt tools that are 1) motif 1.2 compliant, 2) support character and Motif, 3) is fully supported by a major server systems vendor, and 4) support a client/server model that levereages the services of remote servers, then I recommend visual tcl. And, yes, we're on few platforms right now. But two things will change that: #1 IXI, SCO's subsidiary, is porting Visual Tcl to SunOS/Solaris, HP-UX, AIX, OSF/1 ("Digital Unix"). #2 SCO is making the visual tcl source code freely licensable The license simply requires that you preserve the base programming language interface. > >Corporate support for Tcl from SCO is heartening. But, I'm a little puzzled >as to why they chose to go off on their own tangent. (There already was a >TclMotif extension, and for all I know, vtcl is built on top of that.) Yes, we are very very proud to be the first major UNIX system vendor to take this step. The next release of our OS (due the first half of this year) is "riddled" with Tcl. This is not one of many lab experiments. We had a different set of goals to address. Restating these goals in a different way: Pure Motif appearance Multiple GUI support Performance Simplified/More approachable than a script Interface to Motif Separation of execution and GUI rendering Distribution of execution and Display over the network Re: TclMotif.... Visual Tcl is NOT built on TclMotif. It didn't exist (to my knowledge) when visual tcl was created. Again, Visual Tcl is not a "straight mapping" of Motif to Tcl. We use the Motif programming concepts and semantics for widget geometry management and resource names, but hides a lot of other, less friendly details of Xt/Xm programming. Hope that helps, David -- davidy@sco.COM David H. Young (408-427-7784) The Santa Cruz Operation Product Marketing Manager, Future Technologies