No subject

be used by different clients.

> A classic Unix design pattern would limit the scope of the project to
> writing a user-friendly GUI, leaving MacPorts internals alone, and using
> the port tool as the point of contact. The GUI can drive MacPorts via
> commands to the port tool, then parse its output for its own purposes.

The problem with that is MacPorts never defined a "stable" output format
for the port command and I am not sure whether compatibility is
something we want to hold us back from changing the output of the port
command line interface. Hopefully, I did improve the situation a bit by
introducing the -q flag for some of the commands, which was mainly for
myself to make it easier to pipe the port output into other tools.

> A lot of Cocoa devs (professional ones) mock this approach as simply
> wrapping a GUI around a command-line tool. But this approach has the
> virtue of simplicity, letting MacPorts do what it does best and letting
> the UI concentrate on providing a pleasant user experience.

Well, the idea of the MacPorts.framework was to give GUI developers a
library interface they could use instead of worrying to implement a
screen scraper and parse the output correctly.

Rainer