caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jun Furuse <furuse@yl.is.s.u-tokyo.ac.jp>
To: Matt Gushee <matt@gushee.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] LablTk internals
Date: Fri, 18 Nov 2005 15:00:54 +0900	[thread overview]
Message-ID: <87iruqmr55.wl%furuse@yl.is.s.u-tokyo.ac.jp> (raw)
In-Reply-To: <437CF642.8060302@gushee.net>

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


      reply	other threads:[~2005-11-18  6:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17 21:29 Matt Gushee
2005-11-18  6:00 ` Jun Furuse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iruqmr55.wl%furuse@yl.is.s.u-tokyo.ac.jp \
    --to=furuse@yl.is.s.u-tokyo.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=matt@gushee.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).