Version 5 of SEE

Updated 2002-06-21 01:08:53

STEP back.

Purpose: Discussion of ways to enhance productivity of Tcl developers and users.


The acronym resolves to Smart Editing Environment, it was coined by Jean-Claude Wippler as an alternative to the all-present IDE.


In my (AK) vision the SEE is not a monolithic application containing everything which is required to edit, browse, add, delete in packages, scripts, files, etc., but a set of applications each doing some simple task, talking to each other, maybe by using the kernel builtin send, or by some other means (sockets for example). And for the cases some monolithism cannot be avoided I propose to use a plugin structure, i.e. an application with a well-defined interface for loading additional functionality into it.

At the center I have two core applications:

  • A browser for archives, able to list and search the extensions (and libraries) in an archive. It should make no distinction between a local archive (the installed extension), and a remote one (part of the net of all archives ETEN). Functionality beyond the described is added via a plugin-system.
  • A browser for extension and libraries, which are either in an archive or outside (f.e. during development). It has no basic functionality, just a plugin-system to add some.

The above definitions don't speak about the user interface, and their definition should not matter, but I have to admit, that I envision them as "explorer-like", i.e. a single window divided into 2 parts, on the left a tree-view of the archive or extension structure, on the right a more detailed view of the entry currently selected in the tree.

(Larry suggested to take a general file browser, enhance it to be able to use different display systems depending on the type of file and then to use this mechanism to detect, display and operate on extensions. I am unsure about this. It might be feasible in the future. For now I have to admit that this currently aims to high IMHO, I would rather focus more on a pure extension browser, and maybe written so that later integration into a general file/dir browser is easy.)

I currently have no ideas about plugins for an archive browser, but several for the package browser. They are:

  • Test suite management. A plugin is able to detect the presence of a test suite and provides functionality enabling the browser to display its contents. It additionally provides an interface for external editor applications wishing to manipulate the test suite. Such applications may range from simple editors for a single testcase to editors which are part of a code editor (procedures, classes) for example, with extended functionality (testcase <-> code association, ...). As long as they speak the defined interface it should not matter. I made a minimal prototype of a GUI to a test suite evaluator/executor. (Add url here).
  • Management of help texts and documentation. See Bryan Oakley and his thread about a text dump format. (Note: Find dejanews thread url, insert here).
  • Utilities helping in compilation, configuration and installation of extensions. For example a bras-file editor (Note: Paul Duffin, Jean-Claude Wippler, WOBBLE).
  • Code browsers/editors. May abstract away from files and concentrate on the logical structure of classes, methods and procedures, plus higher level aggregrates (function groups, ...), which are then automatically mapped to files. Discussion of possible mapping policies required (single file for all, one file per proc, some sort of dependency analysis, user groups procedures/classes into related sets => hints for mapping), as is discussion about useability of such a scheme.
  • Other possibilities include:
        Documentation as part of code/procedures, at least from the view of the editor. 
        Automatic linkage to help editor/test editor. Or integrated into the code editor.
        Generation of make/bras files from the code/files in the package. See -> automake/autoconf.
        Generation of package index files.

The concept of the plugins for the extension browser can be extended further, by so-called "smart" extensions. They may contain special plugins which are able to supersede and/or enhance existing plugins or temporarily install new, extension-specific plugins. This way it is possible to handle even very special and/or unusual situations.

An example is "Makedist" [L1 ] and its extension specific control file, "PREPARE".

Note: Makedist is basically the "setup.py dist" from the Python DistUtils-SIG [L2 ], "creation of a source distribution".

Here is a picture showing some relationships between possible components http://www.oche.de/~akupries/step/pic/see.gif.


I have much more text lying around, but it is not organized yet, and therefore not included here, for now.

-- AK


Category Acronym