[Xcircuit-dev] insertparam without tcl

[R. Timothy Edwards]

Dear Larry,

> As is pointed out in comments in the parameter.c,
> insertparam() is broken in the non-tcl case.
> I have started to play around with the code.
> Before I waste too much time, can someone
> confirm that my approach is sound?

I question the desirability of messing with the non-Tcl code.
It's just so horribly outdated.  Wouldn't you rather just
convert it wholesale to something more modern (not to mention
compatible with Windows) like Qt or GTK?  But if you want
to do it, go ahead.  If you break anything in the Tcl version,
I'll fix it.

> I think I need to add PARAMSEL_MODE to the
> enum editmode in xcircuit.h.  I'll enter that
> mode after the Wprintf("%s", sstart);
> but not actually modify the string yet.

The idea of the modes is that you could potentially do
any mouse, button, or keystroke in the mode, and the
dispatch routine would interpret the keystroke (or rather
the function binding of the keystroke) relative to the
current mode.  In this case, though, there is no need,
because the whole program will hang, waiting for a response.
This is the way the Tcl version works, which calls the
procedure "promptselectparam" that pops up a window, then
waits for a response and returns the answer.  To match
this behavior, the non-Tcl version should at this point
generate a pop-up window presenting all of the parameters
belonging to the object and their instance values,
wait for a selection, and return the string value of
the parameter key (char *selparm).  At this point, the
Tcl and non-Tcl versions will run the same code (from
parameter.c line 1619).

> On a side note, it looks like this feature has been
> broken (for non-tcl builds) since at least 3.1.38.
> Is parameter usage really that unusual?  I, personally,
> can't survive in xcircuit without it.

No, it is not really possible to survive without it.  I
haven't used the non-Tcl version of XCircuit since roughly
version 3.1.38.  I just compile it from time to time to make
sure it still works.  After a while I just got sick of working
with the Xw code, and the other options (Qt, GTK, as mentioned
above, and a few others) just didn't seem to me to be as elegant
a solution as using the extended Tcl interpreter.  Every now and
then I think about adding some of the Tcl script features back
into the non-Tcl version, but I can't convince myself that it's
worth the effort.

I gather from some of your previous emails that the reason you're
compiling the non-Tcl version is that you want the Python interface.
One could potentially map all the Tk code into Python/Tkinter, and
turn xcircuit into an extension of Python rather than use it as an
embedded interpreter.  This is a lot more work but ultimately more
productive.  I've worked enough with the C calls to both Tcl and
Python to know that most of them have a 1:1 mapping.  It might even
be possible to have a "meta" version of tclxcircuit.c that uses
non-specific interpreter calls, that are mapped into either Tcl or
Python.

					Regards,
					Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim.edwards at multigig.com     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+