No subject

compatibility mode be present for at least a year, so that anyone who
upgrades at least once per year has a chance for a smooth transition..

> and my experience
> was, that so has to set both: quartz and no_x11 to get thinks working
> with quartz and not x11.

No. I believe that no_x11 must be left there only for the sake of
users who have the port installed with no_x11 and when they upgrade,
the no_x11 must be automatically replaced by quartz.

So this:
    if {[variant_isset no_x11 or variant_isset quartz]} {
should rather be
    if {[variant_isset quartz]} {
and this
    if {![variant_isset no_x11]} {
around darwin 8 should rather be
    if {![variant_isset quartz]} {

But probably a few more lines are needed to do the auto-replacement of
the options.

> gwyddion is not a project where don't hear
> from in years. So in one year the smooth transition should be made
> (however: there might be ports where this is not the case)

I didn't want to imply anything about the activity of this particular
project. I only realised possible consequences when thinking about it.
Also because I started collecting the information about [no_]x11 at
http://trac.macports.org/ticket/39383 and I didn't think of this
particular issue before (not increasing the revision).

>> Two more comments:
>>
>> 1.) the code still uses
>>     if {![variant_isset no_x11]}
>> instead of asking for existence or non-existence of quartz. This
>> should probably be fixed?
>
> should be fixed by r108376

See above. If you want to obsolete the no_x11, you probably want to
get rid of it completely.

> gwyddion uses x11 as native backend, since it comes from *ix, where
> x11 is the common ground. If added the usage of quartz later, but one
> of both should exists for this type of software ... and yes:

> if you use
> quartz, you should put the lines rejecting x11 (no_x11) and using quartz
> (quartz)

In future no_x11 will be removed entirely, so let's focus on the
future where there would be no no_x11 available any more. My question
was whether it makes more sense to have

a)
variant quartz conflicts x11 {...}
variant x11 conflicts quartz {...}
... additional code that makes sure that one and only one is selected ...

b) or just
variant quartz {... switch x11 off ...}

Honestly I don't know. The second one is way easier to implement and
understand. The first one is just more verbose, but a lot more complex
for "no reason". (Please not that I was just brainstorming. I didn't
want to imply that one or the other should be done.)

Mojca