The following are notes by my mentor Randall Wood on the MacPorts.Framework GSoC project. I will be using them as a sort of Roadmap to track my progress as the summer progresses.

MacPorts Frameworks

The MacPorts Project would benefit from having Cocoa frameworks wrapped around the core APIs. Currently in a user's space on the MacPorts SVN server, there is a rough MacPorts.Framework. This document attempts to define a stronger framework. Please note that when this document refers to a current class or the current state, it is referring to the existing Framework code.

MacPorts Foundation (MacPorts.Framework)

The MacPorts Foundation needs to provide for the following capabilities:

  1. Allow for Port discovery (search the PortIndexes)

This is trivial and the current MPMacPorts class provides methods for doing this.

  1. Provide information about Ports (state, indexed information, files, etc)

The port discovery methods return wither a single MPPort object or an array of such objects. The MPPort currently provides state and indexed information about the port.

  1. Manipulate Ports (install, uninstall, upgrade, etc)

The MPPort class has methods for doing this, but they are incomplete as they accept no arguments (like a list of variants during install)

  1. Expose the MacPorts configuration

With some exceptions, this is not currently done, and may not be really necessary. The important exception is that there is a method for getting the MacPorts ${prefix} path.

  1. Notify the system of MacPorts activity (upgrade/installation/uninstallation of port foo has started/stopped/failed)

I think this may be the most difficult part of making this framework, but that may simply reflect the reality that I have not been able to sit down for more than about an hour at time to work on it. I think the ideal situation would be that activity in the Foundation framework should be spewed in either local or global notifications depending on the activity

MacPorts Application Kit (MacPortsAppKit.Framework)

The MacPorts Application Kit should provide the following:

  1. A memory resident index of ports that can be rapidly searched

This is currently the MPIndex class, but I think this can be pulled from the Foundation, as it really only benefits GUI applications where rapid response to user input is required

  1. A GUI for authenticating to perform MacPorts activities

This would entail embedding a helper application in the AppKit that can be launched in a privaleged manner to perform privaleged tasks. It should use the standard Authorization services to the greatest extent possible

  1. A GUI for selecting variants

A panel that can be attached to a window?

  1. A GUI for responding to errors and --force requests

Another panel that can be attached to a window?

  1. Extend MPPort to add methods identical in scope to the standard methods (install/uninstall/upgrade/etc) that accept the (id)sender argument and enable a GUI for handling the standard MPPort methods

This is basically a requirement to make MPPort behave as expected in a GUI environment and is an enabler for those panels that the AppKit provides. Ideally the sender should be an NSWindow, NSWindow Delegate, or an MPMacPorts Delegate (see 6 below)

  1. Define a protocol for delegates to handle feedback

The delegates would be delegates to MPMacPorts as extended by the Application Kit and delegation would allow for applications to override the App Kit to use their own GUI or to automate activities that the Framework should not (for example, the App Kit should not automate the forcing of the uninstallation of an inactive port, but a GUI application may allow a user to say that it should always force that, in which case the Application would just tell the App Kit to drive on).

Back to main gsoc08 MacPorts.Framework page

Last modified 9 years ago Last modified on Mar 21, 2009, 12:50:44 PM