Is it worth persevering with Macports_Framework?

[Ian Wadham]

Hello Rainer,

And thanks for very much your insights on what happened to Pallet and
Macports_Framework.

On 12/02/2013, at 8:58 PM, Rainer Müller wrote:
> 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.

I come from a similar background too, but starting on an 80x24 character
based terminal … :-)

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

I am thinking of all those customers I see in the Apple Shop who might
like to know that there is free software available on Apple Mac and be
able to get it easily.  Not so much the tools, but more the big applications
like Gimp and Digikam.

> 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 :-)

The main technical leader seems to have been a guy called "Randall"
Was he rhwood at macports.org?  Was he a student or a Macports developer?
The code contains several comments where people are looking for
advice from Randall.  If we could find *him* ...

>> 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…

I was able to download HTML doc for Macports_Framework from a
repository branch somewhere.  It has been quite useful.

Cheers, Ian W.