[KDE/Mac] kde-mac Digest, Vol 76, Issue 7

[René J.V. Bertin]

On Thursday March 24 2016 08:17:29 Jonathan Schultz wrote:

Hi,

> I take it you made the same fix to this problem as I did - changing the
> definitions of realDpiX and realDpiY to static?

Yep. The API calls made in those functions are deprecated, but I didn't want to spend too much time on this...

> Interesting. I have used qt5.5.1 installed via macports. I did try 
> installing qt5.6 directly from qt.io but found a number of qt modules 
> seemed to be missing(!?) I presume you are using a different macports 
> repository from the default, possibly your own?

My own, indeed. Only qtwebkit has been removed, and has turned out to be a challenge to build due to a few packaging errors in the "official" community_release tarball. I've finally managed to clone the git version inside the Qt5 source tree and have it build in a monolithic build, as it used to do.
-> github.com/RJVB/macstrop

Anyway, be aware that MacPorts' official Qt5 port doesn't contain a patched QStandardPaths class, which is required if you want to have everything working in an approach where you don't have to patch every application's build system to create standalone app bundles.

> > What doesn't work is postscript rendering. I haven't checked if
> > that's an error in libspectre or elsewhere; a 0x0 image is created
> > (also in Okular4).
> 
> And strangely enough postscript rendering works fine on my build.

Any idea what libraries are used for that? It's possible that I haven't updated my ghostscript port for too long (still at 9.10_2). 

I can however confirm that PDF displaying works on a remote X11 display, from a Mac OS X host. That means you should be able to check the hypothesis that the VM driver is responsible for your rendering glitch (in that case remote rendering should work fine).

R.