From AlphaWiki

Development: Xserv issues

Specific issues to be resolved

InSh mode -- The InSh mode used for interactive shells is now a minor mode. This means the real mode of the window is now open to being adjusted. This is useful for, e.g., a tex console, where we'd like the window to be in TeX mode. But this means that an xserv implementation needs to be able to specify what mode it wants the console in.

status: Currently this is done (hacked in) by allowing the driver to set params(shellmode) TeX and that is passed on appropriately. A better mechanism might be needed?

Integrate tetexComm -- TeX mode still has cmd-T and cmd-R. We need to merge these.

status: none

Xserv preferences dialog and Cancel -- Currently Cancel in the main dialog doesn't actually cancel anything.

status: cancel does now cancel changes, but probably only at the topmost level. Changes to bundles or to required helpers of other helpers are probably not cancelled. Testing is needed.

Xserv preferences file -- Currently xserv uses it's own prefs mechanism and saves a special file which contains all the xserv declarations which have been made. But this is really quite problematic for several reasons -- for example if you upgrade AlphaTcl and a service has changed (extra optional parameters, say), the new definition will be ignored in favour of what is in your preferences. Really it would be much better if Xserv just used the same approach as every other AlphaTcl package. If it needs some special new functionality, let's define that and add it. Another problem with this approach of storing all Xserv info, even if AlphaTcl has changed and moved on, is that we have a maintenance nightmore -- a user may have all sorts of old stuff stored forever (and getting in the way) in their xserv preferences file. I already have all sorts of junk in that file just through a few days of fixing/improving alphatcl's xserv usage.

status: none

Xserv preferences dialog is currently quite un-userfriendly. Let's improve it. There are too many nested dialogs.

status: none

Xserv finding programs -- Each platform has its own standard locations which should be searched. This can, possibly, go beyond $env(PATH), for example on Windows we might want to specify a default place like C:/Program Files/*/prog, and on all platforms we might want to look in Alpha's Tools directory.

status: none

Relationships between services -- I might have an ftp upload service, an ftp download service, a url download service, and a more general ftp bundle of services (capable of upload, download, mkdir, etc). Now, how do these interact? How are they made available in the prefs dialog? How can I specify that an ftp download service can cope (with some massaging of url->ftp info) with downloading ftp:// urls, but not other urls. If I have an ftp bundle of services, then the underlying services are hidden from the user (you only see the bundle in the dialog), which is good and bad. To take a concrete example, I want to generalise the 'fileset ftp mirror' package to be a 'fileset remote mirror' which can use various methods to mirror remotely -- perhaps webdav, perhaps ftp, perhaps secure ftp (sftp), perhaps secure-copy (scp), etc. All of these can accept a 'url' as the remote destination, so to activate the service on a given fileset, I want to specify at least a url, and either a global 'upload' helper or a per-fileset upload helper. In the latter case that per-fileset helper needs to be compatible with the specified url, and in the former case, any global upload helper will never be able to handle every single url type... So what's the solution?

status: none

Setting related services -- If I'm using teTeX, or MikTeX, then once I've located one service (e.g. 'etex'), I know where I'm going to be able to find all the rest (bibtex, makeindex, etc). It would be much nicer to be able to give that information to Xserv, either that or to provide a wizard which allows quick and easy setting of a large block of services. (Press button, locate MikTeX install directory, calculate list of all new settings and present them in a checkboxed list to the user with an option to reject any they don't want to set).

status: none

Menu Icons -- a few modes (TeX, ftp at least) used 'app::registerMultiple' to make the icon representing a give menu change automatically depending on the value of a given *Sig. Given sigs will no longer exist, this mechanism will no longer work. If we do wish to continue it, we'll need to find a new approach. (HTML mode simply gives the user a preference they can use to decide what menu icon they want).

status: app::registerMultiple is no longer used. The Ftp menu has a fixed icon. The TeX Menu includes a LaTeX Menu > Change Menu Icon command which allows all non-Windows users to change the icon.

Global vs Extension Package Services

[Cbu] 11March05]] As AlphaTcl is gradually transformed to use the new 'xserv' technology, many [xserv::declare] and [xserv::register] calls are appearing in a variety of SystemCode and package source files. For example, all of the 'internet' services are defined in "www.tcl", while all of the TeX services are in the TeX mode "latexComm.tcl", and then we have various diff services in "diffMode.tcl" and Tcl services in "tclMode.tcl".

I think that it would be a good idea to make a conscious effort to determine which services are available globally (i.e. SystemCode), versus those which require a specific AlphaTcl extension package. I would suggest a new always-on core package named something like

(or whatever seems more intuitive) which serves these functions:

Ideally the xserv registrations would be organized in a manner that reflects the different Helper Applications dialog pane to make it easier to find them and see what is going on. I would suggest that since most (if not all) of the TeX services do not specifically require TeX mode, these should be considered global implementations and placed in this file.

Placing all of the dialog code in this new package would take allow the current "xserv.tcl" file to only be concerned with processing the scripts. Developers would then be able to experiment with different dialog routines with a smarter source file while leaving the basic "xserv.tcl" file alone. This would also provide one-stop shopping for AlphaTcl pirates who are trying to figure out how to create their own xserv code.

Individual packages like "WWW" and "tkhtmlViewer" would then be free to declare their services only if they are actually installed (and the service is appropriate to the user's platform.)


Retrieved from
Page last modified on May 04, 2007, at 06:55 PM