Date: Tue, 25 Feb 1997 11:31:17 -0600 From: "Eric L. Hernes" <erich@lodgenet.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: msmith@gsoft.com.au, freebsd-config@freebsd.org Subject: Re: Psst! TurboVision? Message-ID: <199702251731.LAA08037@jake.lodgenet.com> In-Reply-To: Your message of "Mon, 24 Feb 1997 20:22:32 PST." <6596.856844552@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" writes:
>
>I wish we were using itcl as our default base, of course - it'd be a
>lot easier to maintain their OOP framework through that mechanism than
>it's going to be in TCL. The only way I see it working now is that
>we'll write set of C++ derived classes for doing sysinstall-ish stuff
>and with the kinds of data structures encountered more often in that
>context, then we write the TCL->C++ goop for interfacing to those
>classes. I don't see any reason to implement the entire TurboVision
>API in TCL unless it's for the manifest purpose of providing those
>components for further extention, and TCL is bad at that (hence the
>reference to [incr tcl] :-).
>
Swig might help here. 1.1 does a lot better at the OOP stuff. It
may be able to generate most of the glue. I don't have enough experience
with c++ yet to do the interface to tvision, but I've been playing with
the C stuff. Swig generates code to access c structures (and c++ objects)
similar to the way Tk handles widgets. For example if I've got a structure
like:
struct foo {
int a;
int b;
int c;
}
somewhere in my C-library, swig will provide access to it via calls
like:
foo f
f configure -a 123 -b 321 -c 999
puts [list [f cget -a] [f cget -b] [f cget -c]]
>
> Jordan
eric.
--
erich@lodgenet.com
http://rrnet.com/~erich erich@rrnet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702251731.LAA08037>