-----BEGIN PGP SIGNED MESSAGE-----
Some of you are aware that I'm writing a Tk GUI for DarwinPorts, which
itself is written in Tcl. At times I've run into Tcl-related questions
that I've directed to the DarwinPorts list; on Daniel's advice I'm now
directing them here.
I'm almost done with the roughing out/design of the GUI and internals
for v. 0.2 of my DarwinPorts GUI, and I now have a big decision to make
about implementation before I begin writing code. The first iteration of
the application simply worked as a GUI wrapper for the command-line
version: you filled in a text entry field, pushed a button or menu item,
and the output was piped into a text widget. Only marginally easier than
running DarwinPorts commands from the terminal, and not very polished.
If you're curious, the first edition can be downloaded at
http://www.wordtech-software.com/TkDarwinPorts.dmg . Just throw the
"DarwinPorts" folder into your /Applications directory (or move the apps
if you already have a DP folder in that directory)--some things won't
wowrk if it's installed elsewhere.
The DarwinPorts folks gave me a lot of good feeedback on improving the
interface, such as using listbox/table widgets for output, adding a
progress bar, etc. All of that is pretty much worked out now and will be
part of v 0.2. However, they also encouraged me to hook directly into
the DarwinPorts API, rather than simply calling DP ("port") from the
This is where I've run into problems. Apart from requiring a large
redesign of my program's internals, it also brings me into questions
about the design and scope of the program. Here are a few of the
questions that I'm trying to answer:
1. Hooking into the API would require me to use "package require
darwinports" in my scripts. Since I'm also using the GUI to manage the
installation of DarwinPorts via CVS, isn't this a showstopper for
someone who doesn't have DP installed--i.e., my script would look for
DarwinPorts, not see it, and crash? How would I address this?
2. I realize that I *could* simply include the DarwinPorts bits in my
application bundle, but wouldn't that mean my scripts would use *my* DP
libraries instead of those that are installed on the user's machines?
And doesn't that mean that my DP bits would essentially become a fork?
I'll be honest, I don't know enough to keep my stuff in sync with DP.
The API libraries are pretty dense and I haven't fully digested them. I
guess my question is, how would get the user's libraries to take
precedence over my libraries?
3. The benefit of my current design is that it's completely
separated/abstracted from DP's internals. The DP folks can make whatever
changes/updates they want to the structure, and I probably have to make
only minor changes to my application. Also, because my application also
calls cvs as an external process, calling port as an external process
("/opt/local/bin/port install foo...") also is consistent in terms of
I'm not sure which way to go. I realize that keeping the GUI completely
separated from the command-line internals means I give up some control
over what data is presented: even with a listbox, I'll still be piping
the same output that I'd get from running port on the command line. But
the more granular control of data output seems to be the only upside,
while the downside is a more complex design, more difficult deployment,
and a lot more work.
I'd appreciate any insight into these questions that anyone can offer.
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----