[MacPorts] #54357: Qt5 : 5.9, 5.8 and Mac OS X 10.9

[MacPorts]

#54357: Qt5 : 5.9, 5.8 and Mac OS X 10.9
---------------------+-----------------
  Reporter:  RJVB    |      Owner:
      Type:  update  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:  qt5*    |
---------------------+-----------------

Comment (by RJVB):

 Something I didn't think to mention, and that apparently didn't occur to
 anyone: patches to reintroduce 10.9 support are going to be specific to
 that OS version, one way or another.

 Just to come back to that QComboBox example: I've never run into issues
 with that widget myself (AFAICR). But if it had been a frequent stumbling
 block for me and supposing nothing in its implementation has changed since
 the associated QTBUG report, I would have considered very seriously to
 apply the workaround patch to Qt.

 Don't get me wrong, I'm not saying that it's a bad idea to have a "mostly
 stock" Qt5 port, but I think that is of interest mostly for ports of
 projects that know how to target Mac specifically. The primary MacPorts
 mission as far as I understand it is to provide an easy way to install
 open source projects on Mac - which most of the time means cross-platform
 projects not intentionally developed for Mac. Platform-specific changes to
 middlewares like Qt that impose patching most all dependent projects are
 better addressed by patching the middleware. That doesn't prevent anyone
 from raising the issue upstream (like you did with MythTV), but that's not
 our primary goal.

 2 examples of the kind of patches I include in my port:qt5-kde:
 The patch of QStandardPaths: it allows to build code designed to locate
 shared resources in places ("standard locations") where they are found on
 Linux (e.g. under /usr/share) and where we also tend to install them in
 MacPorts ($prefix/share), without maintaining immense patch sets. It's
 done properly, so it remains possible to use only the Mac'ish standard
 locations.
 The patch of a QMenu hack: Qt has text-based heuristic guessmatics in
 place to infer which menu actions are to become the About, Quit and
 Preferences menu items in the Application menu. That works for
 applications with simple menus (as long as they are coded using more or
 less standard English), but things can go quite wrong. I've already had to
 deal with a case where the Preferences menu activated a non-interactive
 action with annoying and unintended effects. Now you can patch each
 dependent application to use `QMenu::setMenuRole()` on offending menu
 actions, but IMHO the more efficient fix for a context like MacPorts is to
 deactivate the offending heuristics hack (partly).

--
Ticket URL: <https://trac.macports.org/ticket/54357#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS