Is it worth persevering with Macports_Framework?

[Ian Wadham]

On 11/02/2013, at 4:51 AM, Kevin Walzer wrote:
> On 2/10/13 1:39 AM, Ian Wadham wrote:
>> Should I persevere with Macports_Framework?  It's been a while since I
>> worked with threads and concurrent processes and Apple's way of doing
>> things, in Objective C, OS X and Xcode is all new to me.  I enjoy a challenge,
>> but in this case, is it (Macports_Framework) worth the effort?  People are
>> lukewarm about having a GUI for Macports anyway.  I am not, but I find
>> the framework for interacting with Macports to be huge and rather daunting.
> 
> It's been my observation that as long as MacPort devs have worked on a GUI, they have tried to do it the hard way--writing it in Cocoa, and making use of MacPorts internals.
> 
> 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.

Back in the day, I was a great fan of popen() (man 3 popen) for gathering
info in real time from multi-host distributed database systems.  You get
multi-processing for free and synchronisation is as simple as sequential
I/O.  I see that Cocoa has NSTask and NSPipe classes and that Guido's
Guigna app is using them in its GuignaAgent class.  I also like this approach
because there is loose binding between the processes.  Our founding
fathers (Thompson, Ritchie, et al) knew what they were doing when they
developed pipes.

However, I stopped short of using the word "parse" in my previous email
and used the word "intercept" instead.  The "port" command has a slew of
possible message texts and presumably they are subject to change at any
time.  I doubt if I have seen them all yet … :-)  Also, do they get translated
into other languages and locales?

OTOH, just glancing at the Macports code, it does seem to have a consistent
policy wrt messages, such as an error message always begins with "Error:" … ;-)

> 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.

Absolutely.  And I think what a GUI should do is save the raw text, logs,
etc. for port developers' attention, in case needed, and show the user
basic summaries of progress, success or failure and inventories of what
has been installed when, maybe with the option to display full text if
that is what the user prefers.

Re the multi-threading approach, which I think goes about three deep
in Pallet and Macports, I find the code is in a thread when Pallet and
Macports_Framework return from a port command, so I cannot issue
a NSAlert message if there has been an error … ;-)  As in Qt4-Mac,
widgets don't work on a thread.  Maybe that is why Pallet brought in Growl.
Never mind, I will find a solution in due course and am using NSLog
for now, while I am trying out Pallet and Macports_Framework further.

Cheers, Ian W.