Home | Project Home | About | Partners | Contact Us

How to write a TiK Plugin
Part 1: Planning

VA Linux Systems

Planning

Planning may be the most important part of building a new plugin for TiK. It requires:
  • Understanding the interactions with TiK.
  • Understanding the interactions with other plugins.
  • Understanding event processing
    • Waiting - letting the application run while awaiting your events.
    • Net events - incoming messages, backgrounded processing
    • User events - mouse/keyboard
    • Window events - (window appears, is destroyed, is hidden/iconified)
    • Menu or pseudo-events

  • Understanding Tcl/Tk structure
  • Cross-Platform Considerations
    • Newline and end-of-file selection
    • Translations and Encoding
    • Font Availability
    • Connection/Socket support
    • Background external task support
    • Availability of non-Tcl-core compiled extensions
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.

Callbacks and Setup/Option Values

Event Hooks

Menu Insertions

Load/Unload Operational Hooks

Activation and Deactiviation

HTTP Fetches and other Network Access

The Ticker and Buddy List

Namespaces

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.

More to come
All trademarks and copyrights on this page are properties of their respective owners. Forum comments are owned by the poster. The rest is copyright 1999-2000 VA Linux Systems, Inc.