app PortGroup enhancements, and request for someone to test with +quartz variant for a few gtk apps

[Mojca Miklavec]

On 30 March 2018 at 20:17, Kenneth F. Cunningham wrote:
> On 2018-03-22, at 8:24 AM, Kenneth F. Cunningham wrote:
>
>> 2. an option to hide the sometimes forever bouncing dock icon
>>
>> options app.hide_dock_icon
>> default app.hide_dock_icon  no
>>
>> For the +x11 versions, you would want both of these options to be "yes" if gtk2 and gtk3 are installed as +x11.
>
> I have had some time to test this now.
>
> If the gtk port is built against gtk2 +quartz or gtk3 +quartz, then the app icon should be shown, and works correctly.
>
> if the gtk port is built agains gtk2 +x11 or gtk3 +x11, then the app icon should be hidden as it will bounce forever otherwise.
>
>
> I wonder if there is some elegant way to make this happen across the board without specifying a +x11 and +quartz variant individually for every port.
>
> I suspect there is not, and these variants are exactly what we would need to do for each port to make this work right.

I don't see a sane way.

Imagine a python program that depends on wxPython.

wxPython can be either built against Cocoa, [Carbon,] GTK2, or GTK3;
and GTK3 can be either quartz or x11. I don't see a sane way to
specify +x11/+quartz variants for that simple python script that
doesn't actually link against anything.

(We have that one single port whose developers refuse to move on,
py27-robotframework-ride, which still needs py27-wxpython-2.8 ->
wxgtk-2.8 -> gtk2. Not that I would worry about that one port, but
just as an illustrative example.)

I mean ... you could check if the port has the +x11 variant enabled
and set app.hide_dock_icon to yes by default in that case, but you
still need to offer that option to the developer for corner cases.
It's just that introducing some artificial variants to cover that case
sounds like an overkill.

Mojca