Citando Randall Wood :
On 12/1/07, Ryan Schmidt <ryandesign@macports.org> wrote:
I wouldn't make this generalization. There are ports, like ImageMagick, that have a +no_x11 variant, which I believe should continue to have them. ImageMagick can build with support for some X11 things, or not. By default, we want to build the most featureful software possible, so X11 support is on by default. Users who do not wish this support can use the +no_x11 variant. I'm not aware of any Quartz support in ImageMagick.
Unless you would like to redefine our default installation goals to no longer be "most featureful" but instead be "most featureful excluding X11 things". I'm not saying we should or should not redefine this, just point out what our current status is, and that you seem to be proposing a change to that.
Actually, I guess our current guidelines are to build a port to be the most featureful while not including huge libraries as dependencies which most users won't want. Thus far, I think we've had an unspoken agreement that the X11 features are useful, and indeed our installation docs require the user to install X11 and the X11SDK. I guess you're proposing a change to that as well.
This is not a case of selecting features, but of having to make *mutually exclusive choices* between the Aqua (quartz rendering) and X11 user interfaces. In this case, I think we should make the default behavior be Aqua, but I am aware that pushing that now will break what already works during an upgrade, so I have made the default behavior to fail without explicit instructions from the user.
This choice between aqua and x11 is only sensible for ports depending on gtk. ImageMagick's display, teTeX's xdvi and most ports depending on X11 have no quartz backend. I don't know about gtk (the number of dependencies made me avoid gtk on osx), I'm not sure about qt (qt-mac and qt-x11 seem to provide the same things and ports depending on qt seem to be able to work in both cases), but for other things +no_x11 is often the most sensible variant to provide. As for gimp and other gtk progs, isn't the best way to do to have a gimp-app and gimp-x port that depend on two gtk2 ports (gtk2-quartz and gtk2-x) as vim-app vs vim +gtk or carbon-emacs vs emacs? Probably the most time consuming for the maintainers though as it means a lot of ports that become twice a lot of ports (but half as many variants to test and no black-variant-magick dependency to check). Emmanuel