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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
