Is it worth persevering with Macports_Framework?

[Rainer Müller]

Hello Ian,

thank you for your interest in MacPorts.framework. I will try to give
some insight into the state of this framework and the MacPorts GUI,
which will hopefully explain the state of the project.

On 2013-02-10 10:59, Ian Wadham wrote:
> 
> On 10/02/2013, at 8:11 PM, Ryan Schmidt wrote:
>> On Feb 10, 2013, at 00:39, Ian Wadham wrote:
>>> Should I persevere with Macports_Framework?
>>
>> What alternative do you propose?
> 
> For myself, acting alone?  None.  Find something smaller and
> easier to work on - not Macports_Framework, Pallet or other GUI.
> 
> For Macports?  That's up to you guys.  Fix it or forget it, or at least
> withdraw Pallet and Macports_Framework from distribution for the
> time being.

In my experience, most of the developers involved in MacPorts are coming
from a Unix background and are driven by the need to run additional
tools in their terminals on Mac OS X in the same way they would do on
Linux or *BSD. For myself, I have absolutely no idea how to develop
graphical user interfaces on Mac OS X and I have no interest to learn
that as I am quite happy with a terminal.

On the other hand, there is a wide user base with unexperienced users
who would prefer a GUI to interact with MacPorts.

When we were accepted into Google Summer of Code [1] a few years ago we
tried to fix that with the idea that a student should have the
opportunity to write GUI for MacPorts and being paid for that work.
After that summer, we had the initial version of MacPorts.framework. In
the next year, on top of that Pallet was implemented by a different
student under supervision by the first and a third student improved the
GUI in the year after that.

The main problem now is that none of these original developers of the
MacPorts.framework or Pallet sticked with the project, which means the
code is currently orphaned and does not have any active maintainer.
Since then, there were many changes and refactoring in the base code,
including but not limited to the introduction of registry2.0. This lead
to a lot of changes which seem to make MacPorts.framework incompatible.

> If someone can fix MP_Fr, I can assist, but I do not think I can
> handle it alone.

I added all the previous developers of MacPorts.framework and GUI to Cc,
I would be glad if some of them want to lend you a hand. I know that
some of you retired, but I thought that you might be interested in where
your work ends up now :-)

> Maybe there is scope for a simpler interface to Macports, such as
> running scripts and intercepting the output, but I have not looked at
> that.  I think maybe MP_Fr does something like that already ...

No, the framework links with Tcl and makes calls to the macports1.0
library. There are some HeaderDoc comments in the source code, although
I have no idea how to generate any HTML documentation from that...

Rainer

[1] https://trac.macports.org/wiki/SummerOfCode