SEE

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, "creation of a source distribution".

Here is a picture showing some relationships between possible components .

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

-- AK

Hmmm... I was looking for "see" as a command, not an acronym. But https://wiki.tcl-lang.org/see* insists on showing me the seek command.

LV Traditionally, these minor commands have been documented either as a part of the major command (such as entry, button, etc.) or as a combination of the major and minor command (perhaps like "button see" , etc.).

But I can envision cases where documentation of general features of a minor command that were consistent across all widgets might be worth documenting together.

See can also be a Tk widget command. It adjusts the view of a text widget to a certain position. For example, you load a text widget and want it to cut right through the entire content and show you the last line:

    $toplevel.text_widget see "end - 1 char"

... or you may want to have the cursor automatically positioned at the 5th line. But that makes the widget display from the 5th line on only, hiding the 4 first lines, and you want to see them all:

    tk::TextSetCursor $toplevel.text_widget 5.0
    $toplevel.text_widget see 1.0

The first line positions the cursor at 5.0. The second line makes you "see" from the first line on.

RS 2007-01-22: Here's an appromixation for the same on a canvas widget: it moves the view so that the top left corner of the given tag or id is visible

 proc canvas'see {w tagorId} { 
     foreach {x0 y0 x1 y1} [$w bbox $tagorId] break 
     $w config -scrollregion [$w bbox all] 
     foreach {sx0 sy0 sx1 sy1} [$w cget -scrollregion] break 
     $w xview moveto [expr {$x0*1.0/($sx1-$sx0)}] 
     $w yview moveto [expr {$y0*1.0/($sy1-$sy0)}] 
 } 

Look also at xotclIDE that implements many of written requirements (repository browser, code browser, documentation tool, deployment tool (also for Tclkit), configuration browser, syntax checker and debugger).