Hello everybody, I raised this topic on macports-users under the subject "How to get a full list of dependents?", but it is undoubtedly better to discuss it here and under a proper subject line.
I have been studying the source code of Pallet and Macports_Framework and doing a bit of testing of both, with a view to developing a GUI for Macports. I am using Xcode 4.6 and OS X 10.7.5 (Lion) on a Macbook Pro of 2011 vintage. Please note that I am new to Objective C, Xcode and OS X, but I have been developing in C++, Qt, KDE and Linux for a few years. I am in charge of KGoldrunner, KSudoku, Kubrick and KJumpingCube in the kdegames4 set. It appears that Pallet and Macports_Framework are both ex-GSoC projects that are not really finished. Certainly they have a few rough edges. Joshua Root described it as a "pre-alpha" state. On 10/02/2013, at 7:37 AM, Joshua Root wrote: > MacPorts_Framework is still in a pretty "pre-alpha" state, so I wouldn't > worry too much about maintaining compatibility if not doing so will make > it better. Just make sure you mention the interface breakage in the > commit logs, and fix Pallet to match. I replied as follows. It looks as though backwards compatibility is an impossible ask in an Xcode environment. For starters, there are all the .xcodeproj files. My Xcode 4.6 grumbles about them all the time and FAIK has already changed them a lot. The files in SVN are for Xcode 4.3, I think. Then Xcode keeps "pushing" newer features that are somewhat fundamental, such as automatic reference counting and Interface Builder layouts with constraints. These are nice features, but not backwards compatible. Re the "pre-alpha" state of Macports_Framework, tell me about it … :-) One problem is that there is almost zero error information (in an NSError object) passed back to Pallet, but lots of "comments to self" in the code about the need to do something. Another problem is that Pallet ignores the NSError object anyway and treats all actions as successful. A third is that actions like "install Growl" should always fail (the Growl port is broken), but sometimes are said to "succeed" (in the Console messages), when you use Pallet to do "install Growl". Macports_Framework has over 12,000 lines of code, and nearly 4,000 lines are a copy of Apple code for BetterAuthorizationSampleLib, dated 2007 (Is that code still current, I wonder?). 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. I am happy about building a GUI for Macports and I hope it would be an improvement on Pallet, but I am getting cold feet about Macports_Framework. If I persevere, I could certainly use some help with it. Also the question arises, does Macports, as a group, want to persevere with Macports_Framework? Apparently Pallet is its only dependent and I would not say that either of the two ports is up to the standard of quality we expect from Macports and the "port" command, not to mention the hundreds of other ports in Macports. Maybe it is a question of "fix or forget" Macports_Framework. All the best, Ian W. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
