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.
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.
--Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
