|
Although it is possible to write a TiK plugin completely in a compiled
language, for practical purposes, all TiK plugins have at least
glue code written in Tcl, and
many have both Tcl and Tk functionality.
Core plugins are could be developed in this tikpkgs project, but normally are
found within the tik core development project. Just
which packages are part of that core is a decision of the committing
team who work on the core distribution. From time to time, some
packages may be dropped from the core (especially when over half of
the known TiK users are not using the package), and at times packages
from this project may become part of the core. Even if there were
no other reason for standardization, that is a crucial reason.
|
Selecting the name
Although the normal Tcl standard is to name variables and namespaces
which are intended to be referenced externally starting with a capital
letter, and private variables, procs, and even namespaces with a
lowercase initial letter, TiK package management requires a variation
on this scheme which may very well predate that standard.
Each package has one name, immediately below the :: (root)
namespace of the application. The main script(s) run within the
"::" namespace. Most global
settings, even for packages, exist in the "$::TIK()" array, with defaults set there
in the user's tikrc, and defaults before-user-options
set in the top of the plugin script with a special call designed
for that exact purpose.
Throughout TiK, the package is known by that single lowercase name.
To allow for cross-platform compatibility, plugins use all lowercase
(or lowercase and digit) names up to 8 characters. The script for
the plugin is name.tcl, settings are ::TIK(name, ), and the package
is generally referred to by name. If the script is to be
autoloaded by TiK, or even auto-loadable, it must be installed in the
main distribution packages/ subdirectory (for core modules only) or
in the user's packages/ directory, which is adjacent to the user's
tikrc configuration file. The exact location of the user's directory
is relative to the Tcl $env(HOME), and is platform dependent.
Writers of large plugins should consider using more than one namespace,
with initialization code in the parent namespace ::name,
and distinct functional sub-modules in
::name::modulename.
|
