On Tue, 21 Mar 2000, J.R.Suckling wrote:
> Rick Macdonald wrote:
> > There are some features missing for me in vTcl that I don't think are
> > easily added:
>
> This first one might not be so hard.
>
> > - multi source file development.
>
> The biggest deal here is that all the code that is sourced into
> vtcl becomes part of the vtcl project. By that I mean when you
> save your work everything, including all the sourced code, is saved.
>
> There is a set of code that is not saved, that is the vtcl code it's
> self. from what I can tell is that all the code that is prefixed with
> 'vTcl' is not saved. One solution might be to turn this around and
> define a prefix unique to each vtcl project ( or file ). Now use that
> prefix to mark procs in the vtcl project. This set of prefixed procs
> could be the only ones saved that way an external set of procs
> could be used.
So, if each file has all procs with a common but unique prefix, then vTcl
could save them to separate files based on the name. That would be one
way, but perhaps too restrictive for some people.
Another way might be:
vTcl can tell what procs are in a file by comparing the proc list before
and after sourcing the file. After being loaded, perhaps a user would have
to define which file a proc is in when new procs are created. Or, perhaps
each file would have its own "Function List" window. This way, whichever
Function window you use to "Add" a new proc -- that's where that new
function would reside.
This is just an idea. I'd guess that we don't need to re-invent this.
There are probably reasonable conventions used by existing commercial
developement packages (for any language).
> > - calling one vTcl project from another.
>
> tcl was meant to be process glue from the start.
> I think that should be done in software.
> open a pipe or something.
>
> Or am I missing something.
>
> Is this different from multi source file development?
Slightly. Currently in vTcl, each file is separate and each one starts
with .top17, .top18, etc. The names would have to be unique in order to
run them in one wish interpreter. What I'm getting at is a library of
reusable app components, such as data viewers, tables, spreadsheets, etc,
that are built and maintained as stand-alone vTcl projects but you can
source them into other specific vTcl apps at run-time without conflicts.
Currently, to do this I have to create slave interpreters and source the
file there, and alias and monitor "exit" and other commands.
> > - multiple instances of a toplevel, including some sort of
> > dynamic widget alias scheme.
> vtcl does not do dynamic widget creation.
> What I do is let vtcl make a prototype.
> than I include that in a proc and a loop.
> (ie. I do my self)
So do I, but vTcl needs to do this. Stewart started it long ago, but it
was never complete. If you look at any window:
proc vTclWindow.top60 {base} {
if {$base == ""} {
set base .top60
}
...
toplevel $base -class Toplevel -background grey85
-highlightbackground grey85
wm focusmodel $base passive
wm geometry $base 622x582+175+49
...
frame $base.fra61 -background grey85 -borderwidth 1 -height 30
-highlightbackground grey85 -width 30
You can see the intent that you can call "Window show .top60 .top60N1",
for example, to have multiple instances of the top60 window.
However, "top60" is still hardwired elsewhere in this creation proc:
scrollbar $base.fra61.cpd62.01 -background grey85 -borderwidth 1
-command {.top60.fra61.cpd62.03 xview} -highlightbackground grey85
-highlightthickness 0 -orient horiz -width 10
pack $base.fra61 -in .top60 -anchor center -expand 1 -fill both -side top
Plus, what I meant by "dynamic alias", is that if I define a listbox in
.top60, and give it an alias of "MemberList", then I need some way of
having different alaises for each instance of the top60 window. For
example:
Window show .top60 N1
# This listbox is automatically widget(MemberList-N1)
Window show .top60 N2
# This listbox is automatically widget(MemberList-N2)
If I have to do a query to get/set the alias, that's OK too (not that this
makes any sense):
Window show .top60 N1
set widget(MemberList-N1) [Window getalias .top60 N1 MemberList]
I think internally this is more complicated that it appears. If a toplevel
window has a listbox with a binding behaviour that copies the curselection
into an entry widget, or label, or whatever, then the code for this
binding needs to magically know the name of the entry widget for its
instance of this toplevel.
You sometimes get around this by only allowing one instance in the first
place (local grab), such as in the case of a file selector. However, it is
certainly useful and common to want multiple intances of toplevels in an
app.
I don't care about the implementation. These examples are to clarify my
points about what is required.
...RickM...
---------------------------------------------------------------------------
To unsubscribe from the Visual Tcl mailing list, please send a message
to [EMAIL PROTECTED] with "unsubscribe vtcl [EMAIL PROTECTED]" in the
message body (where [EMAIL PROTECTED] is your e-mail address).
