LablTk internals

LablTk internals

[Matt Gushee]

Hello, all--

I am working on some enhancements to LablTk, to bring it up to date with
Tk 8.4. One of the features I want to implement is validation for Entry
and Spinbox widgets (the latter being a new widget that I have added
already). It looks like this will require support module(s) in the
'builtin' directory ... the validation commands are somewhat like event
bindings, in that they use fields (with % substitutions in Tcl syntax)
and require registering callbacks; on the other hand, unlike event
bindings, but like Button and Menu commands, they are bound to the
widgets with configuration options rather than a standalone binding command.

So I need to understand more about those 'builtin' components. I'm sure
I can work out the answers myself, but it will take a lot of time, so
I'd greatly appreciate it if someone could answer at least these questions:

 * How are external support modules associated with modules generated
   from Widgets.src? If I introduce a new module(s), do I need to modify
   a Makefile, or are the dependencies all auto-detected? In the latter
   case, what do I need to do so that

     option ValidationCommand

   will work in a widget definition, where the ValidationCommand type is
   defined in an external module?

 * What do the prefixes 'builtin_', 'builtina_', 'builtinf_', and
   'builtini_' mean, and why do some of the modules in 'builtin' have
   these prefixes, while others have no prefix?
-- 
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] LablTk internals

[Jun Furuse]

Hi,

>  * How are external support modules associated with modules generated
>    from Widgets.src? If I introduce a new module(s), do I need to modify
>    a Makefile, or are the dependencies all auto-detected? In the latter
>    case, what do I need to do so that
> 
>      option ValidationCommand
>
>    will work in a widget definition, where the ValidationCommand type is
>    defined in an external module?

Dont know... Long long ago we have tried to describe the dependency
information as detailed as possible in Makefiles, and some of them are
automatically created by tkcompiler executed by make. But I forget
this is perfect (i.e. type "make" does all the job) or not. 
I recommend to "make clean all" for sure. It is slow but safe.
  
>  * What do the prefixes 'builtin_', 'builtina_', 'builtinf_', and
>    'builtini_' mean, and why do some of the modules in 'builtin' have
>    these prefixes, while others have no prefix?

Ok, let me look at the source... Well,

builtin* things 
  They are inserted directly into tk.ml by tkcompiler.
  The difference of _, , f_ and i_ indicate where they should go.
  {labltk,camltk}/Makefile.gen:

  builtin: 
	Primitive definition of built-in types which are hard to describe
	inside Widgets.src. Such types are declared as external 
	in Widgets.src. Ex:

	type Index external % builtin_index.ml

  builtini:
	*i*nterface between Tk and Caml for the built-in types,
	for translation of tokens such as cCAMLtoTK* and cTKtoCAML*
	functions.

  builtinf:
	*f*unctioni definitions which are hard to write inside 
	Widgets.src. They will be available inside Tk module, so
	non-widget specific command should come here, such as
	bind command.

  builtina_empty: what's this ? I do not remember... Ignore it. :-)

non builtin* things
  They are usually defines widget class specific functions hard to
  describe in Widgets.src. To be incorporated to the module, these 
  external definition files must be declared using external keyword
  like:

	module Optionmenu {
	  external create "builtin/optionmenu"
        }

  In the above, the function create must be defined inside 
  builtin/optionmenu.ml.	

Best,
--
Jun