Please review first draft of Fossick - a MacPorts GUI

Kevin Walzer kw at
Sat Apr 20 11:28:04 PDT 2013

Hi Ian,

I'm the competition here 
(, but since no one else 
has provided any comments yet, I'll offer a few.

The app felt very sluggish the first time I ran it in Xcode--I wasn't 
sure if this was because of the overhead of running it under Xcode or 
what. It was a bit snappier when I closed Xcode and ran it separately.

 From a design standpoint, the UI is a bit counterintuitive. I 
understand the idea behind the side-by-side text views, but it strikes 
me as fiddly and very much out of step with the customary two- and 
three-pane interfaces that are prevalent today: table view, tree view, 
text view. My solution is to have all data in a single text view; there 
may be other ways to do it, such as a floating window, etc. But I didn't 
grok the purpose of the twin text views until I read the "readme." You 
can't assume users will do that.

I also noticed that changes in MacPorts were not reflected in the app 
after running an operation. For instance, I selected a random port 
(gawk) and installed it. It did not change state in the table view after 
the port was installed (i.e. was not listed as being installed). It did 
not show up as installed until I re-launched the app. That's a fairly 
significant issue; users will wonder if anything happened if they do not 
see changes in the UI that reflect operations they have run.

In a similar vein, the app provides no visual feedback of an operation 
running. No scrolling text in the text view, not even a progress bar. I 
ran an install command and the app just sat there. A user should not 
have to select "view output of operation" from a tiny little popup menu 
to get an indication of what is happening.

It appears you're handing a lot of the operations off to AppleScript to 
actually execute port commands, via the "do shell script" paradigm? 
That's an interesting choice. It solves the problem of running 
privileged operations without having to delve into the authorization 
libraries, but doesn't it run the risk of locking up the app? 
AppleScript blocks until a command is returned. (Wranging with this very 
dilemma years ago, I finally ran across a different solution, whereby a 
user password is echoed is piped to "sudo port  install" or what not.) 
I'm curious how you keep the app responsive while you have this massive 
blocking operation going on under the hood. Did NSTask not provide 
useful tools for running port commands, or was there some other reason 
for choosing AppleScript?

Anyway, I realize this is an alpha of an alpha build, and there's still 
a lot to be done, but some of what I'm responding to seems basic to the 
design rather than something that will be smoothed out later, so I felt 
it would be useful to raise these points.

Hope they're helpful,

More information about the macports-dev mailing list