[MacPorts] #70026: trojita with Qt4 does not see its plugins and cannot set IMAP

MacPorts noreply at macports.org
Tue May 28 13:15:40 UTC 2024


#70026: trojita with Qt4 does not see its plugins and cannot set IMAP
---------------------------+-----------------------------------------
  Reporter:  barracuda156  |      Owner:  (none)
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.9.3
Resolution:                |   Keywords:  snowleopard, leopard, tiger
      Port:  trojita       |
---------------------------+-----------------------------------------

Comment (by RJVB):

 Replying to [comment:35 barracuda156]:
 > At least for Qt5 what I want is to build it like on every other non-
 Apple OS (NetBSD etc.), using X11 and no Cocoa (Carbon is out anyway).
 Your subports for qtbase does not do that at the moment?

 No. My Qt5 ports aren't cut up like the mainstream one has been;
 `port:qt5-kde` installs the equivalent of what `port:qt4-mac` installs
 (and with lots of patching to make it more appropriate for KF5). The -x11
 subport is designed as an add-on that provides the possibility to run
 applications under X11.

 What I meant was that your initial testing could be to make that -x11
 subport independent of the main port, and NOT strip it in the post-
 destroot so that it installs a basic but a priori fully functional X11
 Qt5. If you have enough CPU cycles to invest you can also simply apply the
 patches from the -x11 port to the main port and idem for the changes to
 `configure.args`. I don't think I've ever tested this, so you may come
 across Cocoa (or Carbon) code in other components (qtdeclarative would be
 a prime suspect). That is no obstacle to running Qt5 apps with `-platform
 xcb` (i.e. in X11 mode) on a supported OS where those APIs are functioning
 normally; I cannot predict how it will work elsewhere.

 I have one recurrent issue in X11 mode: long-running applications tend to
 get disconnected from the clipboard after a while. Possibly related to my
 habits of suspending the system for the night, which involves using FUS to
 go to the login screen and then turning off the Thunderbolt dock that
 drives my main display. Fact is, Qt5/xcb uses some kind of private hidden
 window as the "anchor" for clipboard operations so that the copied content
 gets discarded when you quit the application. That hidden window must get
 lost or something like that, meaning you can no longer copy content from
 X11 windows. GTk apps don't do this, but I've never yet been able to
 figure out why and patch Qt's code for this. For me it means I just have
 to relaunch my X11 terminals (KF5's konsole) from time to time.

 There are also sporadic issues with displaying on a remote X11 display but
 I reckon that's not your main concern...

 >
 > > Why didn't you add a variant (and why C++11 while wxW has a feature to
 build using C++14)? I *think* that that's a build option which doesn't
 change the ABI.
 >
 > wxWidgets is nasty, though I did not try C++14 with it. But wxGTK-3.2
 ''is broken even on Sonoma,'' so there is no way at the moment (obviously,
 neither Qt5 not Cocoa backend gonna work).

 Good thing I gave up `port:audacity` then!
 (Reading "Sonoma" my brain always adds "Gomorrea" 8-) )

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


More information about the macports-tickets mailing list